`lxml_html_clean` `javascript:` URL Bypass via `xlink:href` (CVE-2026-49825)
The `lxml_html_clean.Cleaner` Python library, and the `lxml.html.clean` module in `lxml`, fails to strip `javascript:`, `vbscript:`, and `data:` URLs from namespaced attributes like `xlink:href` when configured with `safe_attrs_only=False`. This vulnerability, identified as CVE-2026-49825, is a form of stored Cross-Site Scripting (XSS) that allows malicious JavaScript to bypass sanitization, enabling client-side code execution if an application processes and renders untrusted HTML containing such payloads.
A critical vulnerability (CVE-2026-49825) has been identified in the lxml_html_clean.Cleaner library (versions <= 0.4.4) and the legacy lxml.html.clean module within lxml (versions <= 6.1.0). This flaw allows javascript:, vbscript:, and data: URLs to bypass HTML sanitization when present in namespaced attributes, specifically xlink:href, and when the Cleaner is instantiated with safe_attrs_only=False. The root cause is lxml's defs.link_attrs allow-list, which iterlinks() relies on, not including xlink:href, preventing the _remove_javascript_link function from being invoked for these attributes. This enables stored Cross-Site Scripting (XSS) attacks in web applications that use these libraries for sanitizing user-supplied HTML, potentially leading to client-side code execution in victim browsers. The bug affects applications that aim for lenient attribute handling but still expect URL scheme scrubbing.
Attack Chain
- An attacker crafts a malicious HTML payload containing a
javascript:URL embedded within anxlink:hrefattribute, such as<svg><a xlink:href="javascript:alert(document.domain)">click me</a></svg>. - The attacker submits this malicious HTML to a web application (e.g., a forum post, comment section) that uses
lxml_html_clean.Cleanerorlxml.html.cleanto sanitize user input. - The
Cleanerinstance is configured withsafe_attrs_only=False, a documented option for allowing custom attributes while still expecting URL scheme scrubbing. - Due to the vulnerability (CVE-2026-49825), the
Cleanerfails to identify and strip thejavascript:URL from thexlink:hrefattribute because it's not present in its internallink_attrsallow-list. - The unsanitized malicious HTML payload is successfully stored in the application's database or file system.
- A legitimate user accesses the web application page containing the stored malicious content, and their browser renders the SVG or MathML anchor element.
- The user clicks on the rendered link.
- The browser executes the embedded
javascript:URL in the context of the victim's domain, leading to client-side code execution (Stored XSS). This can result in session hijacking, data exfiltration, or further attacks.
Impact
Successful exploitation of CVE-2026-49825 leads to stored Cross-Site Scripting (XSS), allowing attackers to execute arbitrary JavaScript in the context of a victim's browser session. This can result in sensitive data theft (e.g., session cookies, credentials), defacement of web pages, redirection to malicious sites, or further client-side attacks. The severity is rated as 8.2 / High (CVSS 3.1: AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N), emphasizing that the vulnerability is network-exploitable with low attack complexity, requires user interaction (clicking the link), but changes the security scope and can lead to high confidentiality impact. Exploitation is conditional on the safe_attrs_only=False configuration.
Recommendation
- Immediately update
lxml_html_cleanto version0.4.5or higher to remediate CVE-2026-49825, which addresses the flaw in URL scheme stripping. - If still using
lxml.html.clean, ensure yourlxmllibrary version incorporates the fix for CVE-2026-49825, or switch to the maintainedlxml_html_cleanlibrary. - Review all instances of
lxml_html_clean.Cleanerorlxml.html.cleaninstantiation within your applications, especially those configured withsafe_attrs_only=False, to ensure they are adequately sanitizing all user-supplied HTML. - Implement Content Security Policies (CSPs) with strict
script-srcdirectives to mitigate the impact of any successful XSS attempts, even if this vulnerability is exploited.