Apache Wicket CVE-2026-82558

Exploitation requires an application-specific, non-default coding pattern: the app must attach a WebSocketBehavior that overrides onMessage() to a component (or a child of a component) that it hides, disables, or restricts through its IAuthorizationStrategy - for example via MetaDataRoleAuthorizationStrategy or the AuthorizeAction annotation - while Wicket's native WebSocket support is in use. The attacker must hold their own valid session and open their own page containing such a component; because messages are delivered only to pages in the client's own session page store, there is no access to another user's session, page, or connection. Server-pushed messages are not affected. These factors (required authenticated session, dependence on a specific restricted-component + WebSocketBehavior combination, and self-confined scope) sharply limit realistic risk despite the network attack vector.

All decision signals point to low real-world priority and are mutually consistent. The vendor CVSS 4.0 base score is 2.3 (Low) and the vuln.today decision label is 'monitor', not act_now or emergency. The vector (AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:L/VA:N) shows the attacker must already hold a low-privilege authenticated session (PR:L), the attack has a requirement precondition (AT:P) - namely the specific non-default coding pattern described - and impact is only Low on confidentiality and integrity with no availability or subsequent-system impact. Crucially, the description confines the flaw to the attacker's own session, page and WebSocket connection, so there is no cross-user or cross-tenant impact. This is not in CISA KEV (no confirmed active exploitation), no EPSS score was supplied in the input (exploitation probability cannot be quantified here), and no public exploit identified at time of analysis - the only reference is the Apache advisory thread, not PoC/exploit code. Net assessment: a genuine but low-severity authorization gap that depends on an application-specific misuse pattern; it warrants patching during normal maintenance, not emergency response. Note the 'Authentication Bypass' tag overstates the issue: CWE-862 and the description describe missing authorization for an already-authenticated user, not an authentication bypass.

A low-privileged user with their own valid session opens one of their own pages that contains a component the application restricts via its IAuthorizationStrategy (e.g. hidden, disabled, or role-gated) but which also carries a WebSocketBehavior overriding onMessage(). The user sends crafted WebSocket text or binary messages over the single per-page connection, and Wicket delivers them straight to that behavior's onMessage() callback without performing the canCallListener authorization check an Ajax behavior on the same component would be subjected to, letting the user invoke callback logic they should not reach. No public exploit identified at time of analysis; impact is limited to the attacker's own session.