Apache Wicket WebSocket Resource Missing Authorization Vulnerability (CVE-2026-82115) Analysis & Mitigation Guide
Executive & SecOps Summary
SECOPS ASSESSMENTApache Wicket versions 8.0.0 to 8.19.0, 9.0.0 to 9.24.0, 10.0.0 to 10.11.0, and unsupported 7.x releases
Unauthorized attackers can bypass security strategies to directly access WebSocket resources and execute arbitrary business logic via custom payloads
Immediately upgrade Apache Wicket to version 8.20.0, 9.25.0, or 10.12.0 or higher
Affected Products & Version Scope
Remediation & Live Workaround Commands
PATCH & WORKAROUND1. Official Patch & Version Upgrade Commands
Update your project's build configuration to use the patched versions of Apache Wicket (8.20.0, 9.25.0, or 10.12.0).
For Maven (pom.xml):
<!-- Upgrade Apache Wicket dependencies to a secure version -->
<dependency>
<groupId>org.apache.wicket</groupId>
<artifactId>wicket-core</artifactId>
<version>10.12.0</version>
</dependency>
<dependency>
<groupId>org.apache.wicket</groupId>
<artifactId>wicket-native-websocket-javax</artifactId>
<version>10.12.0</version>
</dependency>For Gradle (build.gradle):
implementation 'org.apache.wicket:wicket-core:10.12.0'
implementation 'org.apache.wicket:wicket-native-websocket-javax:10.12.0'2. Temporary Workaround & Hardening Configuration
If an immediate upgrade is not feasible, register an IWebSocketConnectionFilter via WebSocketSettings#setConnectionFilter() to reject unauthorized connections, or manually perform authorization checks at the beginning of each callback.
Example Workaround in Wicket Application Class:
import org.apache.wicket.protocol.ws.api.WebSocketSettings;
@Override
protected void init() {
super.init();
WebSocketSettings webSocketSettings = WebSocketSettings.Holder.get(this);
webSocketSettings.setConnectionFilter((request, sessionHashtable) -> {
// Implement custom authorization check here
// Return false to reject unauthorized WebSocket connection attempts
return true;
});
}3. Log Audit & IoC Verification Commands
Use the following command to scan your deployment environment for vulnerable Wicket library versions.
Vulnerable Library Scan Command:
# Find vulnerable Wicket core JAR files in the deployment directory
find /path/to/deploy -name "wicket-core-*.jar" | grep -E "(8\.(0|[1-9]|1[0-9])\.|9\.(0|[1-9]|1[0-9]|2[0-4])\.|10\.(0|[1-9]|1[0-1])\.)"Block Exploits Instantly with Managed Virtual Patching Rules
Can't patch production immediately? Deploy managed WAF rules at the edge to intercept RCE, SQLi, and deserialization payloads before they hit your origin server.
Technical Root Cause & Exploitation Mechanics
1. Vulnerability Overview & Root Cause
This vulnerability (CVE-2026-82115) is a missing authorization flaw (CWE-862) within Apache Wicket's native WebSocket support. The framework's request handler for delivering incoming WebSocket frames, WebSocketMessageBroadcastHandler, resolves the shared resource specified by the client's handshake parameter and directly invokes WebSocketResource#onPayload(). This process bypasses the standard authorization check, IAuthorizationStrategy#isResourceAuthorized(), which is only enforced in ResourceRequestHandler. Because the WebSocket transport does not route through this handler, and WebSocketResource#respond() is defined as final and empty, any @AuthorizeResource annotations configured on the resource class are completely ignored.
2. Exploitation Mechanics & Attack Scenario
To exploit this vulnerability, an attacker requires a valid bound Wicket session and the name of the target shared resource. The resource name is not confidential, as Wicket exposes it within the HTML page that establishes the connection. Once the name is obtained, the attacker can bypass authorization checks and trigger all callbacks of the target WebSocketResource, including onConnect() and both onMessage() overloads. Any text or binary payload sent by the attacker is processed by these callbacks, and any response pushed back via WebSocketRequestHandler is routed back to the attacker's own connection. While this does not grant access to other users' active connections, it allows unauthorized users to interact with restricted backend resources.
3. Infrastructure & Business Impact
Applications that register a WebSocketResource as a shared resource and rely on Wicket's authorization strategy to restrict access are highly vulnerable. Attackers can execute unauthorized actions, trigger sensitive business logic, or process arbitrary data payloads through the exposed WebSocket endpoints. This can lead to unauthorized data manipulation, system abuse, and integrity compromise of the application's backend services.
Official Vendor Advisories & References
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.
Frequently Asked SecOps Questions (CVE-2026-82115)
FAQQ1. How critical is CVE-2026-82115 and is it actively exploited in the wild?
CVE-2026-82115 is rated CVSS 6.3 (MEDIUM) with a 30-day EPSS exploitation probability of 0.3%. Organizations running affected versions should prioritize patching based on network exposure.
Q2. Which vendors and products are affected by CVE-2026-82115?
Primary impacted vendors include apache across wicket. Scope summary: Apache Wicket versions 8.0.0 through 8.19.0, 9.0.0 through 9.24.0, 10.0.0 through 10.11.0, and legacy unsupported releases from 7.0.0 onwards
Q3. What temporary mitigations or workarounds exist for CVE-2026-82115 before patching?
[Mitigation] Immediately upgrade Apache Wicket to version 8.20.0, 9.25.0, or 10.12.0 or higher Follow the CLI remediation commands and interactive SecOps checklist on this page to restrict exposure prior to your maintenance window.
Generate an Internal Engineering Notice or CISO Report for CVE-2026-82115
Instantly format this advisory into an executive CISO summary or engineering patch ticket.
🔗 Related Advisories in Similar Stack (apache)
View Category →Apache Wicket Cross-Site Scripting (XSS) Vulnerability due to Missing Resource Bundle Escaping (CVE-2026-111089)
[Affected Scope] Apache Wicket versions 8.0.0 to 8.19.0, 9.0.0 to 9.24.0, and 10.0.0 to 10.11.0
Apache Wicket AjaxNewWindowNotifyingBehavior Cross-Site Scripting (XSS) Vulnerability (CVE-2026-82956)
[Affected Scope] Apache Wicket versions 8.0.0 to 8.19.0, 9.0.0 to 9.24.0, and 10.0.0 to 10.11.0, specifically when AjaxNewWindowNotifyingBehavior is explicitly used
Apache Wicket JavaScriptUtils Escape Bypass Remote Script Execution Vulnerability (CVE-2026-83559)
[Affected Scope] Apache Wicket versions 8.0.0 to 8.19.0, 9.0.0 to 9.24.0, 10.0.0 to 10.11.0, and unsupported 7.x or older versions
Apache Wicket SmartLinkLabel Cross-Site Scripting (XSS) Vulnerability (CVE-2026-83539)
[Affected Scope] Apache Wicket versions 8.0.0 to 8.19.0, 9.0.0 to 9.24.0, and 10.0.0 to 10.11.0 utilizing SmartLinkLabel or SmartLinkMultiLineLabel components
Subscribe to Daily Vulnerability Briefings & KEV Alerts
Concise morning briefings for SecOps, DevSecOps, and SRE teams covering newly exploited CVEs and mitigation priorities.