CVE-2026-49825 in lxml
Summary
by MITRE • 08/20/2026
lxml is a library for processing XML and HTML in the Python language. Prior to 6.1.1, link attributes in ``lxml.html.defs.link_attrs`` were missing ``xlink:href``, which can be used for URL bypass attacks in embedded SVG/MathML/etc. content. This vulnerability was fixed in lxml 6.1.1 and lxml_html_clean 0.4.5.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/20/2026
The lxml library serves as a foundational tool for processing XML and HTML documents within the Python ecosystem, offering high-performance parsing capabilities that are widely utilized in web scraping, data extraction, and document generation workflows. A critical security deficiency was identified in versions prior to 6.1.1 regarding the handling of link attributes during sanitization processes. Specifically, the internal definition list known as lxml.html.defs.link_attrs failed to include xlink:href among the recognized safe or monitored attribute types. This omission is particularly significant because SVG and MathML content frequently rely on XLink namespaces for defining hyperlinks and resource references, a standard practice in complex document structures that require rich media integration.
The technical flaw stems from an incomplete whitelist of allowed attributes during HTML cleaning operations. When lxml processes untrusted input through its sanitization functions, it relies on predefined lists to determine which tags and attributes are permitted. By excluding xlink:href from this list, the library inadvertently treated these attributes as invalid or potentially dangerous in a way that did not properly account for their legitimate use cases within SVG contexts. However, more critically, this gap created an opportunity for URL bypass attacks where malicious actors could embed SVG content containing xlink:href links to external resources. Because the sanitizer might strip standard href attributes but fail to recognize xlink:href as equivalent or related, attackers could exploit this discrepancy to inject scripts or redirect users to phishing sites without triggering standard security filters designed to catch traditional HTML anchor tag injections.
From an operational perspective, this vulnerability impacts applications that accept user-generated content containing embedded SVG images or MathML formulas. If such content is processed by a vulnerable version of lxml and then rendered in a web browser or another viewer, the missing attribute check allows for potential cross-site scripting vectors if combined with other injection techniques, or more directly facilitates phishing attacks through deceptive links. The impact extends to any system relying on lxml's html.clean module to sanitize input before storage or display, as these systems may falsely assume that all link-related attributes have been adequately filtered. This represents a classic case of incomplete sanitization where the security logic does not cover all variations of a specific data type, leading to a bypass of intended protective measures.
This vulnerability aligns with CWE-79, which describes Improper Neutralization of Input During Web Page Generation commonly known as Cross-site Scripting (XSS), specifically in contexts involving SVG injection and attribute manipulation. It also relates to CWE-601, URL Redirection to Untrusted Site via Open Redirect, as the core issue involves the uncontrolled redirection capability through a bypassed filter. In terms of MITRE ATT&CK mapping, this flaw facilitates techniques associated with Tactic TA0002 Execution and TA0005 Defense Evasion, particularly under sub-techniques that involve client-side code injection or phishing via manipulated links. The attack vector is primarily remote when the application processes untrusted input from web users, making it a significant concern for public-facing services.
To mitigate this risk, organizations must upgrade to lxml version 6.1.1 and lxml_html_clean version 0.4.5 or later, where the link_attrs definition has been corrected to include xlink:href alongside other relevant attributes like href and src. This ensures that sanitization logic correctly identifies and handles XLink-based references according to their security context rather than ignoring them or mishandling them. For applications unable to upgrade immediately due to dependency constraints, implementing a secondary validation layer using regular expressions or custom parsing rules to explicitly check for xlink:href in SVG content can provide temporary protection. Additionally, developers should enforce strict Content Security Policy headers and validate all incoming HTML/SVG payloads against comprehensive allowlists that account for namespace-specific attributes like those found in XLink standards. Regular security audits of sanitization logic are recommended to prevent similar oversights where standard attribute names overshadow their XML-namespace equivalents.