EUVD-2026-114903
GHSA-f4x7-9w8x-8x82
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessInject quote/backslash into id-derived data
-
DeliveryVictim loads rendered Wicket page
-
ExploitCrafted value breaks out of JS string literal
-
ExecutionInjected script runs in app origin (CSP nonce trusted)
-
ImpactSession/DOM actions in victim context
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A05:2025 - Injection
ASVS 5.0
V1 - Encoding and Sanitization Output encoding, context-aware escaping
MITRE ATT&CK
2 techniques across 2 tactics: Initial Access, Execution The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires that the application supplies a component markup id (via Component#setMarkupId, an id attribute in markup, or a component id derived from data) or a form component id containing a single quote or backslash - Wicket itself never generates such characters, so the tainted value must originate from application data flow. Affected sinks include Form (its markup id and hidden-fields container id on all affected versions; plus an input name in a submitting link on 8.x and an unescaped name attribute via appendDefaultButtonField on 8.x/9.x, where a double quote breaks out of the attribute into markup), FormComponentUpdatingBehavior, MultiFileUploadField, and numerous wicket-extensions components (AjaxEditableLabel, AjaxIndicatorAppender, UploadProgressBar, KittenCaptchaPanel, Palette, FilterForm, and TrapFocusBehavior/AjaxListPanel on 9.x/10.x). Limiting factors: a victim must load the affected rendered page (UI:P), and the application must actually place externally-influenced data into an id - static developer-set ids are not exploitable. The default Wicket 9.x/10.x CSP does NOT limit it, as the injected code sits in a nonce-trusted script element. |
| Impact | This is a genuine but conditional cross-site scripting flaw (CWE-79) in Apache Wicket, reported by the vendor (Apache) itself. The supplied 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) shows a network-reachable, low-complexity, unauthenticated flaw - but two signals pull against raw severity. First, AT:P (a specific attack requirement) and UI:P (passive user interaction, i.e. the victim must load the rendered page) mean exploitation is not universal: per the description, the injected value only reaches a JavaScript string literal when the application itself places a single quote or backslash into a component's markup id, its id attribute, or a component id derived from data - Wicket never introduces such characters on its own. So real-world risk is gated by whether a given application routes attacker-influenced data into those identifiers. Second, there is no EPSS score and no CISA KEV listing in the provided data, and no proof-of-concept is supplied - only the Apache advisory thread is referenced. The vuln.today decision label is 'this_week', consistent with a serious, vendor-confirmed issue that is not under active exploitation. Note the default Content-Security-Policy shipped by Wicket 9.x/10.x does NOT mitigate this, because the generated script carries the per-response nonce the policy trusts - a defender might wrongly assume their CSP covers it, so that assumption should be corrected explicitly. Net: a real priority for teams running affected Wicket versions whose applications derive ids from external data, but lower urgency for applications that only use static, developer-set ids. |
| Exploit ScenarioDerived | An application sets a component's markup id (or a component id used to build a form input name) from attacker-influenced data - for example a record key shown in a list - and that value contains a single quote or backslash. Wicket writes the value unescaped into a single-quoted JavaScript string literal in the script it generates, so the attacker's value closes the literal and the remainder executes as script in the application's origin when a victim loads the page. No authentication is required and the default CSP does not block it; no public proof-of-concept is available at time of analysis. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Nov 01, 2026
Cross-site scripting in Apache Wicket 8.0.0 through 8.19.0, 9.0.0 through 9.24.0 and 10.0.0 through 10.11.0 lets a value that the application places into a component markup id or a component id break out of a single-quoted JavaScript string literal that Wicket itself generates, so the injected script executes in the application's origin when the page loads. Exploitation is conditional: Wicket never generates a quote or backslash in these identifiers, so the tainted value must originate from application data flow (a value passed to Component#setMarkupId, an id attribute in a template, or a component id derived from data), and a victim must load the affected rendered page; the supplied independent assessment scores this as CVSS 3.1 AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:L/A:N, i.e. a genuine but conditional flaw rather than a trivially reachable one. No KEV listing is present and no public exploit code is identified in the available intelligence; the vendor's own advisory carries a CVSS 4.0 score of 7.6 and a this_week remediation priority.
RemediationAI
Vendor-released patches fix this in Apache Wicket 8.20.0, 9.25.0 and 10.12.0; upgrade wicket-core and wicket-extensions together to the branch you need (8.20.0, 9.25.0 or 10.12.0) as documented at https://lists.apache.org/thread.html/5wg754b873tlnsc268myrwcoy9lt046v, and note that 7.x and earlier are unsupported and must be moved to a supported line. The fixed versions validate identifiers at the point of entry rather than escaping at each output: a component id or markup id may no longer contain a quote, backquote, backslash, brace, angle bracket, semicolon, ampersand or control character, and markup ids may additionally not contain parentheses or square brackets, with constructors throwing an exception on violation - so expect applications that legitimately use such characters in ids to fail at startup or render time and plan a code review alongside the upgrade. Where an immediate upgrade is not possible, apply the same validation ahead of Wicket in your own code: reject or transform any markup id passed to Component#setMarkupId, any id attribute in templates, and any component id derived from external data so that it contains only a conservative alphanumeric/dash/underscore character set, and in particular never derive component ids from user-controlled strings; the trade-off is that this is application-level discipline that must be repeated for every component and does not close the 8.x/9.x appendDefaultButtonField attribute-injection path. Because the default 9.x/10.x nonce-based Content-Security-Policy admits the generated script, CSP tuning is not a substitute for the fix, and the changed id rules mean any existing ids that rely on the now-rejected characters must be renamed as part of the upgrade.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Apache Wicket is a Java component-oriented web framework whose rendering pipeline emits small JavaScript snippets that refer back to the DOM elements it produced - for example Wicket.Event.add calls keyed on a component's markup id. The root cause is CWE-79 (improper neutralization of input during web page generation): OnEventHeaderItem#forMarkupId(String, String, CharSequence) in wicket-core quotes the id it receives into such a JavaScript call, and components in both wicket-core and wicket-extensions reach it through #forComponent(Component, String, CharSequence), but the value is placed inside a single-quoted string literal without escaping for the JavaScript context. A markup id is taken from Component#setMarkupId(String), else the element's id attribute in markup, else a Wicket-generated id (which can never contain the dangerous characters); markup ids and component ids are supplied in an HTML context where quotes and backslashes are legal, and Wicket escapes them correctly when writing the same value into an id attribute - the JavaScript sink is simply a different grammar with different escaping rules. Form component input names are built from the ids of the components between the form and the form component, and component ids were historically rejected only for ':' and '~'. On all affected versions org.apache.wicket.markup.html.form.Form writes its markup id and the id of its hidden-fields container into such literals, FormComponentUpdatingBehavior writes an input name, and MultiFileUploadField writes two markup ids and an input name; on 8.x Form additionally writes an input name into the action of a submitting link, and on 8.x and 9.x Form#appendDefaultButtonField writes an input name into a name attribute with no escaping at all, so a double quote escapes the attribute into markup. wicket-extensions is affected in its own right, not just transitively: AjaxEditableLabel, AjaxIndicatorAppender, AjaxDisableComponentListener, UploadProgressBar, KittenCaptchaPanel, Palette and FilterForm build their own JavaScript containing a markup id, as do TrapFocusBehavior and AjaxListPanel on 9.x and 10.x. The default Content-Security-Policy in Wicket 9.x and 10.x does not mitigate this, because the generated script is written into a script element carrying the per-response nonce and is therefore admitted by the policy. The specific trigger path by which an application would surface such an id is not described in the available sources beyond the application-supplied id conditions above.
Know when Apache Wicket gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
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
Unauthenticated network XSS requiring victim page load (UI:R) and the non-default precondition that the app routes tainted data into an id (AC:H); scope changes into the browser (S:C) with C:L/I:L - higher impact is defensible given full script execution in app origin.
Primary rating from Vendor (apache).
CVSS VectorVendor: apache
DescriptionCVE.org
Improper neutralization of input during web page generation in Apache Wicket.
Apache Wicket generates JavaScript that refers to the elements it renders, and writes into that JavaScript two values it derives itself: a component's markup id, and the input name of a form component, which is built from component ids. Both are placed inside single-quoted JavaScript string literals without being escaped for that context, so a value containing a single quote or a backslash ends the literal, and what follows is parsed as script and runs in the application's origin when the page loads.
A markup id is the value passed to org.apache.wicket.Component#setMarkupId(String), or the id attribute written in the component's markup, or an id Wicket generates, in that order. The first two are supplied by the application in an HTML context, where both characters are legal and where Wicket escapes them correctly when it writes the same value into the id attribute of the element; a generated id cannot contain either. An input name is derived from the ids of the components between the form and the form component, and a component id was rejected only for ':' and '~'.
In org.apache.wicket:wicket-core on 9.x and 10.x, org.apache.wicket.markup.head.OnEventHeaderItem#forMarkupId(String, String, CharSequence) quotes the id it is given into a Wicket.Event.add call, and components in both wicket-core and wicket-extensions reach it through #forComponent(Component, String, CharSequence). On every affected version, org.apache.wicket.markup.html.form.Form writes its markup id and the id of its hidden-fields container into such literals, org.apache.wicket.markup.html.form.FormComponentUpdatingBehavior writes an input name, and org.apache.wicket.markup.html.form.upload.MultiFileUploadField writes two markup ids and an input name. On 8.x, Form also writes an input name into the action of a submitting link, and on 8.x and 9.x Form#appendDefaultButtonField writes an input name into a name attribute with no escaping at all, so a value containing a double quote escapes the attribute into markup.
org.apache.wicket:wicket-extensions is affected in its own right and not only through wicket-core: AjaxEditableLabel, AjaxIndicatorAppender, AjaxDisableComponentListener, UploadProgressBar, KittenCaptchaPanel, Palette, FilterForm and, on 9.x and 10.x, TrapFocusBehavior and AjaxListPanel each build their own JavaScript containing a markup id.
An application is affected where a markup id or a component id carries one of those characters. Wicket does not put one there itself, so the value comes from the application: an id set on a component, an id attribute in a template, or a component id derived from data. None of those is a JavaScript context from the application's point of view.
The Content-Security-Policy that Apache Wicket 9.x and 10.x send by default does not prevent this. The generated script is written into a script element carrying the per-response nonce, so the injected code is part of a script the policy admits.
The fixed versions check an id where it enters instead of escaping each place it is written. A component id and a markup id may no longer contain a quote, a backquote, a backslash, braces, angle brackets, a semicolon, an ampersand or a control character, and a markup id may not contain parentheses or square brackets either; a component constructed with such an id, or given such a markup id, fails with an exception.
This issue affects Apache Wicket: from 8.0.0 through 8.19.0, from 9.0.0 through 9.24.0, from 10.0.0 through 10.11.0. Users of Apache Wicket 7.x or older, which are no longer supported, should upgrade to a supported version. Users are recommended to upgrade to version 8.20.0, 9.25.0 or 10.12.0, which fix the issue.
Articles & Coverage 2
Executive ViewAI
A high-severity cross-site scripting vulnerability in Apache Wicket (CVE-2026-95863) affects versions 8.x, 9.x, and 10.x, potentially allowing an attacker to execute scripts in the context of our web applications. This could lead to session hijacking or data theft for users of applications built on these Wicket versions. Leadership should prioritize remediation because the vulnerability is conditional but could be exploited by a determined attacker with application-specific knowledge, and no patch is currently available.
Implement strict input validation and output encoding for all component markup IDs and component IDs, ensure they are generated from trusted sources, and deploy a web application firewall (WAF) with rules to detect and block XSS attempts targeting Wicket-generated JavaScript.
Threat Intelligence Overview
NVD
CVE.org
EPSS
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Cross-Site Scripting occurs when an application accepts untrusted data and sends it to a web browser without proper validation or encoding.
More in Apache Wicket
View allPath traversal vulnerability in Apache Wicket's FolderUploadsFileManager allows unauthenticated attackers to read arbitr
Apache Wicket's form-less upload endpoint (AbstractFileUploadResource, the server side of FileUploadToResourceField, or
Heap-exhaustion denial of service in Apache Wicket 9.14.0 through 9.24.0 and 10.0.0 through 10.11.0, reachable without a
Cross-site scripting in Apache Wicket 8.0.0 through 8.19.0, 9.0.0 through 9.24.0 and 10.0.0 through 10.11.0 allows text
Stored cross-site scripting in Apache Wicket's AjaxNewWindowNotifyingBehavior allows a client-supplied browser window na
Cross-site scripting in Apache Wicket 8.0.0 through 8.19.0 lets remote attackers get script executed in the application'
Apache Wicket's public JavaScriptUtils.escapeQuotes() helper fails to escape backslashes before quotes, so attacker-infl
Cross-site scripting in Apache Wicket's SmartLinkLabel and SmartLinkMultiLineLabel components turns attacker-influenced
Session fixation in Apache Wicket's role-based authentication module leaves the container session id unchanged when an a
Missing authorization in Apache Wicket 8.x, 9.x and 10.x allows unauthenticated remote attackers to invoke a component's
Missing authorization in Apache Wicket 10.3.0 through 10.11.0 allows a remote unauthenticated caller to invoke the serve
Unauthenticated remote attackers can partially read and modify data in Apache Wicket versions 9.0.0 through 9.23.0 and 1
Exploit-DB