CVE-2026-49825: lxml: javascript: URL bypass in Cleaner via xlink:href

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 untouched, and any browser that follows the SVG-anchor specification will execute the JavaScript when the rendered link is clicked.

CWE: CWE-79 (XSS), with CWE-184 (Incomplete List of Disallowed Inputs) as the underlying defect class.

Affected components

| Package | Versions tested | File / line | |--------------------|------------------------|----------------------------------| | lxml | 4.9.x, 5.2.1, 6.1.0 | src/lxml/html/defs.py:20 | | lxml | " | src/lxml/html/init.py:485-528 | | lxmlhtmlclean | 0.4.0 – 0.4.4 | lxmlhtmlclean/clean.py:348,576 |

The legacy lxml.html.clean module — bundled in lxml < 5.2.0 and still installable on newer versions via the lxml[htmlclean] extra — shares the same bug.

Root cause

defs.linkattrs is a flat string set; the literal xlink:href is absent:

python lxml/html/defs.py linkattrs = frozenset([ 'action', 'archive', 'background', 'cite', 'classid', 'codebase', 'data', 'href', 'longdesc', 'profile', 'src', 'usemap', 'dynsrc', 'lowsrc', 'formaction', ])

HtmlMixin.iterlinks() (lxml/html/init.py:526-528) only yields attributes whose key is in that set:

python for attrib in linkattrs: if attrib in attribs: yield (el, attrib, attribs[attrib], 0)

Cleaner.call registers the URL-scheme filter via rewritelinks (lxmlhtmlclean/clean.py:348), which is a thin wrapper around iterlinks(). Because xlink:href is never yielded, removejavascriptlink (clean.py:576) is never invoked for it.

Minimal reproducer

python from lxml import html from lxmlhtmlclean import Cleaner

for payload in ( '<svg><a xlink:href="javascript:alert(1)">x</a></svg>', '<math><a xlink:href="javascript:alert(2)">y</a></math>', ): tree = html.fromstring(payload) Cleaner(safeattrsonly=False)(tree) print(html.tostring(tree).decode()) print(' iterlinks:', list(html.fromstring(payload).iterlinks())) <svg><a xlink:href="javascript:alert(1)">x</a></svg> ← unchanged iterlinks: [] ← link rewriter blind <math><a xlink:href="javascript:alert(2)">y</a></math> ← unchanged iterlinks: [] ← link rewriter blind

Both SVG and MathML scopes are vulnerable — same allow-list gap, both render anchors that browsers treat as navigable. Other lab-confirmed surviving variants (same scope, different scheme encoding): mixed-case (JaVaScRiPt:), HTML-entity (java&#x73;cript:), embedded tab (java\tscript:).

Impact

A caller that uses Cleaner to neutralise untrusted HTML and chooses safeattrsonly=False — typically because the application wants to allow custom data-/aria-/vendor attributes — will silently pass javascript: payloads carried on xlink:href through to victim renders. Stored XSS in any application that round-trips user-supplied HTML through this configuration. Reach is conditional on the safeattrsonly=False toggle, but that is a documented public option; consumers reasonably expect URL-scheme scrubbing to be independent of attribute allow-listing.

Suggested fix

Extend linkattrs to include xlink:href. In HTML mode, lxml.html keeps prefixed attribute names verbatim — the parsed key is the literal string xlink:href, not a Clark-notation form — so the existing allow-list lookup is a plain string match. Same shape as the CVE-2021-28957 fix:

diff # lxml/html/defs.py linkattrs = frozenset([ 'action', 'archive', 'background', 'cite', 'classid', 'codebase', 'data', 'href', 'longdesc', 'profile', 'src', 'usemap', 'dynsrc', 'lowsrc', 'formaction', + 'xlink:href', ])

This single change closes the reported XSS for both SVG <a xlink:href> and MathML <a xlink:href>. lxmlhtmlclean is the canonical home of the Cleaner code (881 lines); lxml.html.clean is a 21-line backward-compat shim (from lxmlhtmlclean import ) that picks up the fix automatically once linkattrs is updated upstream. Since the upstream change requires lxml maintainer action, see the alternative below if a self-contained patch in lxmlhtmlclean is preferred.

Alternative (in-package fix, no lxml coordination needed): add a namespaced-URL-attribute walk inside Cleaner.call so the URL-scheme filter doesn't depend on linkattrs. Sketch:

python lxmlhtmlclean/clean.py — supplements rewritelinks() in call NSURLATTRS = ('xlink:href',) # extend as needed BADSCHEME = re.compile(r'^\s(javascript|vbscript|data):', re.I)

for el in doc.iter(): for attr in NSURLATTRS: if attr in el.attrib and BADSCHEME.match(el.attrib[attr]): del el.attrib[attr]

This decouples the cleaner from the upstream linkattrs set and matches the security-ownership boundary established when the cleaner was extracted in lxml 5.2.0.

Defense in depth (optional, regardless of which fix path is taken): - Also handle srcset: the value is a url 1x, url 2x, … descriptor list, so split on commas and validate each candidate URL. Not directly executable in current browsers, but closes the same gap. - Also accept Clark-notation forms ({http://www.w3.org/1999/xlink}href) so XML-mode callers using lxml.etree get the same protection. HTML mode never produces this form, so not needed for the reported bug.

Severity

CVSS 3.1 base score: 8.2 / High — AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N (stored XSS; victim must click the SVG anchor; scope-changed because script executes in the rendering origin). PR:N reflects the common case where untrusted HTML enters the sanitizer from anonymous sources (comments, support tickets); deployments that gate writes behind authentication can score with PR:L (→ 7.6).

Severity is CONDITIONAL on the caller passing safeattrsonly=False. With the class default (True), attribute allow-listing strips xlink:href before scheme scrubbing runs, and the bug does not fire — verified at HEAD: default-config Cleaner()(<svg><a xlink:href="javascript:…">x</a></svg>) → <svg><a>x</a></svg>.

Prior art / novelty

- CVE-2021-28957 (lxml 4.6.3) — same root cause, different attribute (formaction). Fix was a one-line extension of linkattrs. Direct precedent. - CVE-2022-34473 (Mozilla Sanitizer API) — xlink:href URL bypass primitive in a different sanitizer. - Bleach (Mozilla, Python) explicitly handles the xlink namespace; enshrined/svg-sanitize (PHP) ships cleanXlinkHrefs(); DOMPurify scrubs xlink:href via ALLOWEDURIREGEXP. - nh3 (the alternative recommended in lxmlhtmlclean's own README for security-sensitive use) is not vulnerable to this primitive — verified 2026-05-10 on nh3==0.3.5: with <svg>/<math>/<a> and xlink:href explicitly added to tags/attributes, both SVG and MathML payloads, all four scheme-encoding variants, are stripped (output e.g. <svg><a rel="noopener noreferrer">x</a></svg>).

Coordination

Filing as a private GHSA at fedora-python/lxmlhtmlclean — lxmlhtmlclean is the canonical maintainer of the Cleaner code (881 lines) and the security-responsible team since the lxml 5.2.0 split, where the cleaner was extracted out of lxml precisely so cleaner-security reports could land on the right team. The lxml side cannot be filed via GHSA (https://github.com/lxml/lxml/security/advisories/new returns 404 — private reporting is not enabled), so a parallel report has been emailed directly to the lxml maintainer for the upstream defs.linkattrs patch path. You're welcome to coordinate with them directly if you'd prefer the upstream fix over the in-package alternative above.

Happy to provide a draft patch or PR on either path. No bounty expected.