What is the CVSS score of CVE-2026-82559?

CVE-2026-82559 has a CVSS 4.0 base score of 2.3 (Low). 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. EPSS exploitation probability: 0.3%.

Apache Wicket CVE-2026-82559

EUVD-2026-114889 LOW

Insufficient Session Expiration (CWE-613)

2026-11-01 apache

GHSA-5h36-fqxx-fjph

Apache Java Information Disclosure Apache Wicket Apache Software Foundation

2.3

CVSS 4.0 · Vendor: apache

View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

Access

Authenticate and open native WebSocket connection
Exploit

Session revoked server-side via container (logout/idle timeout)
Execution

Connection keeps resolving cached HttpSessionCopy identity
Impact

Perform privileged WebSocket operations under revoked signed-in state

Vulnerability Assessment

Weakness	CWE CWE-613 OWASP Top 10:2025 A07:2025 - Authentication Failures ASVS 5.0 V7 - Session Management Session expiration enforcement
Exploitation Conditions	The application must use Wicket's native WebSocket support on pages or shared resources that require an authenticated session, AND sessions must be ended through the servlet container rather than through Wicket - i.e. idle timeout, an HttpSession#invalidate() issued from a filter or security framework, container-managed logout, or session replacement. In that case the connection keeps resolving the org.apache.wicket.Session copied when it opened. The attacker must already hold such an authenticated, open WebSocket connection (PR:L). Limiting factors: a WebSocketBehavior bound to a page IS stopped by Wicket's own Session#invalidateNow()/AuthenticatedWebSession#invalidate()/#signOut() because those clear the page manager, so only container-driven termination is bypassed there; a WebSocketResource is NOT limited this way and outlives even Wicket's own sign-out, making it the primary exposure. Not affected: applications that do not use native WebSocket support, and deployments on containers that themselves close WebSocket connections when the underlying HTTP session is destroyed (a container property, not a Wicket behavior).
Impact	All decision signals point to genuinely low priority. The vendor-supplied CVSS 4.0 base score is 2.3 (Low): AV:N/AC:L/AT:P/PR:L/UI:N with limited vulnerable-system confidentiality and integrity impact (VC:L/VI:L/VA:N) and no subsequent-system impact. AT:P (attack requirement present) reflects that exploitation depends on a specific uncontrolled condition - a server-side session revocation occurring while an attacker's WebSocket connection is already open - and PR:L confirms the attacker must already hold an authenticated session, so this is an authenticated privilege-revocation-bypass, not an unauthenticated takeover of other users. The vuln.today decision label is 'monitor', consistent with the low score. No KEV listing, no EPSS score, and no PoC or exploit reference are present in the input, so exploitation status is 'no public exploit identified at time of analysis.' There is no conflict among the available signals - they consistently indicate a real but minor session-management weakness rather than a high-urgency issue. Missing data to note: EPSS probability is absent and PoC status is simply not provided (absence is not evidence of difficulty). This is a legitimate correctness/security fix to schedule in normal patching, not an emergency.
Exploit ScenarioDerived	An authenticated user opens a native Wicket WebSocket connection (for example to a WebSocketResource) and their session is then terminated server-side by the container - an idle timeout, a security-framework HttpSession#invalidate(), or a container-managed logout. Because every frame resolves the Wicket session from a copy frozen when the connection opened, authorization decisions inside WebSocket callbacks continue to see the still-signed-in identity, letting the connection keep operating under credentials that should have been revoked. No public exploit identified at time of analysis.

Monitor Track and reassess. Why: LOW severity (CVSS 0.1-3.9).

No patch listed yet 0.3% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Nov 01, 2026

Apache Wicket's native WebSocket support keeps serving a session after the servlet container has ended it: because each connection resolves its Wicket session from a copy taken at handshake time, an authenticated user holding an open socket continues to be treated as signed in - with the original session attributes and, in wicket-auth-roles applications, the signed-in state - for as long as the connection stays open. Affected are Wicket 8.0.0 through 8.19.0, 9.0.0 through 9.24.0 and 10.0.0 through 10.11.0 (older unsupported 6.x releases from 6.0.0 are also affected), but only where an application uses native WebSocket pages or WebSocketResource endpoints that require an authenticated session and terminates sessions through the container (idle timeout, filter or security-framework HttpSession#invalidate(), container-managed logout, or session replacement) rather than through Wicket. Severity is low (CVSS 4.0 base score 2.3; assessed CVSS 3.1 AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N) since the attacker must already hold such an authenticated connection, and no public exploit has been identified at time of analysis.

RemediationAI

Upgrade to a fixed release: Apache Wicket 8.20.0, 9.25.0 or 10.12.0, as recommended in the vendor advisory at https://lists.apache.org/thread.html/5vkw9wz6gf135ccosj928zjs4hqy7bcv. If an upgrade cannot be scheduled immediately, note that the vendor states updating is the complete fix and that the remaining practical controls are behavioural. First, drive session termination through Wicket rather than the container where possible: Session#invalidateNow(), and AuthenticatedWebSession#invalidate() and #signOut() which call it, remain effective for a WebSocketBehavior on a page because they clear the page manager and the connection can then no longer resolve the page it was opened for - the trade-off is that this does not cover WebSocketResource connections, which are served against a throwaway page and never consult the page manager. Second, prefer containers that close WebSocket connections themselves when the HTTP session they were opened under is destroyed, since the connection then ends regardless; this is a property of the container rather than of Wicket, so it must be verified per container and does not remove the need to patch. For WebSocketResource endpoints requiring authenticated sessions, restrict or disable them until the upgrade is in place, accepting the loss of that functionality.

Affected VersionsENISA

Apache Wicket 8.0.0 ≤8.19.0

Apache Wicket 9.0.0 ≤9.24.0

Apache Wicket 10.0.0 ≤10.11.0

Affected Packages

euvd apache_wicket no fix

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

The flaw is a CWE-613 insufficient session expiration issue rooted in how Wicket bridges the servlet container's request/response lifecycle into its WebSocket layer. org.apache.wicket.protocol.ws.WebSocketSettings#newWebSocketRequest() wraps the HTTP upgrade request in an org.apache.wicket.protocol.ws.api.ServletRequestCopy and retains it for the lifetime of the connection, because the container recycles the upgrade request once the handshake completes; that request copy is documented as deliberate. Alongside it, the container session is also copied into an org.apache.wicket.protocol.ws.api.HttpSessionCopy holding the attributes as they stood when the socket opened. The session copy is not necessary, since a session is not discarded at the end of a request, and it is the source of the defect: every subsequent frame resolves its Wicket session through ISessionStore#lookup(), which reads from the copy, so the connection is detached from the live container session. Writes go the same way - session attributes set over the connection land in the copy rather than in the real session, and a Session#invalidateNow() issued from inside a WebSocket callback invalidates the copy while leaving the container session valid. Confirmed exposure differs by deployment mode: a WebSocketBehavior bound to a page is still stopped by Wicket-side termination because Session#invalidateNow() and AuthenticatedWebSession#invalidate()/#signOut() clear the page manager, after which the connection can no longer resolve the page; a WebSocketResource is not limited 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. Containers that themselves close WebSocket connections when the underlying HTTP session is destroyed end the connection regardless - that is a container property, not a Wicket behaviour - and applications not using the native WebSocket support are unaffected.

Know when Apache Wicket gets its next vulnerability

Watch products and get an email when something new is published
Check this CVE against your own stack and servers
Exploit and PoC references, threat intelligence from 22 sources

Continue with Google Continue with GitHub

No credit card · 7-day full trial

Severity by source

Vendor (apache) PRIMARY 2.3 LOW

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

vuln.today AI 4.2 MEDIUM

Requires a pre-authenticated open WebSocket (PR:L) and a server-side session revocation during that connection (AC:H maps the 4.0 AT:P condition); limited C/I impact, no availability impact.

3.1 AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N

4.0 AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (apache).

CVSS VectorVendor: apache

Attack Vector

Network

Attack Complexity

Low

Attack Requirements

Present

Privileges Required

Low

User Interaction

None

Vulnerable system: Confidentiality

Low

Vulnerable system: Integrity

Low

Vulnerable system: Availability

None

Subsequent system: Confidentiality

None

Subsequent system: Integrity

None

Subsequent system: Availability

None

DescriptionCVE.org

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.

Threat Intelligence Overview

EPSS Score

0.3%

Top 78% exploitable

Prevalence

Low

niche Java component web framework; native WebSocket support used by a minority of deployments

Data Quality

3 sources

Confidence: Low

EUVD

NVD

CVE.org

EPSS

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue

Severity LOW

CISA KEV No

Public POC No

EPSS 0.3%

Patch available No

Active threat No

Deciding rule

LOW severity (CVSS 0.1-3.9)

What every action level means

Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.

Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.

This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.

This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.

Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived

Defer

Exploitation· derived

None

System Exposure· derived

Open

Automatable· derived

Human Impact· derived

Low

Priority Score

Low Medium High Critical

KEV: 0

EPSS: 0

CVSS: +12

PoC: 0

Weaponized: 0

Threat intel: 0

Gov advisory: 0

Attack Technique

Information Disclosure MEDIUM

Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.