Apache Wicket EUVD-2026-114894

Exploitation requires that the target application has explicitly added org.apache.wicket.ajax.AjaxNewWindowNotifyingBehavior to a component; the Wicket framework never installs this behaviour itself, so applications that do not use it are entirely unaffected - this non-default requirement is the primary limiting factor. The attacker must cause the browser's window.name (delivered to the server as the windowName request parameter) to contain a single quote that terminates the single-quoted JavaScript literal, which Wicket then writes into the page as raw script; window.name is client-supplied and receives no validation or escaping. The CVSS vector is PR:N (unauthenticated) but UI:P/AT:P, so success also depends on victim interaction - the victim loading/opening the vulnerable page instance (typically across a window/tab) under attacker-influenced window.name - rather than a fully automated remote hit. Note the behaviour's self-generated name, used when the browser reports no name, is a random UUID and is not attacker-controllable.

This is a genuine but conditional stored cross-site scripting flaw (CWE-79) whose real-world priority is moderate rather than urgent. The CVSS 4.0 vector (CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N, score 7.6) describes an unauthenticated network-reachable issue with high confidentiality and integrity impact in the application origin, but it carries both AT:P (a specific attack requirement) and UI:P (passive user interaction), which materially lower automatability and mass-exploitability. The vuln.today decision label is 'this_week', consistent with a serious-but-not-emergency issue. No EPSS score, no CISA KEV listing, and no POC reference are present in the input, so there is no signal of active exploitation or published exploit code; exploitation status is therefore 'no public exploit identified at time of analysis'. The dominant mitigating factor is not in the CVSS score at all: the advisory states an application is affected ONLY if it has explicitly added org.apache.wicket.ajax.AjaxNewWindowNotifyingBehavior to a component - no part of the framework installs it - so the exploitable population is a narrow subset of Wicket deployments. Net: a real, well-described vulnerability worth patching on a normal priority cadence, not a high-CVSS-but-illusory issue, yet far from a drop-everything emergency given the non-default prerequisite and absence of exploitation signals.

An attacker lures a user to a page they control, sets the browser's window.name to a payload containing a single quote (e.g. breaking out of the JavaScript string literal), then navigates the same tab to a Wicket application that uses AjaxNewWindowNotifyingBehavior. The behaviour reports the client-supplied window.name to the server as the windowName parameter and stores it in the page's serialized state, so the injected script is emitted unescaped into the Ajax-call precondition and executes in the application's origin on every subsequent render of that page instance. No public exploit code is identified at time of analysis; the mechanism is fully described in the Apache advisory.