Repository navigation
chore(deps): update dependency dompurify to v3.4.16 [security] - #1445
Open
renovate[bot] wants to merge 1 commit into
Open
renovate[bot] wants to merge 1 commit into
renovate[bot] wants to merge 1 commit into
Conversation
Contributor
📦 Bundle Size Report
Size Limits
Largest Files (Top 5)
View All Files (289 total)
✅ Bundle size check passed |
Contributor
|
Deploy preview for adp-cost-calculator ready!
Deployed with vercel-action |
Contributor
|
Deploy preview for remote-flows ready!
Deployed with vercel-action |
Contributor
📊 Coverage Report⚪ Coverage unchanged
Detailed BreakdownLines Coverage
Statements Coverage
Functions Coverage
Branches Coverage
✅ Coverage check passed |
renovate
Bot
force-pushed
the
renovate/npm-dompurify-vulnerability
branch
from
October 6, 2026 15:32
215be38 to
cf8664e
Compare
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
3.4.15→3.4.16DOMPurify: 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_PLACEmode 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 thebeforeSanitizeElementsanduponSanitizeElementhook sites. AnafterSanitizeElementsorafterSanitizeAttributeshook that removes a non-root element (a documented, supported pattern) detaches that element's subtree with no neutralization, so descendanton*handlers remain armed on the caller's live tree aftersanitize()returns, yielding DOM XSS. No special privilege is required beyond supplying markup to an application that usesIN_PLACEtogether with a node-removing afterSanitize hook.Root Cause
IN_PLACEsanitization mutates the caller's live document, so any element a hook detaches from that tree must have its subtree neutralized beforesanitize()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_neutralizeSubtreeinIN_PLACE) is invoked only afterbeforeSanitizeElementsand afteruponSanitizeElement. It is never invoked from the afterSanitize return paths, and_sanitizeAttributesnever calls it at all. The post-walkIN_PLACEneutralization pass iterates onlyDOMPurify.removed, and hook-detached nodes are intentionally not recorded there, so that pass cannot reach them either.Impact
An attacker who supplies markup processed by a victim application that runs
DOMPurify.sanitize(node, { IN_PLACE: true })and registers a node-removingafterSanitizeElementsorafterSanitizeAttributeshook can retain arbitraryon*event handlers on descendants of a removed non-root element. BecauseIN_PLACEoperates on the caller's live document, a queued resource-event handler on such a descendant fires in the page origin after the synchronoussanitize()call returns, giving script execution in the victim's session (DOM XSS). This defeats DOMPurify'sIN_PLACEcontract 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
Reproduction steps:
#root > section#wrap > img[onerror]where#rootis the walk root andsection#wrapis a non-root wrapper.afterSanitizeElements(orafterSanitizeAttributes) hook that callsnode.remove()on the wrapper.DOMPurify.sanitize(root, { IN_PLACE: true }).<img>retains itsonerrorhandler, whereas the same removal performed in abeforeSanitizeElements/uponSanitizeElementhook strips it.Attack Chain
DOMPurify.sanitize(liveNode, { IN_PLACE: true })on attacker-influenced markup and has registered a node-removingafterSanitizeElementsorafterSanitizeAttributeshook per an application policy (src/purify.ts:3026walk,2136element pass,2522attribute pass).on*resource-event handler such as<img src=x onerror=...>._handleHookDetachedNoderuns only afterbeforeSanitizeElements(2142) anduponSanitizeElement(2175); it is absent afterafterSanitizeElements(2208,2249) and is never called by_sanitizeAttributes(afterSanitizeAttributes at2670). The NodeIterator advances past the detached subtree, so the descendants are never revisited, and the post-walk pass iterates onlyDOMPurify.removed, which excludes hook-detached nodes.on*handler on the caller's live document aftersanitize()returns.IN_PLACEsanitization.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_neutralizeSubtreeat thebeforeSanitizeElementsanduponSanitizeElementdetach 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_handleHookDetachedNodeatsrc/purify.ts:2142and2175. A subsequent hardening change (#1616) added arootWasRemovedthrow and a neutralization sweep overDOMPurify.removed, but that sweep still iterates onlyDOMPurify.removed, which by design excludes hook-detached non-root nodes, so it does not close this gap. TheafterSanitizeElements-on-kept-custom-element site at2208was 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
onerroris 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 fromDOMPurify.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 insideafterSanitizeElements. 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: npmPackage: dompurifyConfirmed affected range: >= 3.4.13, <= 3.4.15Latest release checked: 3.4.15 (npm registry)Fix status: fixed in 3.4.16The 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_PLACEdetach-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 afterafterSanitizeElementsat bothsrc/purify.ts:2208and2249(returning as removed when the node was detached), and add an equivalentIN_PLACEdetach check plus_neutralizeSubtreeafterafterSanitizeAttributesat2670. As an interim mitigation without a code change, applications usingIN_PLACEcan avoid removing nodes insideafterSanitizeElements/afterSanitizeAttributeshooks and instead perform such removals inbeforeSanitizeElements/uponSanitizeElement, or avoidIN_PLACEfor attacker-influenced content.Reported by zx (GitHub: @manus-pi).
Severity
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:L/VA:N/SC:N/SI:N/SA:NReferences
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.sanitize(node, { IN_PLACE: true })on a Node input;SAFE_FOR_XMLat 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
TypeErrorin_forceRemovewhen a node selected for removal cannot be detached, and a_neutralizeSubtreepass (dist/purify.jsline 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 (theTypeErrorguard is not reached),_neutralizeSubtreestrips 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_PLACEreturns an empty result: the only difference is the IN_PLACE return path handing the killed node back.Steps to reproduce
Observed on 3.4.15: one node, one call — the
onclickattribute 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 theimgwith the liveonerrorhandler.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.js3.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 theLITERAL_TEXT_CLOSEprobe (line 385) alongside theELEMENT_MARKUP_PROBE(line 339) rules._forceRemove(line 1122) records the node inDOMPurify.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.removedjust recorded (verified:DOMPurify.removed.some(e => e.element === root)istrueon the returned instance). The 3.4.9_neutralizeSubtreepass (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
onclickattribute 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_PLACEmode 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 viaappendChildalone 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
_neutralizeSubtreeand 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).<= 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 sameTypeErrorstyle used by the 3.4.9 detach guard ("a node selected for removal could not be safely returned; refusing to sanitize in place"), or returnnull. 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
_neutralizeSubtreeto neutralize text content of rawtext descendants — the elements inLITERAL_TEXT_ELEMENT_NAMES(style,script,xmp,iframe,noembed,noframes,plaintext,noscript) — by rewritingtextContentto 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 intextContent(and is not returned at all under the primary fix) prevents re-introduction.Prior art / differentiation
styleelement killed by the text probe._neutralizeSubtree's attribute stripping and is not that advisory.Applicability scope (stated up front)
The payload materializes when the application serializes and re-parses the sanitizer output (
innerHTMLassignment, template rendering, markdown/HTML round trips) or otherwise consumes the returned node's markup. Moving the returned node viaappendChildalone does not trigger it. Applications that pass live, connected attacker trees intoIN_PLACEare 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.16Compare Source
IN_PLACEnode removal when working with hooks, thanks @manus-piIN_PLACEsanitization and raw-text roots, thanks @h-t-mrolluptorolldownbecause performance, thanks @ssi02014Configuration
📅 Schedule: (UTC)
🚦 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.
This PR was generated by Mend Renovate. View the repository job log.