CVE-2026-82115

LOWCVSS 6.3 · MEDIUM

Signal is active with 1 mentions in latest observed window

Immediate actions

  • Track advisory updates for patch or workaround availability

Recommended action window: Monitor and triage in normal cycle

NVD description

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.

0.0/ 10 priority

Sources & remediation

Weakness type (CWE)
CWE-862

Priority

LOW

Exploitation

NONE

PoC

NONE

Patch

NONE

Momentum

NONE

Threat summary

  • 1 mentions across 1 observed day

What's happening

  • 1 total mentions across 1 day

Deep dive

Activity timeline1 mentions / 1d
00111Mentions · 2026-11-02: 111-02
Referenced assets2 URLs
Full discourse1 post
  • ♫Why♥Not♪@Python_s_

    #NØØT_Security_Alerts 🚨 #ALERT — Apache Wicket WebSocket Authorization Bypass Allows Restricted Resource Operations November 1, 2026 PRODUCT: Apache Wicket (wicket-native-websocket-core) | CVE-2026-82115 | MEDIUM (CVSS 4.0: 6.3). AFFECTED: 8.0.0–8.19.0, 9.0.0–9.24.0, 10.0.0–10.11.0. Older unsupported 7.x releases are also affected. FIXED: 8.20.0 and 9.25.0, released October 29; 10.12.0, released October 31. Wicket 8/9 are now end-of-life. IMPACT: In applications registering a shared WebSocketResource protected through Wicket’s authorization strategy, WebSocketMessageBroadcastHandler invokes resource callbacks without checking IAuthorizationStrategy. The @AuthorizeResource annotation alone does not enforce access. A caller with their own Wicket session and the resource name can send text or binary messages that reach restricted callbacks. The resulting operations depend on application code. This does not grant access to another user’s WebSocket connection. EXPLOITATION STATUS: Apache-documented authorization flaw. No malicious exploitation or victim compromise established by the reviewed primary evidence. TRIAGE: Inventory shared WebSocket resources, authorization rules and deployed Wicket modules. Test whether restricted callbacks reject unauthorized sessions. Correlate WebSocket connections and application-side actions; ordinary connections are not proof of exploitation, and frame contents may be unlogged. URGENT ACTION: Restrict exposed resources. Pending upgrade, use IWebSocketConnectionFilter to reject unauthorized connections or enforce authorization within each callback. Upgrade to supported Wicket 10.12.0 LTS where compatible, or apply the appropriate branch fix while planning migration from 8/9. Verify deployed dependencies and rejection behavior after rollout. Preserve suspicious telemetry and investigate unauthorized operations where indicated. SOURCE — APACHE CNA CVE RECORD: https://github.com/CVEProject/cvelistV5/blob/main/cves/2026/82xxx/CVE-2026-82115.json SOURCE — APACHE VENDOR RELEASE: https://wicket.apache.org/news/2026/10/31/wicket-10.12.0-released.html CONFIDENCE: HIGH for the Apache-published mechanism, prerequisites and fixed versions. Actual deployment exposure and malicious exploitation remain unverified. #CyberSecurity #AppSec #DevSecOps #IncidentResponse

    0000029
    233 followersView on X

Explore more