Outdated HTML Sanitizer Library Allows Malicious Scripts to Slip Through

Vulnerability Explanation

DOMPurify's SAFE_FOR_XML regex failed to account for closing rawtext element tags (e.g., </textarea>) appearing inside HTML attribute values. When DOMPurify sanitizes such input, the closing tag survives the sanitization pass. If the sanitized output is then injected into a rawtext context in the DOM (e.g., inside a <textarea> element), the closing tag breaks out of that context, and any subsequent content — including attacker-controlled JavaScript — is interpreted as normal HTML and executed by the browser. The attack requires user interaction (the victim must load a page containing the crafted payload) and is network-delivered.

Root Cause

A missing validation rule in DOMPurify's SAFE_FOR_XML regex pattern did not escape or reject closing rawtext tags (such as </textarea>) when they appeared within attribute values. This allowed crafted payloads to survive sanitization and later escape their intended rendering context.

Technical Impact

An attacker who can supply input that is sanitized by the vulnerable DOMPurify version and then rendered inside a rawtext element (textarea, title, script, style) can execute arbitrary JavaScript in the victim's browser. This enables session hijacking, credential theft, DOM manipulation, and unauthorized actions performed as the victim user.

Severity Justification

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N scores 6.1 (Medium). Exploitability is conditional: the vulnerable code path is only triggered when sanitized output is placed inside rawtext elements, which is not the default usage pattern. User interaction is required. VulnCheck's CVSS v4 assessment scores this at 5.1.

Affected Components

• DOMPurify 3.1.3 – 3.2.6
• DOMPurify 2.5.3 – 2.5.8 (no patch available for 2.x branch)

Remediation Steps

1. Upgrade DOMPurify to version 3.2.7 or later: `npm install dompurify@latest` or `yarn upgrade dompurify`.
2. If you are on the 2.x branch (2.5.3–2.5.8), migrate to 3.x — the 2.x branch will not receive a patch for this CVE.
3. Audit your codebase for any pattern where DOMPurify output is inserted into rawtext elements (textarea, title, script, style). Apply additional HTML entity encoding at those insertion points as a defence-in-depth measure.
4. Add or strengthen a Content Security Policy (CSP) header to limit the impact of any future XSS bypass. Start in report-only mode to avoid breaking changes.
5. Verify the installed version after upgrading (see verification steps).

Verification Steps

1. Run `npm list dompurify` or `yarn list --pattern dompurify` and confirm the installed version is 3.2.7 or higher.
2. Search your codebase for patterns like `textarea.innerHTML = DOMPurify.sanitize(...)` or equivalent — these are the vulnerable injection points.
3. Use the GitHub Security Advisory GHSA-v8jm-5vwx-cfxm as a reference payload to test your sanitization pipeline in a staging environment.
4. Check your CSP violation reports (if configured) for any unexpected script-src violations after deployment.

Code Examples (javascript)

// Vulnerable: sanitized output placed directly inside a textarea element
const clean = DOMPurify.sanitize(userInput); // DOMPurify 3.1.3–3.2.6
textareaElement.innerHTML = clean; // payload escapes rawtext context

// Fixed: upgrade to 3.2.7+
// npm install dompurify@3.2.7

const clean = DOMPurify.sanitize(userInput); // 3.2.7 correctly handles rawtext closing tags
textareaElement.value = clean; // Prefer .value over .innerHTML for textarea elements

Best Practices

• Prefer setting textarea content via `.value` rather than `.innerHTML` — this avoids HTML parsing entirely and eliminates this class of vulnerability.
• Avoid placing DOMPurify-sanitized output inside rawtext elements (textarea, title, script, style) using innerHTML; use the appropriate DOM property instead.
• Pin your DOMPurify version in package.json and run automated dependency audits (e.g., `npm audit`) in CI to catch future CVEs early.
• Implement a Content Security Policy with a strict script-src directive as a defence-in-depth layer against XSS bypasses.

References

• github.com/advisories/GHSA-v8jm-5vwx-cfxm
• github.com/cure53/DOMPurify/commit/c861f5a83fb8d90800f1680f855fee551161ac2b
• www.vulncheck.com/advisories/dompurify-xss-via-textarea-rawtext-bypass-in-safe-for-xml
• nvd.nist.gov/vuln/detail/CVE-2025-15599