Severity: moderate
CVSS 4.0: 7.2 (high)
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
Affected versions:
- Apache Wicket (org.apache.wicket:wicket-auth-roles) 8.18.0 through 8.19.0
- Apache Wicket (org.apache.wicket:wicket-auth-roles) 9.23.0 through 9.24.0
- Apache Wicket (org.apache.wicket:wicket-auth-roles) 10.9.0 through 10.11.0
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.
Credit:
Emond Papegaaij (finder)
References:
https://wicket.apache.org/
https://www.cve.org/CVERecord?id=CVE-2026-82840
