Apache Wicket CVE-2026-82840

The application must authenticate through org.apache.wicket.authroles.authentication.AuthenticatedWebSession (required by AuthenticatedWebApplication and used by the shipped UsernamePasswordPanel), AND must allow a session that is already signed in to authenticate again - e.g. a step-up prompt before a sensitive action, an account switch, or a sign-in form that remains reachable after login (the module does not hide that form from a signed-in session). The attacker must also plant a session id of their choosing in the victim's browser, which Wicket does not grant since JSESSIONID is set by the servlet container - requiring 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 must be one the attacker has already signed in on, because a not-yet-signed-in session does get its id renewed by the victim's authentication. Limiting factors: a failed authentication signs the session out and closes the window; PR:L means the attacker needs a valid account; UI:A means the victim must perform the authentication; and applications that call Session#changeSessionId() in their own authenticate() code after successful authentication are not affected. Only the listed version ranges are vulnerable.

The CVSS 4.0 base score is 7.2 (High), but the vector tempers that: AV:N makes it network-reachable, yet AT:P flags an attack requirement outside the attacker's control, PR:L means the attacker must hold a valid account to pre-authenticate the planted session, and UI:A requires the victim to actively authenticate. VC:H/VI:H reflect full session hijacking (account takeover) with no availability impact (VA:N). The vuln.today decision label is 'this_week' - meaningful but short of act_now/emergency. No EPSS score, no CISA KEV listing, and no PoC are present in the supplied data, so there is no public exploit identified at time of analysis. The compound preconditions - attacker must plant a chosen JSESSIONID (needing same-registrable-domain host control or URL-based session ids), must have already signed in on that session, and the victim must re-authenticate while already signed in - make this a targeted, high-effort flaw rather than a mass-exploitable one. This is a genuine account-takeover primitive worth patching in scheduled maintenance, but the real-world risk is well below what the 7.2 High headline alone implies given the stacked prerequisites and absence of exploitation or probability signals.

An attacker controlling a sibling host under the same registrable domain (or targeting an app configured to carry the session id in the URL) signs in to their own account to establish a known JSESSIONID, then plants that id in the victim's browser. The victim, already signed in, encounters a still-reachable sign-in form, step-up prompt, or account-switch flow and authenticates again; because the signed-in flag has already transitioned, Wicket skips changeSessionId() and the session id is not renewed, leaving the attacker in a session now bound to the victim's authentication. No public exploit code is identified at time of analysis, and the chain's network vector is offset by the required victim interaction and the attacker's need to position a chosen session id.