CVE-2026-82559
Last modified
CVE-2026-82559 is a low-severity vulnerability rated 2.3/10 on the CVSS scale. 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. EPSS estimates a 0.29% chance of exploitation in the next 30 days.
Description
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.
Metrics
Weakness Enumeration
Affected Software
Source: CNA advisory (CVE.org). NVD analysis pending.
| Vendor | Product | Versions |
|---|---|---|
| Apache Software Foundation | Apache Wicket | >= 8.0.0, <= 8.19.0; >= 9.0.0, <= 9.24.0; >= 10.0.0, <= 10.11.0 |
References
Timeline
- Published
- Last Modified
- Status
- Deferred
Frequently Asked Questions
What is CVE-2026-82559?
How severe is CVE-2026-82559?
How do I fix CVE-2026-82559?
How Strix Helps
- How Strix found a critical auth bypass in etcdStrix autonomously discovered a critical authentication bypass in etcd, later designated CVE-2026-33413.
- Autonomous PentestingAI agents that find and validate exploitable vulnerabilities like this one across your applications.
- PR ReviewsPentest every pull request so vulnerable code is caught before it ships to production.
- AI Penetration TestingHow AI-driven penetration testing continuously covers your attack surface.
Related CVEs from 2026
- CVE-2026-82553A vulnerability was detected in sambitraj Student Management…6.3
- CVE-2026-82554A flaw has been found in SourceCodester Queue Management Sys…4.3
- CVE-2026-82555A vulnerability has been found in TOTOLINK N600R 4.3.0cu.786…3.7
- CVE-2026-82556A vulnerability was found in Forgejo up to 15.0.4. This issu…6.3
- CVE-2026-82557Missing authorization in Apache Wicket. org.apache.wicket.m…6.9
- CVE-2026-82558Missing authorization in Apache Wicket. org.apache.wicket.p…2.3
- CVE-2026-8256A security vulnerability has been detected in Devs Palace ER…2.4
- CVE-2026-82560Pod::Text versions before 6.1.1 for Perl allow CPU and memor…7.5
- CVE-2026-82561Apache NiFi 1.5.0 through 2.11.0 provide REST API methods th…6.5
- CVE-2026-82562### Summary When `qs.parse` is called with `comma: true` …3.7
- CVE-2026-82563An attacker could impersonate the camera and place themselve…7.6
- CVE-2026-82564Authorization Bypass Through User-Controlled Key vulnerabili…7.1
Are you affected by CVE-2026-82559?
Run a free Strix scan to check your systems for this vulnerability.
Scan your code nowSource: NVD / NIST
