GHSA-c6gr-qvv4-5v3f

DOMPurify: SMIL attributeName=href guard is skipped when PARSER_MEDIA_TYPE is application/xhtml+xml

Published

2026-10-22

Modified

2026-10-22

Sources

github-advisory

Summary

### Summary DOMPurify drops `attributeName` attributes whose value contains `href`, so an allowed ` ` or ` ` can't rewrite a link's href after sanitizing. The check compares the attribute name after `transformCaseFunc`, and that function doesn't lowercase in XHTML mode. In XHTML the attribute is spelled `attributeName`, so the comparison with `"attributename"` never matches and the guard does nothing. An app that uses `PARSER_MEDIA_TYPE: 'application/xhtml+xml'` and allows `animate` and `attributeName` will keep ` `. Clicking the parent link then runs the script. This needs a non-default config, so going by SECURITY.md, this is a hardening bug rather than a bypass of the default config. ### Details In `_sanitizeAttributes` (dist/purify.js line 2216 in 3.4.16): ```js const lcName = transformCaseFunc(name); ... if (lcName === "attributename" && stringMatch(value, "href")) { _removeAttribute(name, currentNode, attr); continue; } ``` `transformCaseFunc` is `stringToLowerCase` for text/html but the identity function for application/xhtml+xml, because XML names are case-sensitive. The XML parser keeps SVG's real name `attributeName`, so in XHTML mode `lcName` is `attributeName` and the branch never runs. People using XHTML mode have to list SVG attributes in camelCase. The built-in attribute lists are lowercase and won't match, so `ALLOWED_ATTR`/`ADD_ATTR: ['attributeName', ...]` is the config you'd naturally write here. The value also passes the URI check. `IS_ALLOWED_URI` only checks the start of the string, and `x;javascript:alert(1)` looks like a relative value. SMIL reads `values` as a `;` list and, with `fill="freeze"`, the last entry ends up as the effective href of the parent ` `. In text/html mode the same allowlist is handled correctly. The name is lowercased and `attributeName` is removed. This is close to the XHTML case-sensitivity hardening in 3.4.14/3.4.15 (Attack Classes & Bypass History §22): a check written for lowercase names that a case-preserved name gets past. ### Proof of concept Tested with DOMPurify 3.4.16 in Chrome 153 (headless shell). Also reproduced on 3.3.3, 3.3.1 and 3.2.7. Not confirmed for 2.x. Config: ```js const cfg = { PARSER_MEDIA_TYPE: 'application/xhtml+xml', ALLOWED_TAGS: ['svg', 'a', 'animate', 'text'], ALLOWED_ATTR: ['attributeName', 'values', 'dur', 'fill', 'x', 'y', 'font-size', 'id', 'width', 'height'], }; ``` `{ PARSER_MEDIA_TYPE: 'application/xhtml+xml', USE_PROFILES: { svg: true }, ADD_TAGS: ['animate'], ADD_ATTR: ['attributeName'] }` behaves the same. Input: ```html click ``` Steps: 1. Save this as `poc.xhtml` next to `purify.js` (3.4.16) and open it in Chrome. The `.xhtml` extension makes Chrome load it as application/xhtml+xml, so nothing moves between HTML and XHTML. ```html poc // click '; const clean = DOMPurify.sanitize(dirty, cfg); console.log(clean); document.getElementById('sink').innerHTML = clean; //]]> ``` 2. The logged output still contains `attributeName="href"` and `values="x;javascript:alert(1)"`. 3. `document.getElementById('q').href.animVal` retu

Affected packages

Remediation: Upgrade to 3.4.17 or later.

References

• https://github.com/advisories/GHSA-c6gr-qvv4-5v3f