Outdated HTML Sanitizer Can Be Bypassed to Inject Malicious Scripts

Vulnerability Explanation

DOMPurify versions before 3.2.4 contain a flawed regular expression in the SAFE_FOR_TEMPLATES sanitization path. The TMPLIT_EXPR regex used to detect and neutralize template literals was defined as `/${[\w\W]}/gm`, which requires a closing brace to match. Attackers can craft payloads that omit the closing brace, causing the regex to miss the template expression entirely. When the browser subsequently parses the insufficiently sanitized output — particularly inside SVG elements like `<desc>` or `<title>` — it 'mutates' the content, potentially reinterpreting backtick expressions as active event handlers (e.g., `onload=alert(1)`). This is a mutation XSS (mXSS) attack: the payload appears safe after sanitization but becomes dangerous after browser re-parsing.

Root Cause

An incorrect regular expression (`/${[\w\W]}/gm`) in `src/regexp.ts` failed to match template literals that omit the closing brace. The pattern required `${...}` but payloads using `${...` (no closing brace) bypassed detection. The fix in 3.2.4 tightens the regex to remove the closing brace requirement, ensuring all template literal patterns are caught regardless of whether they are well-formed.

Technical Impact

An attacker who can submit user-controlled HTML to an application using DOMPurify with `SAFE_FOR_TEMPLATES: true` can inject a crafted payload that survives sanitization. When the output is rendered in the browser — especially in SVG contexts — the browser's HTML mutation can activate the payload as executable JavaScript. This enables session hijacking, credential theft, UI redressing, or malicious redirects targeting the victim's browser session.

Severity Justification

CVSS 3.1 score of 4.5 (AV:L/AC:H/PR:N/UI:N/S:C/C:L/I:L/A:N). High attack complexity due to the non-default SAFE_FOR_TEMPLATES configuration requirement and browser-specific mutation behavior. Impact is limited to confidentiality and integrity at low levels. Not in CISA KEV; EPSS score is low (~0.03–4.6% depending on source).

Affected Components

• DOMPurify >= 0.0.1 < 3.2.4

Remediation Steps

1. Upgrade DOMPurify to version 3.2.4 or later (3.2.7 is the current latest): `npm install dompurify@latest` or `yarn upgrade dompurify`.
2. Verify the installed version: `npm list dompurify` — confirm it shows 3.2.4 or higher.
3. If you use a CDN-hosted copy, update the script tag URL to reference version 3.2.4+: `<script src="https://cdn.jsdelivr.net/npm/dompurify@3.2.7/dist/purify.min.js"></script>`.
4. If your application does NOT use `SAFE_FOR_TEMPLATES: true`, the risk is lower but upgrading is still strongly recommended as a precaution.
5. Review your DOMPurify configuration and remove `SAFE_FOR_TEMPLATES: true` if it is not explicitly required by your use case — the default configuration is not affected by this CVE.

Verification Steps

1. Run `npm list dompurify` (or `yarn list --pattern dompurify`) and confirm the version is 3.2.4 or higher.
2. If using a CDN, inspect the page source or Network tab in browser DevTools to confirm the loaded DOMPurify script URL references version 3.2.4+.
3. Search your codebase for `SAFE_FOR_TEMPLATES` to identify all call sites and confirm they are using the patched version.
4. Run your existing test suite to confirm no regressions from the upgrade.

Code Examples (javascript)

// DOMPurify 3.2.3 and earlier — SAFE_FOR_TEMPLATES path uses a flawed regex
// Internally: const TMPLIT_EXPR = /\${[\w\W]}/gm;  ← missing closing brace in match

import DOMPurify from 'dompurify'; // version < 3.2.4

const clean = DOMPurify.sanitize(userInput, {
  SAFE_FOR_TEMPLATES: true, // ← activates the vulnerable code path
});
document.getElementById('output').innerHTML = clean;

// DOMPurify 3.2.4+ — regex corrected, SAFE_FOR_TEMPLATES path is safe
// Internally: const TMPLIT_EXPR = /\${[\w\W]/gm;  ← closing brace requirement removed

import DOMPurify from 'dompurify'; // version >= 3.2.4

const clean = DOMPurify.sanitize(userInput, {
  SAFE_FOR_TEMPLATES: true,
});
document.getElementById('output').innerHTML = clean;

// Or upgrade via npm:
// npm install dompurify@latest

Best Practices

• Pin or lock your DOMPurify version in package.json and review release notes when upgrading — this library has had several security fixes across minor versions.
• Avoid enabling non-default DOMPurify options (like SAFE_FOR_TEMPLATES) unless you have a documented need; each option expands the attack surface.
• Pair DOMPurify with a Content Security Policy (CSP) as a defense-in-depth measure — even if sanitization is bypassed, a strict CSP can block inline script execution.
• Automate dependency vulnerability scanning (e.g., `npm audit`, Dependabot, or Snyk) so future DOMPurify CVEs are flagged before they reach production.

References

• nvd.nist.gov/vuln/detail/CVE-2025-26791
• github.com/advisories/GHSA-vhxf-7vqr-mrjg
• github.com/cure53/DOMPurify/releases/tag/3.2.4
• github.com/cure53/DOMPurify/commit/d18ffcb554e0001748865da03ac75dd7829f0f02
• security.snyk.io/vuln/SNYK-JS-DOMPURIFY-8722251