CVE-2026-82559
LowCVSS 2.3Summary
The vulnerability in Apache Wicket is insufficient session expiration in native WebSocket support. A WebSocket connection keeps a copy of the HTTP session from when it was opened, so invalidating the session via the container (idle timeout, logout, filter invalidate) does not end the connection — subsequent frames still resolve the revoked identity and its attributes.
Risk Assessment
After logout or session expiry, an open WebSocket connection may still authorize requests on behalf of a revoked identity, risking unauthorized access to data and operations. It affects applications using native WebSockets on pages or resources that require an authenticated session.
Recommendation
Upgrade Apache Wicket to version 8.20.0, 9.25.0 or 10.12.0, which fix the issue. Until upgraded, consider closing WebSocket connections application-side on logout and re-verifying identity in callbacks.
Other vulnerabilities in Apache Wicket
See all- CVE-2026-95863High
Apache Wicket generates JavaScript that references rendered elements, placing markup ids and form input names inside single-quoted JavaScript string literals without proper escaping. A value containing a single quote or backslash can terminate the literal and inject script that runs in the application's origin when the page loads. The issue affects wicket-core and wicket-extensions in versions 8.0.0 through 8.19.0, 9.0.0 through 9.24.0, and 10.0.0 through 10.11.0.
- CVE-2026-87718Low
Apache Wicket 10.10.0, 10.11.0 and 9.24.0 do not set Content-Security-Policy headers on a page whose render request handler is wrapped in more than one IRequestHandlerDelegate. The framework unwraps only a single delegate level when deciding whether a request renders a page, so with a deeper chain, for example an application-provided delegating request mapper combined with CryptoMapper, the page is served without any CSP header even though CSP is enabled, and no error or warning is raised. The nonce-based protection Wicket applies to inline scripts and styles, together with any other CSP directives configured by the application, is thereby lost for those pages, exposing them to content injection the policy was meant to prevent. Applications on stock Wicket that do not wrap request handlers themselves are not affected. Versions before 10.10.0 and 9.24.0 handled nested delegates correctly.
- CVE-2026-84231High
A cross-site scripting (XSS) vulnerability in Apache Wicket arises from improper neutralization of input during web page generation. The ExternalLink component, when bound to a non-anchor element, concatenates the model URL into a JavaScript string literal in the onclick attribute without proper escaping, allowing script execution in the application's origin.
- CVE-2026-84177Medium
Apache Wicket has an incorrect behavior order: a file path is validated by PackageResourceGuard before the framework appends the style, variation and locale attributes. As a result, the file opened may differ from the file approved by the guard, allowing disclosure of HTML markup templates of components whose class names contain an underscore (e.g. Report_v2).
- CVE-2026-84172Medium
In Apache Wicket, PackageResourceGuard incorrectly allows component markup templates to be served as package resources when wicket-core is loaded by a class loader that cannot see the application's classes. In such a setup the check for a class file beside the template fails, and a request for the package resource URL returns the component's markup template with status 200. Disclosed content is developer-authored template material such as component structure, comments, inline script, and named endpoints.
- CVE-2026-84170High
A vulnerability in Apache Wicket affects AbstractFileUploadResource, the server side of the form-less upload offered by FileUploadToResourceField. The request size, single-part size and part-count limits are taken from request parameters (maxSize, fileMaxSize, fileCountMax) instead of application configuration, so a client can raise or omit them. The resource carries no authorization annotation, so by default requests need no authentication.
- CVE-2026-83594High
A vulnerability in Apache Wicket affects the FileUploadToResourceField component, whose Ajax callback reads the filesInfo request parameter without binding it to an actual upload. The UploadInfo#get() method allocates a byte array based on the client-supplied size, allowing a single request to exhaust the JVM heap, while negative values trigger a NegativeArraySizeException.
- CVE-2026-83559High
A vulnerability in Apache Wicket affects the JavaScriptUtils#escapeQuotes() method, which fails to escape the backslash character before quotes. A value containing a backslash immediately before a quote results in the quote being left unescaped, closing the JavaScript string literal and allowing JavaScript injection. The issue occurs when an application uses this method to place attacker-influenced data inside a JavaScript string literal, including via the AjaxEditableLabel component.
- CVE-2026-83539High
Cross-site scripting (XSS) vulnerability in the SmartLinkLabel and SmartLinkMultiLineLabel components of Apache Wicket. These components turn URLs found in text into hyperlinks and accept any URL scheme, including script-executing schemes such as javascript:. Escaping the model value does not help because the payload ends up in the href attribute rather than in element text.
- CVE-2026-82956High
A cross-site scripting (XSS) vulnerability in Apache Wicket affects the AjaxNewWindowNotifyingBehavior, which stores the client-supplied window.name value in the page's serialized state. That value is later substituted without escaping into a single-quoted JavaScript string literal in the Ajax call precondition, allowing arbitrary script execution in the application's origin on every render of the page instance. Only applications that explicitly add this behavior to a component are affected.
Original NVD description (English source)
Insufficient session expiration in Apache Wicket. org.apache.wicket.protocol.ws.WebSocketSettings#newWebSocketRequest() wraps the WebSocket upgrade request in an org.apache.wicket.protocol.ws.api.ServletRequestCopy, which is kept for the life of the connection and used to build the request for every frame that arrives on it. Copying the request is deliberate and is documented as such, because the container recycles the upgrade request once the handshake is over. The container session is copied along with it, into an org.apache.wicket.protocol.ws.api.HttpSessionCopy holding the session attributes as they stood when the connection was opened. That second copy is not necessary, because a session, unlike a request, is not discarded at the end of a request. Every frame afterwards resolves its Wicket session through ISessionStore#lookup(), which reads it out of the copy, so the connection is detached from the live container session for as long as it stays open. Ending the session through the container therefore does not end the connection. After an idle timeout, an HttpSession#invalidate() call made from a filter or from a security framework, a container-managed logout, or a session replacement, the connection goes on resolving the org.apache.wicket.Session instance that existed when it was opened, together with that session's attributes and, for applications built on wicket-auth-roles, the signed-in state held on that same instance, so an authorization decision taken inside a WebSocket callback is taken against an identity that has already been revoked. The copy is also what the connection writes through: a Session#invalidateNow() issued from inside a WebSocket callback invalidates the copy and leaves the container session valid, and session attributes set over the connection are written to the copy rather than to the session. An application is affected where it uses Wicket's native WebSocket support on pages or shared resources that require an authenticated session, and where sessions are ended by the container rather than by Wicket. Session#invalidateNow(), and AuthenticatedWebSession#invalidate() and #signOut() which call it, remain effective for a WebSocketBehavior on a page: they clear the page manager, and the connection can then no longer resolve the page it was opened for. A WebSocketResource is not limited in that way, because a frame naming a resource is served against a throwaway page and never consults the page manager, so such a connection outlives Wicket's own sign-out as well. Some containers close WebSocket connections themselves when the HTTP session they were opened under is destroyed, in which case the connection ends regardless; that is a property of the container rather than of Wicket. Applications that do not use the native WebSocket support are not affected. 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 6.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.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS