CVE-2026-82898
📛 CVE Title
Apache Wicket: A cross-origin listener invocation stopped by a login wall is replayed after the user signs in
Description
Incorrect order of security checks in Apache Wicket. org.apache.wicket.protocol.http.ResourceIsolationRequestCycleListener obtains the page a request targets before it consults its resource isolation policies, because those policies are passed that page. Obtaining the page instantiates it, and instantiating a page runs the configured org.apache.wicket.authorization.IAuthorizationStrategy. An application that refuses an unauthenticated visitor by throwing org.apache.wicket.RestartResponseAtInterceptPageException therefore throws it from inside the isolation listener, before any policy has run. That exception replaces the request handler, so the policies are never consulted and a request that came from another origin is not refused. The exception's constructor stores the URL of the request it interrupted, so that Component#continueToOriginalDestination() can resume it once the visitor has signed in. The stored URL is the one the policies would have refused. On sign in Wicket redirects to it, and that redirect is same-origin, so the policies allow it and the listener runs in the newly authenticated session. The whole URL is stored, its query string included, so an ordinary org.apache.wicket.markup.html.form.Form is resumed with the field values the original request carried in its query string and Form#onSubmit() runs with values another origin chose. A form POST is not needed for this; a plain top-level navigation carries them. An application is affected where it registers ResourceIsolationRequestCycleListener, which is opt-in and is not registered by default, and where it refuses unauthorized access with RestartResponseAtInterceptPageException followed by continueToOriginalDestination(). No application override is involved on that path: IAuthorizationStrategy#isInstantiationAuthorized() documents throwing that exception, org.apache.wicket.authroles.authentication.AuthenticatedWebApplication throws it and org.apache.wicket.authroles.authentication.panel.UsernamePasswordPanel continues to the original destination, and org.apache.wicket.authorization.strategies.page.SimplePageAuthorizationStrategy in wicket-core installs the same pattern. A visitor who is already signed in is not affected, because no interception occurs. Request-body parameters stored alongside the intercepted URL are not applied to the resumed form: the resumption is a redirect, so the resumed request is a GET, and form components read their values from the query string on a GET. As a workaround, refuse unauthorized access with org.apache.wicket.RestartResponseException instead, which does not store the original destination; visitors are then not returned to the page they asked for after signing in. This issue affects Apache Wicket: from 9.1.0 through 9.24.0, from 10.0.0 through 10.11.0. Releases before 9.1.0, which is every 8.x release and 9.0.0, are not affected, because the resource isolation this issue concerns was introduced in 9.1.0. They are not protected either. Their only cross-origin defence is org.apache.wicket.protocol.http.CsrfPreventionRequestCycleListener, which works out where a request came from by reading its Origin header and falling back to its Referer header. Neither header need arrive: a browser does not send Origin on the plain GET a link uses, and the document on the other origin decides through its own referrer policy whether a Referer reaches the application at all. That mechanism therefore never made the guarantee the Fetch Metadata based policy makes, and on those releases a listener invocation from another origin is not reliably refused in the first place. Anyone on a release before 9.1.0 who wants this protection should upgrade to 9.x or 10.x and register ResourceIsolationRequestCycleListener. Users are recommended to upgrade to version 9.25.0 or 10.12.0, which fix the issue.
Overview
- State
- PUBLISHED
- Assigner (CNA)
- apache
- CVSS severity
- LOW
- CVSS score
- 2.1 / 10
- CVSS vector
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N- Effective score
- 2.1 / 10 LOW source: CNA overview
- CWE(s)
-
CWE-696 - Reserved
- 2026-08-31
- Published
- 2026-11-01 22:14 UTC
- Last updated
- 2026-11-01 22:14 UTC
- Source
- https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/82xxx/CVE-2026-82898.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: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-114893 - Assigner
- apache
- Published
- Nov 1, 2026, 10:14:06 PM
- Updated
- Nov 1, 2026, 10:14:06 PM
- EUVD base score (CVSS 4.0)
-
2.1 / 10
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N - EUVD-reported EPSS
- 0.0000
- Vendors
- Apache Software Foundation
- Products
-
Apache Wicket (10.0.0 ≤10.11.0)Apache Wicket (9.1.0 ≤9.24.0)
- Aliases
-
GHSA-4f8f-rp3w-cwx9
ENISA description: Incorrect order of security checks in Apache Wicket. org.apache.wicket.protocol.http.ResourceIsolationRequestCycleListener obtains the page a request targets before it consults its resource isolation policies, because those policies are passed that page. Obtaining the page instantiates it, and instantiating a page runs the configured org.apache.wicket.authorization.IAuthorizationStrategy. An application that refuses an unauthenticated visitor by throwing org.apache.wicket.RestartResponseAtInterceptPageException therefore throws it from inside the isolation listener, before any policy has run. That exception replaces the request handler, so the policies are never consulted and a request that came from another origin is not refused. The exception's constructor stores the URL of the request it interrupted, so that Component#continueToOriginalDestination() can resume it once the visitor has signed in. The stored URL is the one the policies would have refused. On sign in Wicket redirects to it, and that redirect is same-origin, so the policies allow it and the listener runs in the newly authenticated session. The whole URL is stored, its query string included, so an ordinary org.apache.wicket.markup.html.form.Form is resumed with the field values the original request carried in its query string and Form#onSubmit() runs with values another origin chose. A form POST is not needed for this; a plain top-level navigation carries them. An application is affected where it registers ResourceIsolationRequestCycleListener, which is opt-in and is not registered by default, and where it refuses unauthorized access with RestartResponseAtInterceptPageException followed by continueToOriginalDestination(). No application override is involved on that path: IAuthorizationStrategy#isInstantiationAuthorized() documents throwing that exception, org.apache.wicket.authroles.authentication.AuthenticatedWebApplication throws it and org.apache.wicket.authroles.authentication.panel.UsernamePasswordPanel continues to the original destination, and org.apache.wicket.authorization.strategies.page.SimplePageAuthorizationStrategy in wicket-core installs the same pattern. A visitor who is already signed in is not affected, because no interception occurs. Request-body parameters stored alongside the intercepted URL are not applied to the resumed form: the resumption is a redirect, so the resumed request is a GET, and form components read their values from the query string on a GET. As a workaround, refuse unauthorized access with org.apache.wicket.RestartResponseException instead, which does not store the original destination; visitors are then not returned to the page they asked for after signing in. This issue affects Apache Wicket: from 9.1.0 through 9.24.0, from 10.0.0 through 10.11.0. Releases before 9.1.0, which is every 8.x release and 9.0.0, are not affected, because the resource isolation this issue concerns was introduced in 9.1.0. They are not protected either. Their only cross-origin defence is org.apache.wicket.protocol.http.CsrfPreventionRequestCycleListener, which works out where a request came from by reading its Origin header and falling back to its Referer header. Neither header need arrive: a browser does not send Origin on the plain GET a link uses, and the document on the other origin decides through its own referrer policy whether a Referer reaches the application at all. That mechanism therefore never made the guarantee the Fetch Metadata based policy makes, and on those releases a listener invocation from another origin is not reliably refused in the first place. Anyone on a release before 9.1.0 who wants this protection should upgrade to 9.x or 10.x and register ResourceIsolationRequestCycleListener. Users are recommended to upgrade to version 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 |
9.1.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/bm4mlwsgftxfg345zvdqj0skg1mktpyp security@apache.org
Remediations (10)
-
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 13:18 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 13:18 UTC -
web:dashboard.patch.io
Access your Patch account by logging in.
2026-11-02 13:18 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 13:18 UTC -
web:support.icewarp.com
Vulnerabilities have been disclosed in PHP and are tracked as CVE - 2026 -109618, CVE - 2026 -109619 and CVE - 2026 -115560. IceWarp Server bundles PHP, so installations running an unpatched PHP version may be affected. IceWarp is providing packages with a patched PHP for supported versions. Customers should apply the patch matching their IceWarp version and operating system as soon as possible.
2026-11-02 13:18 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 13:18 UTC -
web:www.nexusmods.com
Retired: the official 2.5 updates of RED4ext, ArchiveXL, TweakXL and Codeware are out, so use those. Still here: technical notes for mod authors on what patch 2.5 changed for plugins, plus source diff
2026-11-02 13:18 UTC -
web:www.oracle.com
This Critical Patch Update contains 481 new security patches across the product families listed below. Please note that an MOS note summarizing the content of this Critical Patch Update and other Oracle Software Security Assurance activities is located at April 2026 Critical Patch Update: Executive Summary and Analysis.
2026-11-02 13:18 UTC -
web:www.oracle.com
Text Form of Oracle Critical Patch Update - October 2026 Risk Matrices This document provides the text form of the October 2026 Advisory Risk Matrices. Please note that the CVE IDs in this document correspond to the same CVE IDs in the October 2026 Advisory. This page contains the following text format Risk Matrices: Oracle Database Server ...
2026-11-02 13:18 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 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-82898.json.
{
"containers": {
"cna": {
"affected": [
{
"collectionURL": "https://repo.maven.apache.org/maven2",
"defaultStatus": "unaffected",
"packageName": "org.apache.wicket:wicket-core",
"packageURL": "pkg:maven/org.apache.wicket/wicket-core",
"product": "Apache Wicket",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThanOrEqual": "9.24.0",
"status": "affected",
"version": "9.1.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": "Incorrect order of security checks in Apache Wicket.<br><br>org.apache.wicket.protocol.http.ResourceIsolationRequestCycleListener obtains the page a request targets before it consults its resource isolation policies, because those policies are passed that page. Obtaining the page instantiates it, and instantiating a page runs the configured org.apache.wicket.authorization.IAuthorizationStrategy. An application that refuses an unauthenticated visitor by throwing org.apache.wicket.RestartResponseAtInterceptPageException therefore throws it from inside the isolation listener, before any policy has run. That exception replaces the request handler, so the policies are never consulted and a request that came from another origin is not refused.<br><br>The exception's constructor stores the URL of the request it interrupted, so that Component#continueToOriginalDestination() can resume it once the visitor has signed in. The stored URL is the one the policies would have refused. On sign in Wicket redirects to it, and that redirect is same-origin, so the policies allow it and the listener runs in the newly authenticated session. The whole URL is stored, its query string included, so an ordinary org.apache.wicket.markup.html.form.Form is resumed with the field values the original request carried in its query string and Form#onSubmit() runs with values another origin chose. A form POST is not needed for this; a plain top-level navigation carries them.<br><br>An application is affected where it registers ResourceIsolationRequestCycleListener, which is opt-in and is not registered by default, and where it refuses unauthorized access with RestartResponseAtInterceptPageException followed by continueToOriginalDestination(). No application override is involved on that path: IAuthorizationStrategy#isInstantiationAuthorized() documents throwing that exception, org.apache.wicket.authroles.authentication.AuthenticatedWebApplication throws it and org.apache.wicket.authroles.authentication.panel.UsernamePasswordPanel continues to the original destination, and org.apache.wicket.authorization.strategies.page.SimplePageAuthorizationStrategy in wicket-core installs the same pattern. A visitor who is already signed in is not affected, because no interception occurs. Request-body parameters stored alongside the intercepted URL are not applied to the resumed form: the resumption is a redirect, so the resumed request is a GET, and form components read their values from the query string on a GET.<br><br>As a workaround, refuse unauthorized access with org.apache.wicket.RestartResponseException instead, which does not store the original destination; visitors are then not returned to the page they asked for after signing in.<br><br>This issue affects Apache Wicket: from 9.1.0 through 9.24.0, from 10.0.0 through 10.11.0.<br><br>Releases before 9.1.0, which is every 8.x release and 9.0.0, are not affected, because the resource isolation this issue concerns was introduced in 9.1.0. They are not protected either. Their only cross-origin defence is org.apache.wicket.protocol.http.CsrfPreventionRequestCycleListener, which works out where a request came from by reading its Origin header and falling back to its Referer header. Neither header need arrive: a browser does not send Origin on the plain GET a link uses, and the document on the other origin decides through its own referrer policy whether a Referer reaches the application at all. That mechanism therefore never made the guarantee the Fetch Metadata based policy makes, and on those releases a listener invocation from another origin is not reliably refused in the first place. Anyone on a release before 9.1.0 who wants this protection should upgrade to 9.x or 10.x and register ResourceIsolationRequestCycleListener.<br><br>Users are recommended to upgrade to version 9.25.0 or 10.12.0, which fix the issue.<br>"
}
],
"value": "Incorrect order of security checks in Apache Wicket.\n\norg.apache.wicket.protocol.http.ResourceIsolationRequestCycleListener obtains the page a request targets before it consults its resource isolation policies, because those policies are passed that page. Obtaining the page instantiates it, and instantiating a page runs the configured org.apache.wicket.authorization.IAuthorizationStrategy. An application that refuses an unauthenticated visitor by throwing org.apache.wicket.RestartResponseAtInterceptPageException therefore throws it from inside the isolation listener, before any policy has run. That exception replaces the request handler, so the policies are never consulted and a request that came from another origin is not refused.\n\nThe exception's constructor stores the URL of the request it interrupted, so that Component#continueToOriginalDestination() can resume it once the visitor has signed in. The stored URL is the one the policies would have refused. On sign in Wicket redirects to it, and that redirect is same-origin, so the policies allow it and the listener runs in the newly authenticated session. The whole URL is stored, its query string included, so an ordinary org.apache.wicket.markup.html.form.Form is resumed with the field values the original request carried in its query string and Form#onSubmit() runs with values another origin chose. A form POST is not needed for this; a plain top-level navigation carries them.\n\nAn application is affected where it registers ResourceIsolationRequestCycleListener, which is opt-in and is not registered by default, and where it refuses unauthorized access with RestartResponseAtInterceptPageException followed by continueToOriginalDestination(). No application override is involved on that path: IAuthorizationStrategy#isInstantiationAuthorized() documents throwing that exception, org.apache.wicket.authroles.authentication.AuthenticatedWebApplication throws it and org.apache.wicket.authroles.authentication.panel.UsernamePasswordPanel continues to the original destination, and org.apache.wicket.authorization.strategies.page.SimplePageAuthorizationStrategy in wicket-core installs the same pattern. A visitor who is already signed in is not affected, because no interception occurs. Request-body parameters stored alongside the intercepted URL are not applied to the resumed form: the resumption is a redirect, so the resumed request is a GET, and form components read their values from the query string on a GET.\n\nAs a workaround, refuse unauthorized access with org.apache.wicket.RestartResponseException instead, which does not store the original destination; visitors are then not returned to the page they asked for after signing in.\n\nThis issue affects Apache Wicket: from 9.1.0 through 9.24.0, from 10.0.0 through 10.11.0.\n\nReleases before 9.1.0, which is every 8.x release and 9.0.0, are not affected, because the resource isolation this issue concerns was introduced in 9.1.0. They are not protected either. Their only cross-origin defence is org.apache.wicket.protocol.http.CsrfPreventionRequestCycleListener, which works out where a request came from by reading its Origin header and falling back to its Referer header. Neither header need arrive: a browser does not send Origin on the plain GET a link uses, and the document on the other origin decides through its own referrer policy whether a Referer reaches the application at all. That mechanism therefore never made the guarantee the Fetch Metadata based policy makes, and on those releases a listener invocation from another origin is not reliably refused in the first place. Anyone on a release before 9.1.0 who wants this protection should upgrade to 9.x or 10.x and register ResourceIsolationRequestCycleListener.\n\nUsers are recommended to upgrade to version 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.1,
"baseSeverity": "LOW",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "NONE",
"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:N/UI:A/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "NONE",
"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-696",
"description": "CWE-696 Incorrect Behavior Order",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-11-01T22:14:06.838Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://lists.apache.org/thread.html/bm4mlwsgftxfg345zvdqj0skg1mktpyp"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Wicket: A cross-origin listener invocation stopped by a login wall is replayed after the user signs in",
"x_generator": {
"engine": "Vulnogram 0.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2026-82898",
"datePublished": "2026-11-01T22:14:06.838Z",
"dateReserved": "2026-08-31T09:20:33.399Z",
"dateUpdated": "2026-11-01T22:14:06.838Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}