CVE-2026-82898 in Wicket
Summary
by MITRE • 11/02/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 11/02/2026
The vulnerability in Apache Wicket stems from a critical flaw in the execution order of security checks within the ResourceIsolationRequestCycleListener component. This listener is designed to enforce resource isolation policies that prevent cross-origin attacks by verifying the origin of incoming requests against configured allowlists or denylists. However, the implementation contains a logic error where the system attempts to instantiate the target page before consulting these isolation policies. In Java web frameworks like Wicket, instantiating a page triggers its initialization lifecycle, which includes invoking any registered authorization strategies such as IAuthorizationStrategy. This premature instantiation creates a race condition in security enforcement because the authentication and access control checks occur prior to the origin validation that is supposed to protect against cross-site request forgery or similar cross-origin abuses.
When an unauthenticated user attempts to access a protected resource, the application typically responds by throwing RestartResponseAtInterceptPageException to redirect them to a login page. Due to the flawed order of operations, this exception is thrown from within the isolation listener itself, before the origin policy has had a chance to evaluate and potentially reject the request based on its source. Consequently, requests originating from unauthorized or malicious domains are not refused at the isolation layer. Instead, they proceed through the authentication flow because the security check that should have blocked them was bypassed by the earlier page instantiation step. This effectively nullifies the protective intent of the resource isolation feature for unauthenticated users, allowing attackers to leverage legitimate application flows against their own or other origins without being intercepted at the appropriate security boundary.
The impact is further exacerbated by how Wicket handles session resumption after authentication. The RestartResponseAtInterceptPageException stores the full URL of the interrupted request, including its query string parameters, in order for Component#continueToOriginalDestination() to resume the user's journey upon successful login. Because this stored URL includes any query parameters present in the original malicious request, a subsequent redirect following sign-in will carry those values into an authenticated session. This means that if a form or page component reads its state from the query string during a GET request, it may process data injected by an attacker via cross-origin navigation rather than legitimate user input. Although POST body parameters are not carried over due to the nature of HTTP redirects converting subsequent requests to GETs, the exposure of query-string-based values allows for potential manipulation of application behavior or state in contexts where such inputs influence logic or display content.
This vulnerability is classified under CWE-20 Improper Input Validation and relates closely to ATT&CK techniques involving Cross-Site Request Forgery (CSRF) and potentially Server-Side Request Forgery depending on how the resumed parameters are processed within the application context. The flaw specifically affects applications that explicitly register ResourceIsolationRequestCycleListener, which is an opt-in feature introduced in version 9.1.0 to provide Fetch Metadata-based origin checking. Versions prior to 9.1.0 rely solely on CsrfPreventionRequestCycleListener, which uses Origin and Referer headers for validation. However, these headers are often omitted by browsers during simple GET requests or controlled by referrer policies, making pre-9.1 protections unreliable. Therefore, the vulnerability is most critical in environments using 9.x and 10.x releases where developers have enabled this specific isolation listener expecting robust cross-origin protection that is currently undermined by the implementation bug.
To mitigate this risk, applications should upgrade to Apache Wicket version 9.25.0 or 10.12.0, which corrects the execution order so that resource isolation policies are consulted before page instantiation occurs. For organizations unable to immediately upgrade, a temporary workaround involves replacing RestartResponseAtInterceptPageException with RestartResponseException when denying unauthorized access. This alternative exception does not store the original destination URL for resumption, thereby preventing the leakage of potentially malicious query parameters into authenticated sessions via redirect-based login flows. While this workaround sacrifices the convenience of returning users to their originally requested page after authentication, it restores security integrity by ensuring that cross-origin requests are properly evaluated before any stateful components are initialized or resumed with unvalidated input data.