CVE-2026-82559
📛 CVE Title
Apache Wicket: WebSocket messages are processed against an HTTP session snapshot that survives invalidation
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.
Overview
- State
- PUBLISHED
- Assigner (CNA)
- apache
- CVSS severity
- LOW
- CVSS score
- 2.3 / 10
- CVSS vector
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N- Effective score
- 2.3 / 10 LOW source: CNA overview
- CWE(s)
-
CWE-613 - Reserved
- 2026-08-29
- Published
- 2026-11-01 22:00 UTC
- Last updated
- 2026-11-01 22:00 UTC
- Source
- https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/82xxx/CVE-2026-82559.json
NVD triage scoring NVD CVE 2.0
Layer NVD adds on top of the CNA's CVE record — published / last-modified timestamps, exploitability / impact subscores, and the FIRST.org EPSS probability that this CVE will be exploited in the wild in the next 30 days.
- NVD published
- 2026-11-01 22:17:47 UTC
- NVD last modified
- 2026-11-01 22:17:47 UTC
NVD / KEV / EPSS data refreshed 2026-11-02 13:55 UTC. Re-run the 🛰 Backfill from NVD button above to refresh.
European Union Vulnerability Database ENISA EUVD
ENISA's official EU repository for curated vulnerability intelligence. Carries a separate identifier (EUVD-YYYY-NNNN) and frequently exposes an earlier-published description + CVSS than NVD does.
- EUVD ID
-
EUVD-2026-114889 - Assigner
- apache
- Published
- Nov 1, 2026, 10:00:24 PM
- Updated
- Nov 1, 2026, 10:00:24 PM
- EUVD base score (CVSS 4.0)
-
2.3 / 10
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N - EUVD-reported EPSS
- 0.0000
- Vendors
- Apache Software Foundation
- Products
-
Apache Wicket (8.0.0 ≤8.19.0)Apache Wicket (9.0.0 ≤9.24.0)Apache Wicket (10.0.0 ≤10.11.0)
- Aliases
-
GHSA-5h36-fqxx-fjph
ENISA 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.
EUVD references (1)
Affected products (1)
| Vendor | Product | Versions | Platforms |
|---|---|---|---|
| Apache Software Foundation | Apache Wicket |
8.0.0 (affected),
9.0.0 (affected),
10.0.0 (affected)
|
— |
Vendor references (1)
References embedded in the original CVE record by the assigning CNA.
MITRE references (1) cveawg.mitre.org
Pulled from MITRE's CVE Services API by the 🛰 Backfill from MITRE button.
Web references (0)
DuckDuckGo results ranked by threat-intel / vendor advisory domains. Generated by the 🔎 Find references (web) button above — same flow as the Remediations search.
No web references attached yet.
NVD-tagged references (1)
Reference list NVD curates from the CNA record, vendor advisories, and third-party reports. The tag chips below are NVD's analyst-assigned categories.
- https://lists.apache.org/thread.html/5vkw9wz6gf135ccosj928zjs4hqy7bcv security@apache.org
Remediations (10)
-
web:cvetodo.com
CVE-2026-82559 : Insufficient Session Expiration in Apache Wicket (CVSS 2.3). Full technical analysis, mitigations , and exploit status — updated in real time.
2026-11-02 13:18 UTC -
web:cyberupdates365.com
Track critical CVE vulnerabilities 2026 with verified enterprise patch guides. Fix zero-days across VMware, WordPress, Windows, and cloud infrastructure.
2026-11-02 13:18 UTC -
web:vulmon.com
Vulnerability Summary Apache Wicket versions 8.0.0 through 8.19.0, 9.0.0 through 9.24.0, and 10.0.0 through 10.11. are affected by insufficient session expiration in their WebSocket support. This vulnerability allows connections to remain active and authenticated even after the container session has been invalidated. The issue arises because WebSocket connections maintain a copy of the ...
2026-11-02 13:18 UTC -
web:vulners.com
Apache Wicket versions 8.0.0 through 8.19.0 , 9.0.0 through 9.24.0 , and 10.0.0 through 10.11. (along with unsupported releases from 6.0.0 onwards) are vulnerable to insufficient session expiration via native WebSocket support. The root cause is ...
2026-11-02 13:18 UTC -
web:www.aikido.dev
None of these is a clean fix , which is why the decision on how to remediate depends on knowing what package versions are running in production and why. This post will cover how AI has accelerated CVE detection and discovery, the upgrade trap, what CVE remediation actually involves in 2026 , and how to solve the CVE remediation problem.
2026-11-02 13:18 UTC -
web:www.cve.org
At cve .org, we provide the authoritative reference method for publicly known information-security vulnerabilities and exposures
2026-11-02 13:18 UTC -
web:www.oracle.com
This Critical Patch Update contains 1448 new security patches across the product families listed below. Please note that a My Oracle Support (MOS) note summarizing the content of this Critical Patch Update and other Oracle Software Security Assurance activities is located at July 2026 Critical Patch Update: Executive Summary and Analysis.
2026-11-02 13:18 UTC -
web:www.oracle.com
Prior Critical Patch Update and Critical Security Patch Update advisories should be reviewed for information regarding earlier published security patches. Refer to Critical Patch Updates, Critical Security Patch Updates, Security Alerts and Bulletins for information about Oracle Security advisories.
2026-11-02 13:18 UTC -
web:www.rapid7.com
CVE-2026-82559 : Apache Software Foundation Apache Wicket: Insufficient session expiration in Apache Wicket. View severity, references, and remediation details from Rapid7.
2026-11-02 13:18 UTC -
web:www.thehackerwire.com
How do I fix or mitigate CVE-2026-82559 ? To protect against CVE-2026-82559 , you should: (1) Apply the latest security patches from the vendor, (2) Check official security advisories for specific remediation steps, (3) Update affected software to the latest version, and (4) Monitor your systems for any signs of exploitation.
2026-11-02 13:18 UTC
AI Forensic Analysis
Only Available for Registered Users. Sign in to view.
Raw JSON
The full cvelistV5 record. Download as CVE-2026-82559.json.
{
"containers": {
"cna": {
"affected": [
{
"collectionURL": "https://repo.maven.apache.org/maven2",
"defaultStatus": "unaffected",
"packageName": "org.apache.wicket:wicket-native-websocket-core",
"packageURL": "pkg:maven/org.apache.wicket/wicket-native-websocket-core",
"product": "Apache Wicket",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThanOrEqual": "8.19.0",
"status": "affected",
"version": "8.0.0",
"versionType": "semver"
},
{
"lessThanOrEqual": "9.24.0",
"status": "affected",
"version": "9.0.0",
"versionType": "semver"
},
{
"lessThanOrEqual": "10.11.0",
"status": "affected",
"version": "10.0.0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Emond Papegaaij"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "Insufficient session expiration in Apache Wicket.<br><br>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.<br><br>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.<br><br>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.<br><br>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.<br>"
}
],
"value": "Insufficient session expiration in Apache Wicket.\n\norg.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.\n\nEnding 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.\n\nAn 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.\n\nThis 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": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 2.3,
"baseSeverity": "LOW",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "LOW",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "LOW",
"vulnIntegrityImpact": "LOW",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
},
{
"other": {
"content": {
"text": "moderate"
},
"type": "Textual description of severity"
},
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-613",
"description": "CWE-613 Insufficient Session Expiration",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-11-01T22:00:24.598Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://lists.apache.org/thread.html/5vkw9wz6gf135ccosj928zjs4hqy7bcv"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Wicket: WebSocket messages are processed against an HTTP session snapshot that survives invalidation",
"x_generator": {
"engine": "Vulnogram 0.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-82559",
"datePublished": "2026-11-01T22:00:24.598Z",
"dateReserved": "2026-08-29T20:41:19.285Z",
"dateUpdated": "2026-11-01T22:00:24.598Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}