EUVD-2026-114893
GHSA-4f8f-rp3w-cwx9
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessHost malicious cross-origin page
-
DeliveryTrigger top-level navigation to protected Wicket URL with crafted query params
-
ExploitInterception stores original destination URL
-
ExecutionVictim signs in, same-origin redirect resumes request
-
ImpactForm onSubmit() executes with attacker-chosen values
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Incorrect behavior order
|
| Exploitation Conditions | Exploitable only where the application (1) registers org.apache.wicket.protocol.http.ResourceIsolationRequestCycleListener, which is opt-in and NOT enabled by default, and (2) refuses unauthorized access by throwing RestartResponseAtInterceptPageException followed by Component#continueToOriginalDestination() - the standard pattern used by AuthenticatedWebApplication, UsernamePasswordPanel, and SimplePageAuthorizationStrategy, needing no application override. Affected versions are 9.1.0-9.24.0 and 10.0.0-10.11.0. Limiting factors: requires victim user interaction (the victim must follow the attacker's top-level navigation and then sign in); already-authenticated visitors are unaffected because no interception occurs; impact is confined to form fields read from the query string on a GET - request-body parameters stored alongside the URL are NOT re-applied, so only forms that read values from the query string are affected. Releases before 9.1.0 do not have this feature and are out of scope. |
| Impact | All signals converge on low real-world priority. The CVSS 4.0 base score is 2.1, and the independently reasonable vector (AV:N/AC:L/AT:P/PR:N/UI:A) reflects a network-reachable but condition-gated issue: AT:P marks an attack requirement - the specific intercept-then-sign-in sequence must occur - and UI:A means a victim must actively navigate and then authenticate. Impact is limited to VI:L (an authenticated form is resumed with attacker-chosen GET/query-string values); there is no confidentiality (VC:N) or availability (VA:N) impact and no scope change. The vuln.today Decision label is 'monitor', consistent with the low score. No EPSS score was provided and the issue is not in CISA KEV, so there is no exploitation-probability or active-exploitation signal; no public exploit identified at time of analysis - the sole reference is an Apache mailing-list announcement thread, not exploit code. Crucially, the vulnerable path is opt-in and not present by default: it requires registering ResourceIsolationRequestCycleListener AND refusing unauthorized access via RestartResponseAtInterceptPageException + continueToOriginalDestination(). One caveat on labeling: the input Tag 'Authentication Bypass' overstates the mechanism - the victim still authenticates normally; this is a cross-origin resource-isolation (Fetch Metadata) bypass driven by an incorrect order of security checks (CWE-696), not a credential or auth bypass. Net: a genuine low-severity hardening gap, not an urgent threat. |
| Exploit ScenarioDerived | An attacker hosts a cross-origin page that triggers a plain top-level navigation (a link, not a POST) to a protected Wicket page, carrying attacker-chosen form field values in the query string. An unauthenticated victim is intercepted and the interrupted URL (with its query string) is stored; after the victim signs in, Wicket issues a same-origin redirect to that stored URL, which passes resource isolation, resuming the targeted Form so Form#onSubmit() runs with the attacker's values. No public exploit identified at time of analysis. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Nov 01, 2026
Incorrect ordering of security checks in Apache Wicket 9.1.0 through 9.24.0 and 10.0.0 through 10.11.0 allows a cross-origin request to bypass the opt-in ResourceIsolationRequestCycleListener when an application refuses unauthenticated visitors with RestartResponseAtInterceptPageException and later calls continueToOriginalDestination(), so a victim who follows an attacker-supplied top-level navigation and then signs in resumes a form whose query-string field values were chosen by another origin. Impact is confined to integrity of form values read from the query string on the resumed GET; request-body parameters stored with the intercepted URL are not replayed, already-authenticated visitors are unaffected, and user interaction is required. The vulnerability is assessed as low severity (CVSS 3.1 base 2.1-equivalent integrity-only impact) and no public exploit identified at time of analysis.
RemediationAI
Upgrade to Apache Wicket 9.25.0 on the 9.x branch or 10.12.0 on the 10.x branch, which fix the ordering defect; confirm after upgrading that ResourceIsolationRequestCycleListener is registered, since the protection is opt-in and absent by default. Applications that cannot upgrade immediately can replace RestartResponseAtInterceptPageException on the authorization failure path with org.apache.wicket.RestartResponseException, which does not store the original destination - the trade-off is that users are no longer returned to the page they requested after signing in, and the original destination must be handled by other means. Releases before 9.1.0 (8.x and 9.0.0) are not affected by this flaw but lack equivalent Fetch Metadata protection; organizations wanting that guarantee must upgrade to 9.x or 10.x and register the listener. Vendor advisory: https://lists.apache.org/thread.html/bm4mlwsgftxfg345zvdqj0skg1mktpyp.
Affected VersionsENISA
Affected Packages
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
CWE-696 (Incorrect Behavior Order) is the root cause: ResourceIsolationRequestCycleListener must consult its Fetch Metadata-based resource isolation policies before the target page is obtained, but it fetches that page first because the policies are evaluated against it. Obtaining the page instantiates it, and instantiation runs the configured IAuthorizationStrategy; when that strategy throws RestartResponseAtInterceptPageException, the exception replaces the request handler before any isolation policy has run, so a cross-origin request that the policies would have refused is not refused. The exception also stores the interrupted URL, query string included, for Component#continueToOriginalDestination(); after sign-in the resulting redirect is same-origin, so the policies permit it and the listener executes in the newly authenticated session, where form components on a GET read their values from the query string. Request-body parameters captured alongside the URL are not reapplied. The feature was introduced in 9.1.0; earlier releases (all 8.x and 9.0.0) rely solely on CsrfPreventionRequestCycleListener, which infers origin from Origin with a Referer fallback - headers a browser may omit - so those releases never provided the Fetch Metadata guarantee and are out of scope. Our assessment uses CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N (vendor CVSS 4.0 base score 2.1).
Know when Java 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
No credit card · 7-day full trial
Severity by source
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
Network-reachable with no attacker privileges (PR:N), but a victim must navigate then sign in (UI:R); impact is limited integrity from attacker-chosen form values (I:L) with no confidentiality or availability effect.
Primary rating from Vendor (apache).
CVSS VectorVendor: apache
DescriptionCVE.org
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.
Threat Intelligence Overview
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.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Oracle Java SE 7 Update 6 and earlier contains multiple sandbox bypass vulnerabilities via the ClassFinder and forName m
Remote code execution in IBM Sterling B2B Integrator, Sterling Integrator, and Tivoli Common Reporting allows unauthenti
Java Runtime Environment sandbox bypass via incorrect image channel verification in 2D component allows remote unauthent
Oracle Java SE JDK/JRE 7 and 6 Update 27 and earlier allows remote code execution with complete system compromise throug
JBoss Seam 2 in Red Hat JBoss EAP 4.3.0 fails to sanitize JBoss Expression Language inputs, allowing remote attackers to
Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 update 4 and earlier, 6 up
Multiple vulnerabilities in Oracle Java 7 before Update 11 allow remote attackers to execute arbitrary code by (1) using
Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 Update 2 and earlier, 6 Up
The WLS Security component in Oracle WebLogic Server 10.3.6.0, 12.1.2.0, 12.1.3.0, and 12.2.1.0 allows remote attackers
Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 Update 7 and earlier allow
Remote unauthenticated attackers can execute arbitrary code on Adobe ColdFusion servers through Java deserialization fla
The ExceptionDelegator component in Apache Struts before 2.2.3.1 interprets parameter values as OGNL expressions during
Exploit-DB