Track: DOMPurify advisories via monaco-editor's pinned dompurify@3.2.7

[huhamhire]

Long-term tracking issue for the DOMPurify Dependabot advisories (deliberately not patched now — see rationale).

Root cause

All the open dompurify alerts trace to one copy: dompurify@3.2.7, which monaco-editor pins exactly:

node_modules/monaco-editor → dompurify 3.2.7   (vulnerable)
node_modules/mermaid       → dompurify ^3.3.1 → 3.4.11 (already patched, not the concern)

Monaco uses DOMPurify internally to sanitize its markdown / hover rendering. Because monaco pins an exact version, it can't float up on its own.

Why it is not fixed now

• The proper fix is a monaco-editor release that bumps its pinned dompurify. There is no such release yet.
• Per repo policy (AGENTS.md, "Vulnerability-alert fixes — no overrides"), we do not force transitive versions with npm overrides — they mask the dependency graph and break on the parent's next update.
• One advisory (Release 0.3.0 #19, IN_PLACE attacker-controlled nodeName) currently has no fix in any dompurify version, so even a bump wouldn't clear it yet.

Risk scope (why deferring is acceptable)

Monaco renders code + PR/comment metadata from the connected code platforms inside a sandboxed Electron renderer. The advisories are largely IN_PLACE / config-pollution XSS vectors that require attacker-controlled DOM objects or setConfig/clearConfig call paths the app does not expose to untrusted input — so real-world exploitability here is low. This is defense-in-depth, not a live hole. (Scoping urgency, not dismissing.)

Resolution / close condition

• Bump monaco-editor once it ships a release pinning dompurify ≥ 3.4.11, then npm ls dompurify to confirm the vulnerable 3.2.7 copy is gone.
• Close the remaining advisory (Release 0.3.0 #19) once upstream DOMPurify publishes a fix and it flows through monaco.

Open alerts (as of filing)

dompurify (runtime package-lock.json): #1, #2, #3, #4, #5, #6, #7, #8, #16, #17, #18, #19, #20, #21, #22, #23.

[huhamhire]

Status update: monaco-editor 0.56.0 shrinks this a lot, but does not close it

Upgrading monaco-editor 0.55.1 → 0.56.0 moves its pinned dompurify from 3.2.7 → 3.4.8. The vulnerable 3.2.7 copy is gone:

monaco-editor@0.56.0 -> dompurify@3.4.8
mermaid@11.15.0      -> dompurify@3.4.11

The 16 alerts filed above (#1–#8, #16–#23) collapse to 4. But the close condition in this issue — "bump once monaco pins dompurify ≥ 3.4.11" — turns out to be the wrong bar: new advisories have since widened the affected range past 3.4.11, so mermaid''s copy is now in scope too. What remains, against 3.4.8:

Advisory	Affected	Fixed in
GHSA-cmwh-pvxp-8882 — ALLOWED_ATTR pollution via setConfig()	<=3.4.10	3.4.11
GHSA-vxr8-fq34-vvx9 — Trusted Types policy survives clearConfig()	<3.4.9	3.4.9
GHSA-c2j3-45gr-mqc4 — CUSTOM_ELEMENT_HANDLING bypasses afterSanitizeElements	<=3.4.11	3.4.12
GHSA-55q2-fjhq-7xh7 — IN_PLACE detached subtree stays executable	<=3.4.12	none yet

The first three need dompurify ≥ 3.4.12, which needs another monaco release. The fourth is the one previously tracked as #19: still unfixed in any published dompurify, so no upgrade clears it today.

npm audit proposes "fix" by moving monaco to 0.53.0 — that is a downgrade to an older, more vulnerable copy, and is not taken.

The risk assessment in the issue body is unchanged: these are setConfig / clearConfig / IN_PLACE config-pollution vectors, and the app does not route untrusted input into those call paths. Defense-in-depth, not a live hole.

Revised close condition

• monaco pins dompurify ≥ 3.4.11 → superseded; 3.4.11 is itself in scope now
• monaco ships a release pinning dompurify ≥ 3.4.12 (clears the first three)
• DOMPurify publishes a fix for GHSA-55q2-fjhq-7xh7 and it flows through monaco (clears the fourth)