Apache Wicket CVE-2026-82115

Exploitation requires a specific, non-default application pattern: the app must register an org.apache.wicket.protocol.ws.api.WebSocketResource as a shared resource AND depend on the Wicket IAuthorizationStrategy (e.g. an @AuthorizeResource annotation) to restrict access to it - apps that do not expose WebSocketResource shared resources, or that already gate them with an IWebSocketConnectionFilter, are not affected. The attacker needs a bound Wicket session (trivially obtained by any visitor, not true authentication) and the resource name, which Wicket writes into the page that opens the connection and is therefore not secret. Limiting factors: impact is bounded to whatever the targeted resource's callbacks do with an attacker-supplied message, and the connection registers under the attacker's own session, giving no access to other users' connections.

This is a genuine but constrained authorization-bypass (CWE-862) in Apache Wicket's native WebSocket transport, best characterized as a moderate, conditional issue rather than a top-tier emergency. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N) scores 6.3 and signals network reach with no privileges or user interaction, but the AT:P flag (attack requirement) is material: the flaw only exists where an application both registers a WebSocketResource as a shared resource AND relies on IAuthorizationStrategy to restrict it. Impact is explicitly limited (VC:L/VI:L/VA:N) - the caller gains only whatever that specific resource's onConnect/onMessage callbacks do with an attacker-chosen text or binary message, scoped to the caller's own session, so there is no cross-user access and no availability impact. No KEV listing, no EPSS score, and no PoC or exploit reference are present in the input, so exploitation signals are all absent rather than conflicting: exploitation status is 'no public exploit identified at time of analysis.' The vuln.today decision label is 'this_month,' consistent with a patch-this-cycle priority rather than act_now/emergency. Note one signal to verify: CVSS marks PR:N, yet the description requires a 'bound Wicket session' - a session is trivially obtained by any visitor and is not authentication, so PR:N is defensible, but teams relying on CVSS alone should understand the real gate is the vulnerable app pattern, not network exposure.

An application registers a WebSocketResource as a shared resource and annotates it with @AuthorizeResource expecting the authorization strategy to block unauthorized users. A remote attacker who can obtain a Wicket session reads the resource name (Wicket writes it into the page that opens the connection, so it is not secret), opens a WebSocket naming that resource, and reaches onConnect() and onMessage() directly - the authorization check is never consulted. No public exploit code or PoC reference is identified in the available data.