CVE-2026-82840
📛 CVE Title
Apache Wicket: The session id is renewed only on the first sign in, not on re-authentication
Description
Session fixation in Apache Wicket. org.apache.wicket.authroles.authentication.AuthenticatedWebSession is the authentication base class of Wicket's role-based security module, and its signIn(String, String) method is the entry point through which an application authenticates a session. Renewing the container session id at that point is the standard defence against an attacker who has fixed a session id in a victim's browser, and Wicket provides that renewal as org.apache.wicket.Session#changeSessionId(), whose documentation directs callers to invoke it on login for exactly that reason. AuthenticatedWebSession#signIn(String, String) calls it inside a guard that succeeds only on the first transition of the session's signed-in flag. The session id is therefore renewed when a session first signs in, and is not renewed when a session that is already signed in authenticates again. signIn(String, String) returns true either way, so neither the caller nor the application can tell that the renewal did not happen. An application is affected where it authenticates through AuthenticatedWebSession, which AuthenticatedWebApplication requires and which the shipped UsernamePasswordPanel uses, and where a session that is already signed in can authenticate again: a step-up prompt before a sensitive action, an account switch, or simply a sign-in form that stays reachable once the user is signed in. Nothing in the module hides that form from a signed-in session. Reaching the defect also requires an attacker to place a session id of their choosing in the victim's browser. JSESSIONID is set by the servlet container rather than by Wicket, so that needs a position Wicket does not grant, such as control of a host under the same registrable domain or a container configured to carry the session id in the URL, and the planted session has to be one the attacker has already signed in on, because a session that is not yet signed in does have its id renewed by the victim's authentication. An authentication attempt that fails signs the session out and closes the window. Applications that renew the session id in their own code after a successful authentication are not affected. As a workaround, renew the session id from the application's own code on every successful authentication, by calling Session#changeSessionId() at the end of the authenticate(String, String) implementation. This issue affects Apache Wicket: from 8.18.0 through 8.19.0, from 9.23.0 through 9.24.0, from 10.9.0 through 10.11.0. 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
- HIGH
- CVSS score
- 7.2 / 10
- CVSS vector
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:A/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N- Effective score
- 7.2 / 10 HIGH source: CNA overview
- CWE(s)
-
CWE-384 - Reserved
- 2026-08-31
- Published
- 2026-11-01 22:05 UTC
- Last updated
- 2026-11-01 22:05 UTC
- Source
- https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/82xxx/CVE-2026-82840.json
- Linked Threat
- CVE-2026-82840 — Apache Wicket: The session id is renewed only on the first sign in, not on re-authentication
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:48 UTC
- NVD last modified
- 2026-11-01 22:17:48 UTC
NVD / KEV / EPSS data refreshed 2026-11-02 13:54 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-114892 - Assigner
- apache
- Published
- Nov 1, 2026, 10:05:07 PM
- Updated
- Nov 1, 2026, 10:05:07 PM
- EUVD base score (CVSS 4.0)
-
7.2 / 10
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:A/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N - EUVD-reported EPSS
- 0.0000
- Vendors
- Apache Software Foundation
- Products
-
Apache Wicket (9.23.0 ≤9.24.0)Apache Wicket (8.18.0 ≤8.19.0)Apache Wicket (10.9.0 ≤10.11.0)
- Aliases
-
GHSA-qqf3-jqrg-fm5r
ENISA description: Session fixation in Apache Wicket. org.apache.wicket.authroles.authentication.AuthenticatedWebSession is the authentication base class of Wicket's role-based security module, and its signIn(String, String) method is the entry point through which an application authenticates a session. Renewing the container session id at that point is the standard defence against an attacker who has fixed a session id in a victim's browser, and Wicket provides that renewal as org.apache.wicket.Session#changeSessionId(), whose documentation directs callers to invoke it on login for exactly that reason. AuthenticatedWebSession#signIn(String, String) calls it inside a guard that succeeds only on the first transition of the session's signed-in flag. The session id is therefore renewed when a session first signs in, and is not renewed when a session that is already signed in authenticates again. signIn(String, String) returns true either way, so neither the caller nor the application can tell that the renewal did not happen. An application is affected where it authenticates through AuthenticatedWebSession, which AuthenticatedWebApplication requires and which the shipped UsernamePasswordPanel uses, and where a session that is already signed in can authenticate again: a step-up prompt before a sensitive action, an account switch, or simply a sign-in form that stays reachable once the user is signed in. Nothing in the module hides that form from a signed-in session. Reaching the defect also requires an attacker to place a session id of their choosing in the victim's browser. JSESSIONID is set by the servlet container rather than by Wicket, so that needs a position Wicket does not grant, such as control of a host under the same registrable domain or a container configured to carry the session id in the URL, and the planted session has to be one the attacker has already signed in on, because a session that is not yet signed in does have its id renewed by the victim's authentication. An authentication attempt that fails signs the session out and closes the window. Applications that renew the session id in their own code after a successful authentication are not affected. As a workaround, renew the session id from the application's own code on every successful authentication, by calling Session#changeSessionId() at the end of the authenticate(String, String) implementation. This issue affects Apache Wicket: from 8.18.0 through 8.19.0, from 9.23.0 through 9.24.0, from 10.9.0 through 10.11.0. 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.18.0 (affected),
9.23.0 (affected),
10.9.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/q812kjb74x2pt6956w0pcmkc4wwj95l9 security@apache.org
Remediations (10)
Remediations are stored against the linked Threat row; the list below is deduplicated across both pages.
-
web:blogs.oracle.com
For more information about the Critical Patch Update program, see the security vulnerability remediation practices page located on the Oracle Trust Center.
2026-11-02 11:27 UTC -
web:community.spiceworks.com
Another record-breaking patch cycle…1408 CVE's , .NET 8 and 9 reach EOS next month (start planning, if you're not already) Microsoft Publisher starts vanishing and place your bets now, on how much breaks between now and next month!
2026-11-02 11:27 UTC -
web:crimsondesert.pearlabyss.com
Fellow Greymanes, Here are the fixes and improvements that have been added this patch . Update ScheduleThe patch is rolling out across all platforms. Please refer to the Update section below to see the state of the patch for each platform. UpdateSteam (PC): Patch available now Steam (Mac): Patch ...
2026-11-02 11:27 UTC -
web:epatch.pa.gov
Why does PATCH exist? Its purpose is to better enable the public to obtain criminal history record checks. The repository was created and is maintained in accordance with Pennsylvania's Criminal History Information Act contained in Chapter 91 of Title 18, Crimes Code. This Act also directs the Pennsylvania State Police (PSP) to disseminate criminal history data to criminal justice agencies ...
2026-11-02 11:27 UTC -
web:sec.cloudapps.cisco.com
As part of Cisco's ongoing commitment to proactive security and product quality, engineering teams conducted a comprehensive internal security review. This review resulted in software hardening releases that address multiple internally discovered vulnerabilities. These vulnerabilities were found during internal testing and are not known to be actively exploited. To assist customers in patching ...
2026-11-02 11:27 UTC -
web:support.esri.com
This patch deals specifically with the issues listed below under Issues addressed with this patch . As part of the patch installation, the ArcGIS Server service is stopped and restarted. The restart may take several minutes depending on the number of services published on the ArcGIS Server site. This patch can be uninstalled as outlined in the Uninstalling this patch on Windows and Uninstalling ...
2026-11-02 11:27 UTC -
web:windowsreport.com
Windows 11 October 2026 Patch Tuesady update, KB5127648, is reportedly causing serious headaches for some business networks. The latest Patch Tuesday update, which appears to have fixed previously reported the Group Policy failure, has apparently broken WPA2-Enterprise Wi-Fi and wired 802.1X authentication.
2026-11-02 11:27 UTC -
web:www.ivanti.com
Microsoft's October Patch Tuesday resolved 1,407 CVEs , including 78 Critical fixes. Priority focus: actively exploited Windows Shell zero-day CVE - 2026 -96951. Also address publicly disclosed CVE - 2026 -108398 and secure edge devices (NetScaler, FortiMail, Ivanti) against ongoing attacks.
2026-11-02 11:27 UTC -
web:www.microsoft.com
Resources you patch manually: nothing is installed automatically for you. Apply the updates now, starting with internet-facing systems, and then restart or reimage. Software you installed or bundled: you update it no matter how you patch . Rebuild and redeploy containers and custom images.
2026-11-02 11:27 UTC -
web:www.veeam.com
Vulnerabilities Resolved in Veeam ONE 13.1 Patch 1 Veeam® is committed to ensuring its products protect customers from potential risks. As part of that commitment, we operate a Vulnerability Disclosure Program (VDP) for all Veeam products and perform extensive internal code audits. When a vulnerability is identified, our team promptly develops a patch to address and mitigate the risk. In line ...
2026-11-02 11:27 UTC
AI Forensic Analysis
Only Available for Registered Users. Sign in to view.
Raw JSON
The full cvelistV5 record. Download as CVE-2026-82840.json.
{
"containers": {
"cna": {
"affected": [
{
"collectionURL": "https://repo.maven.apache.org/maven2",
"defaultStatus": "unaffected",
"packageName": "org.apache.wicket:wicket-auth-roles",
"packageURL": "pkg:maven/org.apache.wicket/wicket-auth-roles",
"product": "Apache Wicket",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThanOrEqual": "8.19.0",
"status": "affected",
"version": "8.18.0",
"versionType": "semver"
},
{
"lessThanOrEqual": "9.24.0",
"status": "affected",
"version": "9.23.0",
"versionType": "semver"
},
{
"lessThanOrEqual": "10.11.0",
"status": "affected",
"version": "10.9.0",
"versionType": "semver"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Emond Papegaaij"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "Session fixation in Apache Wicket.<br><br>org.apache.wicket.authroles.authentication.AuthenticatedWebSession is the authentication base class of Wicket's role-based security module, and its signIn(String, String) method is the entry point through which an application authenticates a session. Renewing the container session id at that point is the standard defence against an attacker who has fixed a session id in a victim's browser, and Wicket provides that renewal as org.apache.wicket.Session#changeSessionId(), whose documentation directs callers to invoke it on login for exactly that reason.<br><br>AuthenticatedWebSession#signIn(String, String) calls it inside a guard that succeeds only on the first transition of the session's signed-in flag. The session id is therefore renewed when a session first signs in, and is not renewed when a session that is already signed in authenticates again. signIn(String, String) returns true either way, so neither the caller nor the application can tell that the renewal did not happen.<br><br>An application is affected where it authenticates through AuthenticatedWebSession, which AuthenticatedWebApplication requires and which the shipped UsernamePasswordPanel uses, and where a session that is already signed in can authenticate again: a step-up prompt before a sensitive action, an account switch, or simply a sign-in form that stays reachable once the user is signed in. Nothing in the module hides that form from a signed-in session. Reaching the defect also requires an attacker to place a session id of their choosing in the victim's browser. JSESSIONID is set by the servlet container rather than by Wicket, so that needs a position Wicket does not grant, such as control of a host under the same registrable domain or a container configured to carry the session id in the URL, and the planted session has to be one the attacker has already signed in on, because a session that is not yet signed in does have its id renewed by the victim's authentication. An authentication attempt that fails signs the session out and closes the window. Applications that renew the session id in their own code after a successful authentication are not affected.<br><br>As a workaround, renew the session id from the application's own code on every successful authentication, by calling Session#changeSessionId() at the end of the authenticate(String, String) implementation.<br><br>This issue affects Apache Wicket: from 8.18.0 through 8.19.0, from 9.23.0 through 9.24.0, from 10.9.0 through 10.11.0.<br><br>Users are recommended to upgrade to version 8.20.0, 9.25.0 or 10.12.0, which fix the issue.<br>"
}
],
"value": "Session fixation in Apache Wicket.\n\norg.apache.wicket.authroles.authentication.AuthenticatedWebSession is the authentication base class of Wicket's role-based security module, and its signIn(String, String) method is the entry point through which an application authenticates a session. Renewing the container session id at that point is the standard defence against an attacker who has fixed a session id in a victim's browser, and Wicket provides that renewal as org.apache.wicket.Session#changeSessionId(), whose documentation directs callers to invoke it on login for exactly that reason.\n\nAuthenticatedWebSession#signIn(String, String) calls it inside a guard that succeeds only on the first transition of the session's signed-in flag. The session id is therefore renewed when a session first signs in, and is not renewed when a session that is already signed in authenticates again. signIn(String, String) returns true either way, so neither the caller nor the application can tell that the renewal did not happen.\n\nAn application is affected where it authenticates through AuthenticatedWebSession, which AuthenticatedWebApplication requires and which the shipped UsernamePasswordPanel uses, and where a session that is already signed in can authenticate again: a step-up prompt before a sensitive action, an account switch, or simply a sign-in form that stays reachable once the user is signed in. Nothing in the module hides that form from a signed-in session. Reaching the defect also requires an attacker to place a session id of their choosing in the victim's browser. JSESSIONID is set by the servlet container rather than by Wicket, so that needs a position Wicket does not grant, such as control of a host under the same registrable domain or a container configured to carry the session id in the URL, and the planted session has to be one the attacker has already signed in on, because a session that is not yet signed in does have its id renewed by the victim's authentication. An authentication attempt that fails signs the session out and closes the window. Applications that renew the session id in their own code after a successful authentication are not affected.\n\nAs a workaround, renew the session id from the application's own code on every successful authentication, by calling Session#changeSessionId() at the end of the authenticate(String, String) implementation.\n\nThis issue affects Apache Wicket: from 8.18.0 through 8.19.0, from 9.23.0 through 9.24.0, from 10.9.0 through 10.11.0.\n\nUsers 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": 7.2,
"baseSeverity": "HIGH",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "LOW",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "ACTIVE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:A/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH",
"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-384",
"description": "CWE-384 Session Fixation",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-11-01T22:05:07.392Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://lists.apache.org/thread.html/q812kjb74x2pt6956w0pcmkc4wwj95l9"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Wicket: The session id is renewed only on the first sign in, not on re-authentication",
"x_generator": {
"engine": "Vulnogram 0.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-82840",
"datePublished": "2026-11-01T22:05:07.392Z",
"dateReserved": "2026-08-31T08:07:14.885Z",
"dateUpdated": "2026-11-01T22:05:07.392Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}