Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
lxmlhtmlclean.Cleaner does not strip javascript: URLs from namespaced URL attributes (xlink:href) Reporter: Guillem Lefait <guillem@datamq.com · Date: 2026-05-10 Affected: lxml ≤ 6.1.0 and lxmlhtmlclean ≤ 0.4.4 (latest stable) Confirmed against: lxml 6.1.0 + lxmlhtmlclean 0.4.4 on Python 3.13.5, 3.14.4, and 3.15.0a8 (libxml2 2.14.6 / 2.9.14 — bug is in pure-Python sanitizer logic, independent of the libxml2 backend) Root-cause class: same as CVE-2021-28957 (formaction missing from linkattrs) Summary Cleaner filters URL schemes (javascript:, vbscript:, …) by walking links via rewritelinks(), which delegates to iterlinks(), which only yields attributes named in lxml.html.defs.linkattrs. That allow-list contains no prefixed names (xlink:href) and no srcset. As a result, when Cleaner is configured with safeattrsonly=False — a documented option for callers that want lenient attribute handling but still expect URL-scheme scrubbing — <a xlink:href="javascript:…" survives sanitization…
Recommended action: Upgrade to 0.4.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The <base tag passes through the default Cleaner configuration. While pagestructure=True removes html, head, and title tags, there is no specific handling for <base, allowing an attacker to inject it and hijack relative links on the page. Details The <base tag is not currently in the pagestructure kill set. Even though the specification says <base must be inside <head, browsers accept <base tags outside of the head. If an attacker injects a <base tag, it changes the base URL for all relative URLs on the page (links, images, scripts) to a domain controlled by the attacker. PoC Impact The injection of a <base tag allows an attacker to hijack the resolution of all relative URLs on the page. This results in three critical attack vectors: 1. Phishing & Redirection: Attackers can redirect user navigation (e.g., <a href="/login") and form submissions (e.g., <form action="/auth") to an attacker-controlled domain, effectively stealing credentials or sensitive data without the user…
Recommended action: Upgrade to 0.4.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The hassneakyjavascript() method strips backslashes before checking for dangerous CSS keywords. This causes CSS Unicode escape sequences to bypass the @import and expression() filters, allowing external CSS loading or XSS in older browsers. Details The root cause is located in clean.py (around line 594): This transformation changes a payload like @\69mport into @69mport. This resulting string does NOT match the blacklist keyword @import. However, all modern browsers' CSS parsers decode \69 as the character 'i' (hex 69) according to CSS spec section 4.3.7, interpreting @\69mport as a valid @import statement. Same root cause bypasses expression() detection: \65xpression(alert(1)) passes through (IE only). PoC If rendered in a browser, the browser loads the external CSS. Variants like @\0069mport, @\69 mport (trailing space), and @\49mport (uppercase I) also work. Impact External CSS loading enables data exfiltration via attribute selectors (e.g., reading CSRF tokens), UI…
Recommended action: Upgrade to 0.4.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The HTML Parser in lxml does not properly handle context-switching for special HTML tags such as <svg, <math and <noscript. This behavior deviates from how web browsers parse and interpret such tags. Specifically, content in CSS comments is ignored by lxmlhtmlclean but may be interpreted differently by web browsers, enabling malicious scripts to bypass the cleaning process. This vulnerability could lead to Cross-Site Scripting (XSS) attacks, compromising the security of users relying on lxmlhtmlclean in default configuration for sanitizing untrusted HTML content. Patches Users employing the HTML cleaner in a security-sensitive context should upgrade to lxml 0.4.0, which addresses this issue. Workarounds As a temporary mitigation, users can configure lxmlhtmlclean with the following settings to prevent the exploitation of this vulnerability: removetags: Specify tags to remove - their content is moved to their parents' tags. killtags: Specify tags to be removed completely.…
Recommended action: Upgrade to 0.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.