VulWall Team March 13, 2026 4 min read

Outdated HTML Sanitizer Library Allows Script Injection on Your Website

Your website uses a popular library called DOMPurify to clean up user-submitted content before displaying it — think of it like a filter that strips out dangerous code. A flaw in the version you're running means that filter has a gap: under specific conditions, a crafted piece of content can slip through and run malicious code in a visitor's browser. A patch is already available and the fix is a straightforward version upgrade.

OWASP A03 Effort: trivial Exploitable
xss dompurify sanitizer-bypass cve frontend javascript rawtext safe-for-xml

Business Impact And Actions

high urgency

Business Impact

If exploited, an attacker could run scripts in your visitors' browsers — potentially stealing session cookies, redirecting users to phishing pages, or performing actions on their behalf. The risk is real but conditional: it only applies if your app renders DOMPurify-sanitized content inside certain HTML structures (like `<noscript>` blocks). Even so, a known, patchable vulnerability in a security library is a compliance flag and a liability — most security audits and frameworks like SOC 2 or ISO 27001 will flag unpatched dependencies.

What To Do

  1. Ask your developer to check which version of DOMPurify is installed in your project — if it's between 3.1.3 and 3.3.1 (or 2.5.3 and 2.5.8), it needs to be updated.
  2. Request the upgrade to DOMPurify 3.3.2 or higher (or 2.5.9 if you're on the 2.x branch). This is a drop-in update with no code changes required.
  3. After the update is deployed, ask your developer to confirm the new version is live using your package audit tool (e.g., `npm audit`).
  4. If you use a Content Security Policy on your site, ask your developer to verify it's configured to block inline scripts — this acts as a safety net for this class of issue.

DOMPurify 3.1.3–3.3.1 / 2.5.3–2.5.8: XSS via Incomplete SAFE_FOR_XML Rawtext Regex (CVE-2026-0540)

medium severity CVSS 6.1

Vulnerability Explanation

DOMPurify's `SAFE_FOR_XML` mode applies a regex to attribute values to detect closing tags that could escape their element context and inject markup. The original regex only matched `</style>` and `</title>` closing tags. Five additional rawtext elements — `noscript`, `xmp`, `noembed`, `noframes`, and `iframe` — were not included in the pattern. An attacker can embed a payload such as `</noscript><img src=x onerror=alert(1)>` inside an attribute value. DOMPurify passes this through sanitization without stripping it. When the sanitized output is later placed inside a `<noscript>` (or other unprotected rawtext) element in the DOM, the browser parses the closing tag, breaks out of the rawtext context, and executes the injected script.

Root Cause

Incomplete regex coverage in the `SAFE_FOR_XML` attribute sanitization logic. The pattern `/((--!?|])>)|<\/(style|title)/i` only guarded against `style` and `title` closing tags, leaving `noscript`, `xmp`, `noembed`, `noframes`, and `iframe` unprotected against context-escaping payloads embedded in attribute values.

Technical Impact

Stored or reflected XSS in applications that render DOMPurify-sanitized content inside rawtext elements. An attacker who can supply input to the sanitizer can achieve arbitrary JavaScript execution in the victim's browser — enabling session hijacking, credential theft, DOM manipulation, or user impersonation depending on the application's privilege model.

Severity Justification

CVSS 3.1 base score of 6.1 (AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N). Network-accessible, no authentication required, but exploitation requires user interaction and depends on the application rendering sanitized output inside specific rawtext element contexts, which is not universally present.

Affected Components

  • DOMPurify >= 3.1.3 and < 3.3.2
  • DOMPurify >= 2.5.3 and < 2.5.9

Remediation Steps

  1. Upgrade DOMPurify to version 3.3.2 or later (or 2.5.9 if you must stay on the 2.x branch): `npm install dompurify@latest` or pin to `^3.3.2` in package.json.
  2. If using a CDN-hosted copy, update the script tag src to reference version 3.3.2 or later from the official jsDelivr or unpkg CDN.
  3. Run `npm audit` (or `yarn audit`) after upgrading to confirm no remaining DOMPurify advisories are reported.
  4. Audit your templates and server-side rendering code for any locations where DOMPurify output is injected inside `<noscript>`, `<xmp>`, `<noembed>`, `<noframes>`, or `<iframe>` elements — these patterns are inherently risky regardless of sanitizer version.
  5. Deploy or tighten a Content Security Policy with `script-src` directives to block inline script execution as a defence-in-depth measure.

Verification Steps

  1. Run `npm list dompurify` (or `yarn list --pattern dompurify`) and confirm the resolved version is 3.3.2 or higher.
  2. Run `npm audit` and verify CVE-2026-0540 / GHSA-v2wj-7wpq-c8vv no longer appears in the output.
  3. In a browser dev console on your application, run `DOMPurify.version` and confirm it returns `3.3.2` or later.
  4. Test a known payload — e.g., sanitize an attribute containing `</noscript><img src=x onerror=alert(1)>` and confirm the closing tag is stripped from the output.

Code Examples (json)

Vulnerable
// package.json — vulnerable range
"dompurify": "^3.1.3"  // resolves to anything up to 3.3.1

// The SAFE_FOR_XML regex in affected versions only covered style/title:
// /((--!?|])>)|<\/(style|title)/i
// Missing: noscript, xmp, noembed, noframes, iframe
Fixed
// package.json — safe
"dompurify": "^3.3.2"

// Upgrade via npm:
// npm install dompurify@^3.3.2

// The fix expands the regex to cover all rawtext elements:
// /((--!?|])>)|<\/(style|title|noscript|xmp|noembed|noframes|iframe)/i

Best Practices

  • Subscribe to DOMPurify's security mailing list (https://lists.ruhr-uni-bochum.de/mailman/listinfo/dompurify-security) to receive immediate notification of future bypass disclosures.
  • Avoid rendering DOMPurify-sanitized output inside rawtext elements (`<noscript>`, `<xmp>`, `<textarea>`, `<iframe>`) — these contexts have non-standard parsing rules that can interact unexpectedly with sanitizers.
  • Implement a Content Security Policy with a strict `script-src` directive to limit the blast radius of any future sanitizer bypass.
  • Integrate `npm audit` or a dependency scanning tool (e.g., Dependabot, Snyk) into your CI pipeline to catch vulnerable dependency versions before they reach production.

References

Found this in your infrastructure?

VulWall scans for this and dozens of other issues automatically.

Scan Your Domain Free
Back to Knowledge Base