Severity: moderate
CVSS 4.0: 2.1 (low)
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
Affected versions:
- Apache Wicket (org.apache.wicket:wicket-core) 9.1.0 through 9.24.0
- Apache Wicket (org.apache.wicket:wicket-core) 10.0.0 through 10.11.0
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.
Credit:
Emond Papegaaij (finder)
References:
https://wicket.apache.org/
https://www.cve.org/CVERecord?id=CVE-2026-82898
