CVE-2026-83539 in Wicket
Summary
by MITRE • 11/02/2026
Improper neutralization of input during web page generation in Apache Wicket.
org.apache.wicket.extensions.markup.html.basic.SmartLinkLabel and org.apache.wicket.extensions.markup.html.basic.SmartLinkMultiLineLabel display a text value and turn any URL they find in it into a hyperlink. Both escape the model value and then hand the escaped text to org.apache.wicket.extensions.markup.html.basic.DefaultLinkParser, which searches it for anything of the form scheme://rest and wraps each match in an anchor whose href is the matched text, copied in as it is. The pattern accepts any scheme, and there is no list of permitted schemes anywhere on the path. A text value naming a scheme that executes script therefore becomes an anchor that executes it, in the application's origin and in the reader's own session, when the reader clicks the link. Rendering the page is not enough on its own; the link has to be activated. Escaping does not prevent this and is not the issue: the characters the payload needs are all valid in a URL and are ones that org.apache.wicket.util.string.Strings#escapeMarkup() leaves alone, and the value ends up in a URL rather than in element text, which is a context that escaping model data does not make safe.
An application is affected where it renders text it received through either of these two components. That is what they are for: they exist to linkify email addresses and web URLs found in the data an application is displaying, so untrusted input is the purpose of the feature rather than a misuse of it, and no unusual configuration is involved. No other component uses this parser, and an application that uses neither SmartLinkLabel nor SmartLinkMultiLineLabel is not affected.
On 9.x and 10.x the Content-Security-Policy Wicket sends by default admits script only from a source carrying a per-response nonce, and a URL whose scheme executes script cannot carry one, so that default policy stops the script from running. This is a property of the default policy and not of these components. An application that has weakened or disabled its Content-Security-Policy, for this or for any unrelated reason, is affected in full. Wicket 8.x has no Content-Security-Policy support at all and is affected as it stands.
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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 11/02/2026
The vulnerability identified in Apache Wicket represents a classic case of improper neutralization of input during web page generation, specifically manifesting as a Cross-Site Scripting (XSS) flaw within the SmartLinkLabel and SmartLinkMultiLineLabel components. These components are designed to automatically detect URLs embedded within text strings and convert them into clickable hyperlinks, a feature commonly used for linkifying email addresses or web links in user-generated content. The technical root cause lies in the DefaultLinkParser class, which processes escaped model values by searching for patterns matching scheme://rest syntax. Crucially, this parser accepts any URI scheme without validating against an allowlist of safe protocols such as HTTP or HTTPS. Consequently, if a text value contains a malicious payload utilizing a script-executing scheme like javascript:, it is wrapped in an anchor tag with the href attribute set directly to that unvalidated input. This architectural oversight means that while standard HTML escaping prevents injection into element content, it does not protect against injection into URL attributes where specific schemes can trigger execution contexts outside of normal rendering flows.
The operational impact of this vulnerability is significant because it allows for stored or reflected cross-site scripting attacks depending on how the data was originally ingested by the application. When a victim user views a page containing such a crafted link, no script executes merely upon page load; however, clicking the hyperlink triggers the browser to interpret the javascript: scheme and execute the embedded code within the security context of the vulnerable web application's origin. This grants an attacker the ability to perform actions on behalf of the victim, steal session cookies, capture sensitive input data, or redirect users to phishing sites. The vulnerability is particularly insidious because it targets a feature explicitly intended for handling untrusted input, meaning that developers relying on these components for sanitization may inadvertently introduce security risks without realizing they are processing potentially malicious payloads through an unsafe parsing mechanism.
Mitigation strategies must address both the immediate code-level flaw and broader architectural defenses. The primary remediation is to upgrade Apache Wicket to version 8.20.0, 9.25.0, or 10.12.0, where this issue has been resolved by implementing stricter validation of URI schemes within the link parser. For applications unable to immediately upgrade, developers should avoid using SmartLinkLabel and SmartLinkMultiLineLabel for any content derived from untrusted sources until a patch is applied. Additionally, organizations should enforce robust Content-Security-Policy (CSP) headers across their web infrastructure. In Wicket versions 9.x and 10.x, the default CSP configuration includes a nonce-based restriction that typically prevents script execution unless explicitly allowed by response-specific nonces; since malicious javascript: URLs cannot carry these nonces, they are blocked under strict default policies. However, applications with weakened or disabled CSP configurations remain fully vulnerable regardless of Wicket version. Upgrading from unsupported versions like 7.x is also critical to ensure access to modern security features and patches.
From a classification perspective, this vulnerability aligns with CWE-80: Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) and falls under the MITRE ATT&CK technique T1189: Drive-by Client Side Execution. The failure to validate URI schemes against an allowlist constitutes a lack of input validation that permits dangerous code execution contexts. Security teams should audit their use of Wicket's linkification components, ensuring that any text containing potential URLs is either sanitized through a dedicated URL whitelisting library before being passed to these components or replaced with safer alternatives for displaying untrusted content. Regular security assessments and static analysis tools configured to detect unsafe URI handling in web frameworks can help identify similar patterns across the codebase.