Skip to content

chore(deps): update dependency dompurify to v3.4.16 [security] - #1445

Open
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/npm-dompurify-vulnerability
Open

renovate[bot] wants to merge 1 commit into
mainfrom
renovate/npm-dompurify-vulnerability

Conversation

@renovate

@renovate renovate Bot commented Oct 5, 2026 •

Copy link
Copy Markdown
Contributor

This PR contains the following updates:

Package Change Age Confidence
dompurify 3.4.15 → 3.4.16 age confidence

DOMPurify: IN_PLACE: node-removing afterSanitize hook leaves detached subtree event handlers armed, causing DOM XSS

GHSA-p98j-92pf-mc4p

More information

Details

Summary

In IN_PLACE mode DOMPurify sanitizes the caller's live DOM subtree directly. To close a known hazard (GHSA-55q2-fjhq-7xh7), the library neutralizes any node a hook detaches during sanitization by stripping its subtree's non-allow-listed attributes, but this neutralization is wired only into the beforeSanitizeElements and uponSanitizeElement hook sites. An afterSanitizeElements or afterSanitizeAttributes hook that removes a non-root element (a documented, supported pattern) detaches that element's subtree with no neutralization, so descendant on* handlers remain armed on the caller's live tree after sanitize() returns, yielding DOM XSS. No special privilege is required beyond supplying markup to an application that uses IN_PLACE together with a node-removing afterSanitize hook.

Root Cause

IN_PLACE sanitization mutates the caller's live document, so any element a hook detaches from that tree must have its subtree neutralized before sanitize() returns; otherwise a queued resource-event handler (for example an <img onerror> that began loading when the caller built the tree) fires in page scope even though the handler never reached the sanitized output. The guard helper _handleHookDetachedNode (which calls _neutralizeSubtree in IN_PLACE) is invoked only after beforeSanitizeElements and after uponSanitizeElement. It is never invoked from the afterSanitize return paths, and _sanitizeAttributes never calls it at all. The post-walk IN_PLACE neutralization pass iterates only DOMPurify.removed, and hook-detached nodes are intentionally not recorded there, so that pass cannot reach them either.

src/purify.ts
  _sanitizeElements: _handleHookDetachedNode present at lines 2142 and 2175
    (before/upon), absent after afterSanitizeElements at lines 2208 and 2249.
  _sanitizeAttributes: afterSanitizeAttributes fires at line 2670 with no
    detach re-check; the function never calls _handleHookDetachedNode.
  Post-walk IN_PLACE pass (lines 3081-3090) iterates DOMPurify.removed only,
    which by design (comment at lines 2096-2099) excludes hook-detached nodes.
Impact

An attacker who supplies markup processed by a victim application that runs DOMPurify.sanitize(node, { IN_PLACE: true }) and registers a node-removing afterSanitizeElements or afterSanitizeAttributes hook can retain arbitrary on* event handlers on descendants of a removed non-root element. Because IN_PLACE operates on the caller's live document, a queued resource-event handler on such a descendant fires in the page origin after the synchronous sanitize() call returns, giving script execution in the victim's session (DOM XSS). This defeats DOMPurify's IN_PLACE contract to neutralize handlers on subtrees removed from the live tree. The capability is script execution in the victim origin; exact confidentiality and integrity effects depend on the hosting application's session.

Proof of Concept
Dependencies: Node.js and jsdom. The harness builds a live tree, registers a
removal hook, runs IN_PLACE sanitize(), then inspects whether the attacker
onerror handler survives on the detached descendant. jsdom does not perform
real image loads, so the retained handler (rather than an actual fired event)
is the observed hazard; the retained on* attribute on a live detached node
after a synchronous sanitize() return is the neutralization failure.

Reproduction steps:

  1. Build a live subtree #root > section#wrap > img[onerror] where #root is the walk root and section#wrap is a non-root wrapper.
  2. Register an afterSanitizeElements (or afterSanitizeAttributes) hook that calls node.remove() on the wrapper.
  3. Call DOMPurify.sanitize(root, { IN_PLACE: true }).
  4. Observe that the descendant <img> retains its onerror handler, whereas the same removal performed in a beforeSanitizeElements/uponSanitizeElement hook strips it.
const { JSDOM } = require('jsdom');
const createDOMPurify = require('dompurify');
const { window } = new JSDOM('<!DOCTYPE html><body></body>');
const DOMPurify = createDOMPurify(window);

const root = window.document.createElement('div');
root.id = 'root';
root.innerHTML = '<section id="wrap"><img src="x" onerror="ATTACKER()"></section>';
window.document.body.appendChild(root);

DOMPurify.addHook('afterSanitizeElements', (node) => {
  if (node.id === 'wrap') node.remove();
});
DOMPurify.sanitize(root, { IN_PLACE: true });

// The detached <img> still carries its onerror handler:
console.log(root.querySelector('#wrap') === null,               // true (removed from live tree)
            !!window.document.querySelector('img[onerror]') ||  // handler survives on the detached node
            root.innerHTML);
PASS: beforeSanitizeElements detach neutralizes descendant onerror (control)
PASS: uponSanitizeElement detach neutralizes descendant onerror (control)
PASS: without a removal hook the descendant onerror is stripped normally
PASS: afterSanitizeElements detach LEAVES descendant onerror armed (GAP)
PASS: afterSanitizeAttributes detach LEAVES descendant onerror armed (GAP)
PASS: kept custom element removed in afterSanitizeElements leaves descendant onerror armed (GAP)
Attack Chain
  1. Exposure: The victim application calls DOMPurify.sanitize(liveNode, { IN_PLACE: true }) on attacker-influenced markup and has registered a node-removing afterSanitizeElements or afterSanitizeAttributes hook per an application policy (src/purify.ts:3026 walk, 2136 element pass, 2522 attribute pass).
  2. Control: The attacker controls the markup, including a non-root wrapper element and, inside it, a descendant carrying an on* resource-event handler such as <img src=x onerror=...>.
  3. Path: The pre-order walk visits the wrapper before its descendants. During the wrapper's element or attribute pass the application hook detaches the wrapper from the live tree.
  4. Guard: The detach-neutralization guard _handleHookDetachedNode runs only after beforeSanitizeElements (2142) and uponSanitizeElement (2175); it is absent after afterSanitizeElements (2208, 2249) and is never called by _sanitizeAttributes (afterSanitizeAttributes at 2670). The NodeIterator advances past the detached subtree, so the descendants are never revisited, and the post-walk pass iterates only DOMPurify.removed, which excludes hook-detached nodes.
  5. Primitive: The descendant retains its on* handler on the caller's live document after sanitize() returns.
  6. Result: The queued resource event fires the attacker handler in the victim page origin, achieving DOM XSS despite IN_PLACE sanitization.
Bypass Evidence

The relevant prior fix is GHSA-55q2-fjhq-7xh7 ("IN_PLACE hook removal leaves a detached subtree executable, causing XSS"), whose change (#1557) added _neutralizeSubtree at the beforeSanitizeElements and uponSanitizeElement detach sites. Inspection of that change shows it touches no afterSanitize site: the diff adds the neutralization only at the before/upon locations, later refactored into _handleHookDetachedNode at src/purify.ts:2142 and 2175. A subsequent hardening change (#1616) added a rootWasRemoved throw and a neutralization sweep over DOMPurify.removed, but that sweep still iterates only DOMPurify.removed, which by design excludes hook-detached non-root nodes, so it does not close this gap. The afterSanitizeElements-on-kept-custom-element site at 2208 was itself introduced by the fix for GHSA-c2j3-45gr-mqc4 (#1527), adding another uncovered hook site.

Disproof attempts, all failed: (a) that a later release closed the afterSanitize gap, refuted by inspecting the published 3.4.13, 3.4.14, and 3.4.15 artifacts; (b) that detached descendants are revisited or re-sanitized, refuted at runtime (the onerror is retained only at the afterSanitize sites and stripped at the before/upon sites and with no removal hook); (c) that the post-walk pass catches hook-detached nodes, refuted by the design that excludes them from DOMPurify.removed; (d) that the precondition is contrived, refuted by parity with the accepted GHSA-55q2 threat model and the library's own supported pattern of removing a node inside afterSanitizeElements. The only edge not directly executed is the browser resource-event dispatch (jsdom performs no real image load); it is established by the proven retention of the live handler after a synchronous return, the library's own comments describing exactly this hazard, and parity with the accepted GHSA-55q2 mechanism.

Affected Versions
  • Ecosystem: npm
  • Package: dompurify
  • Confirmed affected range: >= 3.4.13, <= 3.4.15
  • Latest release checked: 3.4.15 (npm registry)
  • Fix status: fixed in 3.4.16

The before/upon detach neutralization introduced for GHSA-55q2-fjhq-7xh7 first shipped in 3.4.13; the residual afterSanitize gap was verified by reproducing it against the published npm artifacts for 3.4.13, 3.4.14, and 3.4.15. The 3.4.12 artifact predates that neutralization and behaves differently at the before/upon sites, so it is outside this specific incomplete-fix range. No release through 3.4.15 neutralizes detached subtrees at the afterSanitize sites, so no fixed version is established.

Suggested Fix

Enforce the same IN_PLACE detach-neutralization invariant at every hook site that can detach a node, not only the before/upon sites. Concretely, apply a _handleHookDetachedNode(currentNode, root) re-check after afterSanitizeElements at both src/purify.ts:2208 and 2249 (returning as removed when the node was detached), and add an equivalent IN_PLACE detach check plus _neutralizeSubtree after afterSanitizeAttributes at 2670. As an interim mitigation without a code change, applications using IN_PLACE can avoid removing nodes inside afterSanitizeElements/afterSanitizeAttributes hooks and instead perform such removals in beforeSanitizeElements/uponSanitizeElement, or avoid IN_PLACE for attacker-influenced content.

Reported by zx (GitHub: @​manus-pi).

Severity

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

References

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


DOMPurify: IN_PLACE returns a force-removed rawtext root whose text carries attacker markup — pure HTML reparse executes

GHSA-6688-9rhm-gjv2

More information

Details

Environment
  • dompurify 3.4.15 (current npm release); reproduced independently on jsdom 30.0.1 and 29.1.1 (Node.js 20.x / 26.x)
  • Config: DOMPurify.sanitize(node, { IN_PLACE: true }) on a Node input; SAFE_FOR_XML at its default (true)
Summary

The 3.4.9 fix for the IN_PLACE detached-root class added two protections on the IN_PLACE return path: a fail-closed TypeError in _forceRemove when a node selected for removal cannot be detached, and a _neutralizeSubtree pass (dist/purify.js line 1336) that strips non-allowlisted attributes from removed subtrees.

Both miss the rawtext text-content form. When the force-removed root is a rawtext element (<style>), the payload lives in the node's text: the node detaches fine (the TypeError guard is not reached), _neutralizeSubtree strips nothing (there are no attributes), and the IN_PLACE exit returns the detached, never-sanitized <style> whose text still carries live markup. Serializing that node and re-parsing it in plain HTML context materializes the payload — no foreign-content context required.

The same Node input sanitized without IN_PLACE returns an empty result: the only difference is the IN_PLACE return path handing the killed node back.

Steps to reproduce
const { JSDOM } = require('jsdom');
const createDOMPurify = require('dompurify');   // 3.4.15

const window = new JSDOM('').window;
const DOMPurify = createDOMPurify(window);

const styleRoot = window.document.createElement('style');
styleRoot.setAttribute('onclick', 'alert(1)');    // attribute payload
styleRoot.textContent = '</style><img src=x onerror=1>';  // text payload
window.document.body.appendChild(styleRoot);

const returned = DOMPurify.sanitize(styleRoot, { IN_PLACE: true });

console.log(returned === styleRoot);                       // true (same node)
console.log(styleRoot.parentNode === null);                // true (detached)
console.log(styleRoot.outerHTML);
// <style></style><img src=x onerror=1></style>
console.log(styleRoot.getAttribute('onclick'));            // null  (attribute neutralized)
console.log(styleRoot.textContent);                        // '</style><img src=x onerror=1>' (text survives)

// plain HTML reparse (no foreign-content context involved):
const probe = window.document.createElement('div');
probe.innerHTML = returned.outerHTML || styleRoot.outerHTML;
console.log(probe.querySelectorAll('img').length);         // 1
console.log(probe.querySelector('img').getAttribute('onerror')); // "1"

Observed on 3.4.15: one node, one call — the onclick attribute is neutralized while the text payload (</style><img src=x onerror=1>) survives verbatim; serializing and re-parsing the returned node in plain HTML context materializes the img with the live onerror handler.

Contrast on the same Node input without IN_PLACE: RETURN_DOM: true → <body></body>; RETURN_DOM_FRAGMENT: true → 0 children — the payload is fully sanitized away. The only difference is the IN_PLACE return path.

Contrast on the removal trigger: SAFE_FOR_XML: false → the node is not removed (detached stays false); plain CSS text → not removed. The removal is gated by the mXSS text probes and happens specifically because the serialized node would re-open tags on reparse.

Root cause

_isUnsafeNode (dist/purify.js 3.4.15, lines 1700–1714) removes nodes whose literal text would re-open tags on reparse — shape (b) in the source comment is "text-only content that already carries the element's OWN end tag", detected by the LITERAL_TEXT_CLOSE probe (line 385) alongside the ELEMENT_MARKUP_PROBE (line 339) rules. _forceRemove (line 1122) records the node in DOMPurify.removed ({element}) and detaches it. The removal is intentional: the upstream comment states these shapes are removed because the literal serializer emits them verbatim for the HTML parser to re-open.

The IN_PLACE exit then hands the force-removed root back to the caller — the very node whose removal DOMPurify.removed just recorded (verified: DOMPurify.removed.some(e => e.element === root) is true on the returned instance). The 3.4.9 _neutralizeSubtree pass (line 1336) addresses only the attribute form — its own docstring: "walks a removed subtree and strips every attribute" (purpose: cancel queued resource events). Rawtext text content is out of its scope, so the removal that was performed specifically to prevent reparse is undone by returning the node: you removed it to stop the reparse, then returned it.

Differential (one node, one call, same removal path): the onclick attribute is neutralized by the existing pass while the text payload survives verbatim — the attribute axis is covered, the text axis is the gap.

Impact

Identical blast radius to the published IN_PLACE family: an application that sanitizes a Node in IN_PLACE mode and re-inserts (or serializes and then re-inserts) the result materializes attacker markup in plain HTML context: script execution in the page. Moving the returned node via appendChild alone is safe; the round trip through serialization is what fires the payload. No foreign-content context is required with the close-tag payload.

Affected versions
  • Verified live: 3.4.15 (current).
  • Source-verified: the attribute-only _neutralizeSubtree and the IN_PLACE return path are present in 3.4.9–3.4.14; releases before 3.4.9 predate the fix entirely (unconditional return; individual pre-3.4.9 releases not dynamically tested).
  • Per cure53 advisory convention the affected range is reported as <= 3.4.15 (current at time of writing).
Suggested remediation

Primary (root-cause, covers every form): at the IN_PLACE exit, check whether the returned root was recorded during sanitization — DOMPurify.removed.some(e => e.element === root) — and fail closed: throw the same TypeError style used by the 3.4.9 detach guard ("a node selected for removal could not be safely returned; refusing to sanitize in place"), or return null. This is consistent with the existing fail-closed design and covers all present and future root-kill reasons in one check.

Secondary (form-specific): extend _neutralizeSubtree to neutralize text content of rawtext descendants — the elements in LITERAL_TEXT_ELEMENT_NAMES (style, script, xmp, iframe, noembed, noframes, plaintext, noscript) — by rewriting textContent to a defanged form, matching the probe coverage of _isUnsafeNode/LITERAL_TEXT_CLOSE.

A regression test asserting that a force-removed rawtext root comes back with no /<[/\w!]/ match in textContent (and is not returned at all under the primary fix) prevents re-introduction.

Prior art / differentiation
  • GHSA-r47g-fvhr-h676 (fixed 3.4.6): clobbered-form root removal — different trigger; this report's root is a normal allowlisted style element killed by the text probe.
  • GHSA-55q2-fjhq-7xh7 (low): IN_PLACE hook removal leaves a detached subtree executable — the attribute-form twin (hook-stripped subtree retains onload-class handlers). This report's rawtext text form is not covered by _neutralizeSubtree's attribute stripping and is not that advisory.
  • GHSA-h8r8-wccr-v5f2 (medium): mXSS via re-contextualization in the standard (non-IN_PLACE) serialize path — different mechanism; IN_PLACE is not involved.
  • The 3.4.9 release notes credit @​mozfreedyb for the IN_PLACE handling improvements that this residual escapes on the text axis.
Applicability scope (stated up front)

The payload materializes when the application serializes and re-parses the sanitizer output (innerHTML assignment, template rendering, markdown/HTML round trips) or otherwise consumes the returned node's markup. Moving the returned node via appendChild alone does not trigger it. Applications that pass live, connected attacker trees into IN_PLACE are explicitly warned against by upstream's own source comment; this report concerns the serialize-and-reinsert consumption pattern that the IN_PLACE mode exists to serve.

Severity

Low

References

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


Release Notes

cure53/DOMPurify (dompurify)

v3.4.16: DOMPurify 3.4.16

Compare Source

  • Fixed a problem with IN_PLACE node removal when working with hooks, thanks @​manus-pi
  • Fixed a problem with IN_PLACE sanitization and raw-text roots, thanks @​h-t-m
  • Fixed a problem with ESM default exports landing in CommonJS declarations, thanks @​ssi02014
  • Migrated from rollup to rolldown because performance, thanks @​ssi02014
  • Bumped several dependencies where possible

Configuration

📅 Schedule: (UTC)

  • Branch creation
    • At any time (no schedule defined)
  • 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-actions

github-actions Bot commented Oct 5, 2026 •

Copy link
Copy Markdown
Contributor

📦 Bundle Size Report

Metric Current Previous Change Status
Total (gzip) 226.39 kB 226.39 kB 0 B (0%) 🟢
Total (raw) 632.02 kB 632.02 kB 0 B (0%) 🟢
CSS (gzip) 21.94 kB 21.94 kB 0 B (0%) 🟢
CSS (raw) 114.43 kB 114.43 kB 0 B (0%) 🟢

Size Limits

  • ✅ Total gzipped: 226.39 kB / 350 kB (64.7%)
  • ✅ Total raw: 632.02 kB / 850 kB (74.4%)
  • ✅ CSS gzipped: 21.94 kB / 25 kB (87.8%)

Largest Files (Top 5)

  1. index.esm-wIkXrqU6.js - 11.4 kB (0 B (0%))
  2. styles.css - 10.97 kB (0 B (0%))
  3. index.css - 10.97 kB (0 B (0%))
  4. internals-60vKS2gi.js - 6.14 kB (0 B (0%))
  5. hooks-AI3ANODo.js - 5.85 kB (0 B (0%))
View All Files (289 total)
File Size (gzip) Change
index.esm-wIkXrqU6.js 11.4 kB 0 B (0%)
styles.css 10.97 kB 0 B (0%)
index.css 10.97 kB 0 B (0%)
internals-60vKS2gi.js 6.14 kB 0 B (0%)
hooks-AI3ANODo.js 5.85 kB 0 B (0%)
index.js 5.52 kB 0 B (0%)
sdk.gen-hikpofx9.js 5.48 kB 0 B (0%)
flows/Onboarding/hooks.js 4.42 kB 0 B (0%)
utils-qfe-oQBs.js 4.07 kB 0 B (0%)
FieldSetField-Bds5UIuj.js 4.03 kB 0 B (0%)

✅ Bundle size check passed

@github-actions

github-actions Bot commented Oct 5, 2026 •

Copy link
Copy Markdown
Contributor

Deploy preview for adp-cost-calculator ready!

Project:adp-cost-calculator
Status: ✅  Deploy successful!
Preview URL:https://adp-cost-calculator-i2xhg1cqm-remotecom.vercel.app
Latest Commit:cf8664e

Deployed with vercel-action

@github-actions

github-actions Bot commented Oct 5, 2026 •

Copy link
Copy Markdown
Contributor

Deploy preview for remote-flows ready!

Project:remote-flows
Status: ✅  Deploy successful!
Preview URL:https://remote-flows-d1uenv17z-remotecom.vercel.app
Latest Commit:cf8664e

Deployed with vercel-action

@github-actions

github-actions Bot commented Oct 5, 2026 •

Copy link
Copy Markdown
Contributor

📊 Coverage Report

⚪ Coverage unchanged

Metric Current Previous Change Status
Lines 86.82% 86.82% 0% ⚪
Statements 86.39% 86.39% 0% ⚪
Functions 85.42% 85.42% 0% ⚪
Branches 78.19% 78.19% 0% ⚪

Detailed Breakdown

Lines Coverage
  • Covered: 5006 / 5766
  • Coverage: 86.82%
  • Change: 0% (0 lines)
Statements Coverage
  • Covered: 5095 / 5898
  • Coverage: 86.39%
  • Change: 0% (0 statements)
Functions Coverage
  • Covered: 1330 / 1557
  • Coverage: 85.42%
  • Change: 0% (0 functions)
Branches Coverage
  • Covered: 3093 / 3956
  • Coverage: 78.19%
  • Change: 0% (0 branches)

✅ Coverage check passed

@renovate
renovate Bot force-pushed the renovate/npm-dompurify-vulnerability branch from 215be38 to cf8664e Compare October 6, 2026 15:32

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants