Live › vulnerability › CVE-2026-82115
Apache Wicket's WebSocket support delivers incoming frames to shared WebSocketResource callbacks without consulting the configured authorization strategy. A logged-in or session-bound caller who knows the resource name can trigger those callbacks with messages of their choosing.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-11-01 22:22 UTC. All times on this page are UTC.
Applications that register a WebSocketResource as a shared resource and depend on the authorization strategy to restrict it are exposed. The caller needs a bound Wicket session and the resource name, which the page already exposes. Applications that do not use WebSocket resources, or that enforce access with a connection filter, can skip it.
No product ranges from the sources yet.
WebSocketResource subclasses registered as shared resources (mountResource or SharedResources) in the application that rely on IAuthorizationStrategy or @AuthorizeResource to restrict access.8.20.09.25.010.12.0Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
Missing authorization in Apache Wicket.
org.apache.wicket.protocol.ws.api.WebSocketMessageBroadcastHandler, the request handler Wicket's native WebSocket support uses to deliver an incoming frame, resolves the shared resource named by the client's handshake parameter and calls WebSocketResource#onPayload() on it directly, without consulting IAuthorizationStrategy#isResourceAuthorized(). That method has a single enforcement point in the framework, org.apache.wicket.request.handler.resource.ResourceRequestHandler, which the WebSocket transport does not pass through, and WebSocketResource#respond() is final and empty. No route to a WebSocketResource therefore asks the configured authorization strategy whether the caller may use it, and an @AuthorizeResource annotation on such a class has no effect.
A caller needs a bound Wicket session and the name of the resource. The name is not a secret: Wicket writes it into the page that opens the connection. No page of the application is otherwise involved, because a request naming a resource is served with a throwaway page. All of the resource's callbacks are reached this way, including onConnect() and both onMessage() overloads, and what a callback pushes back through WebSocketRequestHandler goes to the caller's own connection.
An application is affected where it registers a WebSocketResource as a shared resource and relies on the authorization strategy to restrict it. What the caller gains is whatever that resource's callbacks do with a text or binary message of the caller's choosing. The connection is registered under the caller's own session, so it gives no access to another user's connection.
As a workaround, reject unauthorized connections with an IWebSocketConnectionFilter registered through WebSocketSettings#setConnectionFilter(), or repeat the authorization check at the start of each callback.
This issue affects Apache Wicket: from 8.0.0 through 8.19.0, from 9.0.0 through 9.24.0, from 10.0.0 through 10.11.0. Older, unsupported releases from 7.0.0 onwards are also affected. Users are recommended to upgrade to version 8.20.0, 9.25.0 or 10.12.0, which fix the issue.
This page as .md · .json · in your agent: get_signal("CVE-2026-82115")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.