Apache Wicket EUVD-2026-114904

Exploitation requires that a resource-bundle entry rendered by an affected component carry text influenced by another party and containing a quote/apostrophe - specifically the org.apache.wicket.mfu.delete message (MultiFileUploadField) or the hidden-fields CSS class (Form, and Form#appendDefaultButtonField on 8.0.0-8.19.0 and 9.0.0-9.24.0) in wicket-core, and UploadProgressBar.starting, the FilterForm hidden-fields CSS class, or the TrapFocusBehavior current CSS class (on 9.0.0-9.24.0 and 10.0.0-10.11.0) in wicket-extensions. A victim must then load the generated page (UI:P). Limiting factors: resource bundles are normally authored by the application developer and not attacker-controlled, so script execution depends on a non-default situation where bundle content is under external influence; and on Wicket 9.x/10.x the default CSP blocks the attribute-injection (inline event handler) cases, leaving the JavaScript-string-literal cases exploitable because the generated script carries the per-response nonce the policy trusts. A quote in a legitimately translated string (common in many languages) is enough to break the page even without a malicious actor.

This is a CWE-79 cross-site scripting flaw in Apache Wicket where resource-bundle texts (a localized label, a CSS class name) are written unescaped into single-quoted JavaScript string literals and into quoted HTML attribute values. The only severity signal provided is the vendor (Apache) CVSS 4.0 vector CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N (7.6): network reachable, low complexity, but with an attack requirement (AT:P) and passive user interaction (UI:P). No EPSS score, no CISA KEV entry, and no PoC/exploit reference are present in the input - the sole reference is the Apache advisory thread. The vuln.today decision label is 'this_week', not act_now/emergency. The practical risk is bounded by a real prerequisite the AT:P metric reflects: the injected text must come from a resource-bundle entry that is under the influence of another party, which is not the default state of a developer-authored bundle. One nuance worth stressing to defenders: the CVSS impact is rated VC:H/VI:H, but for a browser-executed XSS running in the application origin a lower confidentiality/integrity rating is defensible - I have flagged this in my own assessment below rather than treating VC:H/VI:H as settled. Where the attribute-injection cases are concerned, the default Content-Security-Policy shipped by Wicket 9.x and 10.x blocks the injected inline event handler; it does NOT block the JavaScript-string-literal cases because the generated script carries the per-response nonce the policy admits. Net: a genuine, patch-worthy XSS that should be remediated this cycle, but not a mass-exploitation emergency on the available signals - no confirmed exploitation and exploitation is gated by attacker influence over bundle content.

An attacker who can influence the text of a resource-bundle entry that Wicket renders - for example a label, the org.apache.wicket.mfu.delete message, UploadProgressBar.starting, or a hidden-fields/TrapFocusBehavior CSS class - supplies a value containing an apostrophe or quote. When a victim loads the Wicket-generated page, the quote terminates the JavaScript string literal (or the attribute value) and the attacker's following characters are parsed as script in the application's origin. No public exploit identified at time of analysis; the only reference is the Apache advisory.