Skip to main content
← Vulnerabilities

Apache Wicket: The configured authorization strategy is not applied to a shared WebSocketResource

Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.

Published
Last modified
Published
Not listed in CISA KEV
28/100 · provisional
None on Exploit-DB, Metasploit or GitHub

Summary

Apache Wicket applications that register a WebSocketResource as a shared resource and rely on the configured authorization strategy to restrict it are affected. A user with a bound session can reach that resource's callbacks, including when a connection opens and when messages arrive, so the authorization restriction is bypassed and the caller can make the resource act on messages they send.

Read the original 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.

Timeline

  1. CVE published
  2. First seen by cve.now

Affected versions

  • org.apache.wicket:wicket-native-websocket-core

    From 8.0.0 · through 8.19.0; From 9.0.0 · through 9.24.0; From 10.0.0 · through 10.11.0

Evidence 1

  1. Advisory

Corrections

None so far.

Something wrong on this page? Report an error. Every fix is listed here.