Vulnerable Library - vivid-5.15.1.tgz
Path to dependency file: /tutorials/vonage_video_react_app-feature-config/project/package.json
Path to vulnerable library: /tutorials/vonage_video_react_app-feature-config/project/package.json
Found in HEAD commit: f400f39c07df86338418f7902a27a7c22c1442b4
Vulnerabilities
*For some transitive vulnerabilities, there is no version of direct dependency with a fix. Check the "Details" section below to see if there is a version of transitive dependency where vulnerability is fixed.
**In some cases, Remediation PR cannot be created automatically for a vulnerability despite the availability of remediation
Details
Partial details (11 vulnerabilities) are displayed below due to a content size limitation in GitHub. To view information on the remaining vulnerabilities, navigate to the Mend Application.
CVE-2026-41907
Vulnerable Library - uuid-11.1.0.tgz
RFC9562 UUIDs
Library home page: https://registry.npmjs.org/uuid/-/uuid-11.1.0.tgz
Path to dependency file: /tutorials/vonage_video_react_app-feature-config/project/package.json
Path to vulnerable library: /tutorials/vonage_video_react_app-feature-config/project/package.json
Dependency Hierarchy:
- vivid-5.15.1.tgz (Root Library)
- ❌ uuid-11.1.0.tgz (Vulnerable Library)
Found in HEAD commit: f400f39c07df86338418f7902a27a7c22c1442b4
Found in base branch: main
Vulnerability Details
uuid is for the creation of RFC9562 (formerly RFC4122) UUIDs. Prior to 14.0.0, v3, v5, and v6 accept external output buffers but do not reject out-of-range writes (small buf or large offset). This allows silent partial writes into caller-provided buffers. This vulnerability is fixed in 14.0.0.
Publish Date: 2026-04-24
URL: CVE-2026-41907
CVSS 3 Score Details (9.8)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: High
- Integrity Impact: High
- Availability Impact: High
For more information on CVSS3 Scores, click here.
Suggested Fix
Type: Upgrade version
Origin: GHSA-w5hq-g745-h8pq
Release Date: 2026-04-24
Fix Resolution: https://github.com/uuidjs/uuid.git - v11.1.1,https://github.com/uuidjs/uuid.git - v12.0.1,https://github.com/uuidjs/uuid.git - v13.0.1
CVE-2026-41675
Vulnerable Library - xmldom-0.8.11.tgz
A pure JavaScript W3C standard-based (XML DOM Level 2 Core) DOMParser and XMLSerializer module.
Library home page: https://registry.npmjs.org/@xmldom/xmldom/-/xmldom-0.8.11.tgz
Path to dependency file: /tutorials/vonage_video_react_app-feature-config/project/package.json
Path to vulnerable library: /tutorials/vonage_video_react_app-feature-config/project/package.json
Dependency Hierarchy:
- vivid-5.15.1.tgz (Root Library)
- video.js-8.23.7.tgz
- mpd-parser-1.3.1.tgz
- ❌ xmldom-0.8.11.tgz (Vulnerable Library)
Found in HEAD commit: f400f39c07df86338418f7902a27a7c22c1442b4
Found in base branch: main
Vulnerability Details
xmldom is a pure JavaScript W3C standard-based (XML DOM Level 2 Core) "DOMParser" and "XMLSerializer" module. In @xmldom/xmldom prior to versions 0.9.10 and 0.8.13 and xmldom version 0.6.0 and prior, the package allows attacker-controlled processing instruction data to be serialized into XML without validating or neutralizing the PI-closing sequence ?>. As a result, an attacker can terminate the processing instruction early and inject arbitrary XML nodes into the serialized output. This issue has been patched in versions @xmldom/xmldom versions 0.9.10 and 0.8.13.
Publish Date: 2026-05-07
URL: CVE-2026-41675
CVSS 3 Score Details (7.5)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: High
- Availability Impact: None
For more information on CVSS3 Scores, click here.
Suggested Fix
Type: Upgrade version
Release Date: 2026-04-22
Fix Resolution: https://github.com/xmldom/xmldom.git - 0.8.13,https://github.com/xmldom/xmldom.git - 0.9.10
CVE-2026-41674
Vulnerable Library - xmldom-0.8.11.tgz
A pure JavaScript W3C standard-based (XML DOM Level 2 Core) DOMParser and XMLSerializer module.
Library home page: https://registry.npmjs.org/@xmldom/xmldom/-/xmldom-0.8.11.tgz
Path to dependency file: /tutorials/vonage_video_react_app-feature-config/project/package.json
Path to vulnerable library: /tutorials/vonage_video_react_app-feature-config/project/package.json
Dependency Hierarchy:
- vivid-5.15.1.tgz (Root Library)
- video.js-8.23.7.tgz
- mpd-parser-1.3.1.tgz
- ❌ xmldom-0.8.11.tgz (Vulnerable Library)
Found in HEAD commit: f400f39c07df86338418f7902a27a7c22c1442b4
Found in base branch: main
Vulnerability Details
xmldom is a pure JavaScript W3C standard-based (XML DOM Level 2 Core) "DOMParser" and "XMLSerializer" module. In @xmldom/xmldom prior to versions 0.9.10 and 0.8.13 and xmldom version 0.6.0 and prior, the package serializes DocumentType node fields (internalSubset, publicId, systemId) verbatim without any escaping or validation. When these fields are set programmatically to attacker-controlled strings, XMLSerializer.serializeToString can produce output where the DOCTYPE declaration is terminated early and arbitrary markup appears outside it. This issue has been patched in versions @xmldom/xmldom versions 0.9.10 and 0.8.13.
Publish Date: 2026-05-07
URL: CVE-2026-41674
CVSS 3 Score Details (7.5)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: High
- Availability Impact: None
For more information on CVSS3 Scores, click here.
Suggested Fix
Type: Upgrade version
Release Date: 2026-04-22
Fix Resolution: https://github.com/xmldom/xmldom.git - 0.8.13,https://github.com/xmldom/xmldom.git - 0.9.10
CVE-2026-41673
Vulnerable Library - xmldom-0.8.11.tgz
A pure JavaScript W3C standard-based (XML DOM Level 2 Core) DOMParser and XMLSerializer module.
Library home page: https://registry.npmjs.org/@xmldom/xmldom/-/xmldom-0.8.11.tgz
Path to dependency file: /tutorials/vonage_video_react_app-feature-config/project/package.json
Path to vulnerable library: /tutorials/vonage_video_react_app-feature-config/project/package.json
Dependency Hierarchy:
- vivid-5.15.1.tgz (Root Library)
- video.js-8.23.7.tgz
- mpd-parser-1.3.1.tgz
- ❌ xmldom-0.8.11.tgz (Vulnerable Library)
Found in HEAD commit: f400f39c07df86338418f7902a27a7c22c1442b4
Found in base branch: main
Vulnerability Details
xmldom is a pure JavaScript W3C standard-based (XML DOM Level 2 Core) "DOMParser" and "XMLSerializer" module. In @xmldom/xmldom prior to versions 0.9.10 and 0.8.13 and xmldom version 0.6.0 and prior, seven recursive traversals in lib/dom.js operate without a depth limit. A sufficiently deeply nested DOM tree causes a RangeError: Maximum call stack size exceeded, crashing the application. This issue has been patched in versions @xmldom/xmldom versions 0.9.10 and 0.8.13.
Publish Date: 2026-05-07
URL: CVE-2026-41673
CVSS 3 Score Details (7.5)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: None
- Availability Impact: High
For more information on CVSS3 Scores, click here.
Suggested Fix
Type: Upgrade version
Release Date: 2026-04-22
Fix Resolution: https://github.com/xmldom/xmldom.git - 0.8.13,https://github.com/xmldom/xmldom.git - 0.9.10
CVE-2026-41672
Vulnerable Library - xmldom-0.8.11.tgz
A pure JavaScript W3C standard-based (XML DOM Level 2 Core) DOMParser and XMLSerializer module.
Library home page: https://registry.npmjs.org/@xmldom/xmldom/-/xmldom-0.8.11.tgz
Path to dependency file: /tutorials/vonage_video_react_app-feature-config/project/package.json
Path to vulnerable library: /tutorials/vonage_video_react_app-feature-config/project/package.json
Dependency Hierarchy:
- vivid-5.15.1.tgz (Root Library)
- video.js-8.23.7.tgz
- mpd-parser-1.3.1.tgz
- ❌ xmldom-0.8.11.tgz (Vulnerable Library)
Found in HEAD commit: f400f39c07df86338418f7902a27a7c22c1442b4
Found in base branch: main
Vulnerability Details
xmldom is a pure JavaScript W3C standard-based (XML DOM Level 2 Core) "DOMParser" and "XMLSerializer" module. In @xmldom/xmldom prior to versions 0.9.10 and 0.8.13 and xmldom version 0.6.0 and prior, the package allows attacker-controlled comment content to be serialized into XML without validating or neutralizing comment-breaking sequences. As a result, an attacker can terminate the comment early and inject arbitrary XML nodes into the serialized output. This issue has been patched in versions @xmldom/xmldom versions 0.9.10 and 0.8.13.
Publish Date: 2026-05-07
URL: CVE-2026-41672
CVSS 3 Score Details (7.5)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: High
- Availability Impact: None
For more information on CVSS3 Scores, click here.
Suggested Fix
Type: Upgrade version
Release Date: 2026-04-22
Fix Resolution: https://github.com/xmldom/xmldom.git - 0.8.13,https://github.com/xmldom/xmldom.git - 0.9.10
CVE-2026-34601
Vulnerable Library - xmldom-0.8.11.tgz
A pure JavaScript W3C standard-based (XML DOM Level 2 Core) DOMParser and XMLSerializer module.
Library home page: https://registry.npmjs.org/@xmldom/xmldom/-/xmldom-0.8.11.tgz
Path to dependency file: /tutorials/vonage_video_react_app-feature-config/project/package.json
Path to vulnerable library: /tutorials/vonage_video_react_app-feature-config/project/package.json
Dependency Hierarchy:
- vivid-5.15.1.tgz (Root Library)
- video.js-8.23.7.tgz
- mpd-parser-1.3.1.tgz
- ❌ xmldom-0.8.11.tgz (Vulnerable Library)
Found in HEAD commit: f400f39c07df86338418f7902a27a7c22c1442b4
Found in base branch: main
Vulnerability Details
xmldom is a pure JavaScript W3C standard-based (XML DOM Level 2 Core) "DOMParser" and "XMLSerializer" module. In xmldom versions 0.6.0 and prior and @xmldom/xmldom prior to versions 0.8.12 and 0.9.9, xmldom/xmldom allows attacker-controlled strings containing the CDATA terminator ]]> to be inserted into a CDATASection node. During serialization, XMLSerializer emitted the CDATA content verbatim without rejecting or safely splitting the terminator. As a result, data intended to remain text-only became active XML markup in the serialized output, enabling XML structure injection and downstream business-logic manipulation. This issue has been patched in xmldom version 0.6.0 and @xmldom/xmldom versions 0.8.12 and 0.9.9.
Publish Date: 2026-04-02
URL: CVE-2026-34601
CVSS 3 Score Details (7.5)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: High
- Availability Impact: None
For more information on CVSS3 Scores, click here.
Suggested Fix
Type: Upgrade version
Release Date: 2026-04-01
Fix Resolution: https://github.com/xmldom/xmldom.git - 0.9.9
CVE-2026-41238
Vulnerable Library - dompurify-3.3.3.tgz
DOMPurify is a DOM-only, super-fast, uber-tolerant XSS sanitizer for HTML, MathML and SVG. It's written in JavaScript and works in all modern browsers (Safari, Opera (15+), Internet Explorer (10+), Firefox and Chrome - as well as almost anything else usin
Library home page: https://registry.npmjs.org/dompurify/-/dompurify-3.3.3.tgz
Path to dependency file: /tutorials/vonage_video_react_app-feature-config/project/package.json
Path to vulnerable library: /tutorials/vonage_video_react_app-feature-config/project/package.json
Dependency Hierarchy:
- vivid-5.15.1.tgz (Root Library)
- ❌ dompurify-3.3.3.tgz (Vulnerable Library)
Found in HEAD commit: f400f39c07df86338418f7902a27a7c22c1442b4
Found in base branch: main
Vulnerability 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.
Mend Note: The description of this vulnerability differs from MITRE.
Publish Date: 2026-04-23
URL: CVE-2026-41238
CVSS 3 Score Details (6.9)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: High
- Privileges Required: None
- User Interaction: Required
- Scope: Changed
- Impact Metrics:
- Confidentiality Impact: High
- Integrity Impact: Low
- Availability Impact: None
For more information on CVSS3 Scores, click here.
Suggested Fix
Type: Upgrade version
Origin: GHSA-v9jr-rg53-9pgp
Release Date: 2026-04-22
Fix Resolution (dompurify): 3.4.0
Direct dependency fix Resolution (@vonage/vivid): 5.16.0
⛑️ Automatic Remediation will be attempted for this issue.
CVE-2026-41239
Vulnerable Library - dompurify-3.3.3.tgz
DOMPurify is a DOM-only, super-fast, uber-tolerant XSS sanitizer for HTML, MathML and SVG. It's written in JavaScript and works in all modern browsers (Safari, Opera (15+), Internet Explorer (10+), Firefox and Chrome - as well as almost anything else usin
Library home page: https://registry.npmjs.org/dompurify/-/dompurify-3.3.3.tgz
Path to dependency file: /tutorials/vonage_video_react_app-feature-config/project/package.json
Path to vulnerable library: /tutorials/vonage_video_react_app-feature-config/project/package.json
Dependency Hierarchy:
- vivid-5.15.1.tgz (Root Library)
- ❌ dompurify-3.3.3.tgz (Vulnerable Library)
Found in HEAD commit: f400f39c07df86338418f7902a27a7c22c1442b4
Found in base branch: main
Vulnerability Details
Summary | Field | Value | |:------|:------| | Severity | Medium | | Affected | DOMPurify "main" at ""883ac15"" (https://github.com/cure53/DOMPurify/tree/883ac15d47f907cb1a3b5a152fe90c4d8c10f9e6), introduced in v1.0.10 (""7fc196db"" (cure53/DOMPurify@7fc196d)) | "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: 1. Per-node — each text node is checked during the tree walk (""purify.ts:1179-1191"" (https://github.com/cure53/DOMPurify/blob/883ac15d47f907cb1a3b5a152fe90c4d8c10f9e6/src/purify.ts#L1179-L1191)): // pass #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; } 2. Final string scrub — after serialization, the full HTML string is scrubbed again (""purify.ts:1679-1683"" (https://github.com/cure53/DOMPurify/blob/883ac15d47f907cb1a3b5a152fe90c4d8c10f9e6/src/purify.ts#L1679-L1683)). 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"" (https://github.com/cure53/DOMPurify/blob/883ac15d47f907cb1a3b5a152fe90c4d8c10f9e6/src/purify.ts#L1637-L1661)): // purify.ts (simplified) if (RETURN_DOM) { // ... build returnNode ... return returnNode; // <-- exits here, pass #2 never runs } // pass #2: only reached by string-mode callers if (SAFE_FOR_TEMPLATES) { serializedHTML = serializedHTML.replace(MUSTACHE_EXPR, ' '); } return serializedHTML; The payload "{{constructor.constructor('alert(1)')()}}" exploits this: 3. Parser creates: "TEXT("{")" → "" → "TEXT("{payload}")" → "" → "TEXT("}")" — no single node contains "{{", so pass #1 misses it 4. "" is not allowed, so DOMPurify removes it but keeps surrounding text 5. The three text nodes are now adjacent — ".outerHTML" reads them as "{{payload}}", which Vue 2 compiles and executes
Mend Note: The description of this vulnerability differs from MITRE.
Publish Date: 2026-04-23
URL: CVE-2026-41239
CVSS 3 Score Details (6.8)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: High
- Privileges Required: None
- User Interaction: Required
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: High
- Integrity Impact: High
- Availability Impact: None
For more information on CVSS3 Scores, click here.
Suggested Fix
Type: Upgrade version
Origin: GHSA-crv5-9vww-q3g8
Release Date: 2026-04-22
Fix Resolution (dompurify): 3.4.0
Direct dependency fix Resolution (@vonage/vivid): 5.16.0
⛑️ Automatic Remediation will be attempted for this issue.
CVE-2026-41240
Vulnerable Library - dompurify-3.3.3.tgz
DOMPurify is a DOM-only, super-fast, uber-tolerant XSS sanitizer for HTML, MathML and SVG. It's written in JavaScript and works in all modern browsers (Safari, Opera (15+), Internet Explorer (10+), Firefox and Chrome - as well as almost anything else usin
Library home page: https://registry.npmjs.org/dompurify/-/dompurify-3.3.3.tgz
Path to dependency file: /tutorials/vonage_video_react_app-feature-config/project/package.json
Path to vulnerable library: /tutorials/vonage_video_react_app-feature-config/project/package.json
Dependency Hierarchy:
- vivid-5.15.1.tgz (Root Library)
- ❌ dompurify-3.3.3.tgz (Vulnerable Library)
Found in HEAD commit: f400f39c07df86338418f7902a27a7c22c1442b4
Found in base branch: main
Vulnerability Details
There is an inconsistency between FORBID_TAGS and FORBID_ATTR handling when function-based ADD_TAGS is used. Commit "c361baa" (cure53/DOMPurify@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.
Mend Note: The description of this vulnerability differs from MITRE.
Publish Date: 2026-04-23
URL: CVE-2026-41240
CVSS 3 Score Details (6.5)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: Required
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: High
- Availability Impact: None
For more information on CVSS3 Scores, click here.
Suggested Fix
Type: Upgrade version
Origin: GHSA-h7mw-gpvr-xq4m
Release Date: 2026-04-23
Fix Resolution (dompurify): 3.4.0
Direct dependency fix Resolution (@vonage/vivid): 5.16.0
⛑️ Automatic Remediation will be attempted for this issue.
CVE-2026-49978
Vulnerable Library - dompurify-3.3.3.tgz
DOMPurify is a DOM-only, super-fast, uber-tolerant XSS sanitizer for HTML, MathML and SVG. It's written in JavaScript and works in all modern browsers (Safari, Opera (15+), Internet Explorer (10+), Firefox and Chrome - as well as almost anything else usin
Library home page: https://registry.npmjs.org/dompurify/-/dompurify-3.3.3.tgz
Path to dependency file: /tutorials/vonage_video_react_app-feature-config/project/package.json
Path to vulnerable library: /tutorials/vonage_video_react_app-feature-config/project/package.json
Dependency Hierarchy:
- vivid-5.15.1.tgz (Root Library)
- ❌ dompurify-3.3.3.tgz (Vulnerable Library)
Found in HEAD commit: f400f39c07df86338418f7902a27a7c22c1442b4
Found in base branch: main
Vulnerability Details
If the HTML you give it contains a element, and inside that template there's an element with a shadow DOM attached to it, DOMPurify quietly skips over the shadow contents. Whatever the attacker put in there - an image with an onerror handler, a link with a javascript: URL, even a full script - survives untouched. The moment the application uses that template the way templates are meant to be used (cloning it and inserting the result into the page), the malicious payload comes along and runs as if it had never been sanitized. From there an attacker gets everything XSS normally gets them: session cookies, stored tokens, the ability to act as the user, and the ability to leave persistent payloads behind for the next person who visits. "advisory.pdf" (https://github.com/user-attachments/files/28275600/advisory.pdf) "poc.html" (https://github.com/user-attachments/files/28275708/poc.html)
Publish Date: 2026-06-15
URL: CVE-2026-49978
CVSS 3 Score Details (6.1)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: Required
- Scope: Changed
- Impact Metrics:
- Confidentiality Impact: Low
- Integrity Impact: Low
- Availability Impact: None
For more information on CVSS3 Scores, click here.
Suggested Fix
Type: Upgrade version
Release Date: 2026-06-15
Fix Resolution: https://github.com/cure53/DOMPurify.git - 3.4.7
CVE-2026-49459
Vulnerable Library - dompurify-3.3.3.tgz
DOMPurify is a DOM-only, super-fast, uber-tolerant XSS sanitizer for HTML, MathML and SVG. It's written in JavaScript and works in all modern browsers (Safari, Opera (15+), Internet Explorer (10+), Firefox and Chrome - as well as almost anything else usin
Library home page: https://registry.npmjs.org/dompurify/-/dompurify-3.3.3.tgz
Path to dependency file: /tutorials/vonage_video_react_app-feature-config/project/package.json
Path to vulnerable library: /tutorials/vonage_video_react_app-feature-config/project/package.json
Dependency Hierarchy:
- vivid-5.15.1.tgz (Root Library)
- ❌ dompurify-3.3.3.tgz (Vulnerable Library)
Found in HEAD commit: f400f39c07df86338418f7902a27a7c22c1442b4
Found in base branch: main
Vulnerability Details
IN_PLACE mode preserves attributes of a clobbered root element, allowing XSS via attacker-controlled root DOM CWE: CWE-79 (XSS — Improper Neutralization of Input During Web Page Generation) via CWE-693 (Protection Mechanism Failure — silent no-op when "_forceRemove" is called on a parent-less node) Summary When "DOMPurify.sanitize(root, { IN_PLACE: true })" is called and "root" is a "
" whose own attributes carry an event handler ("onmouseover", "onfocus", "onclick", etc.), a single descendant element with a "name=" attribute matching any of the property names "_isClobbered" checks ("nodeName", "setAttribute", "namespaceURI", "insertBefore", "hasChildNodes", "childNodes") is sufficient to bypass attribute sanitization on the root. "_forceRemove" silently no-ops because the root has no parent; the iterator drives on to "_sanitizeAttributes", which early-returns on clobbered nodes — and the event handler attribute is never inspected. The sanitized return is the same root, with the handler live. This affects current "main" at "89da34e" (the just-landed DOM-clobbering hardening fix at "89da34e" addressed "_sanitizeAttachedShadowRoots" walk traversal, not the main "_sanitizeElements" / "_sanitizeAttributes" pipeline against the iterator-root node). Affected - DOMPurify ≤ 3.4.5, including "main" at "89da34e03ec17868e561f87f3747a9371b61a9e7" - Any caller that does "DOMPurify.sanitize(node, { IN_PLACE: true })" where "node" is built from untrusted HTML (e.g., parsed via "createElement('template').innerHTML = dirty" then "template.content.firstElementChild" handed in) Not affected: - String-input "DOMPurify.sanitize(dirtyString)" — the library builds the DOM itself inside "_initDocument", the root is the cleanly-created document body, and clobber-named children of the body cannot shadow "body" named properties (HTMLBodyElement does not carry "[LegacyOverrideBuiltIns]") - IN_PLACE where the root is not an HTMLFormElement - IN_PLACE where the attacker cannot place a clobber-named child inside the root Vulnerability details Code paths [A] — "_forceRemove" at "src/purify.ts:930-939": const forceRemove = function (node: Node): void { arrayPush(DOMPurify.removed, { element: node }); try { // eslint-disable-next-line unicorn/prefer-dom-node-remove getParentNode(node).removeChild(node); // [A1] throws when getParentNode returns null } catch () { remove(node); // [A2] WebIDL Node.remove() — spec-defined no-op } // when the node has no parent }; When the iterator-root has no parent (the standard IN_PLACE case where the caller hands in a detached node), "getParentNode(node)" returns "null", "null.removeChild(node)" throws, the catch falls to "remove(node)" — which per WebIDL is "Element.prototype.remove.call(node)", and per spec does nothing if the node has no parent. Nothing about "_forceRemove"'s contract acknowledges this — the function appears to its callers as "the node is gone now," but the node is still in place. [B] — "_sanitizeAttributes" at "src/purify.ts:1490-1492": const _sanitizeAttributes = function (currentNode: Element): void { _executeHooks(hooks.beforeSanitizeAttributes, currentNode, null); const { attributes } = currentNode; /* Check if we have attributes; if not we might have a text node / if (!attributes || _isClobbered(currentNode)) { return; // [B] silently skips ALL attribute checks } // for clobbered nodes ... }; The skip at "[B]" is deliberate — the intent is to avoid touching nodes the library has already decided to discard. The invariant the comment implies is "if "_isClobbered", then "_sanitizeElements" already removed this node, so we will never reach "_sanitizeAttributes" on it." That invariant holds for every non-root node (their "_forceRemove" succeeds in detaching them), but fails for the iterator root in IN_PLACE mode. The mismatch is between [A] and [B]: [A] assumes "removal" means the node will not be observed again, and [B] assumes any clobbered node it sees has already been removed. Neither holds for the iterator root. A correct guard would either make "_forceRemove" fail loudly on parent-less nodes (so the caller can bail out of IN_PLACE entirely) or have "_sanitizeAttributes" strip attributes from clobbered roots before returning. Iterator call site "src/purify.ts:1850-1864" ignores the boolean return value of "_sanitizeElements": const nodeIterator = _createNodeIterator(IN_PLACE ? dirty : body); while ((currentNode = nodeIterator.nextNode())) { _sanitizeElements(currentNode); // returns "true" if killed — IGNORED _sanitizeAttributes(currentNode); // runs unconditionally; relies on [B]'s skip ... } If the return value were checked and "_sanitizeAttributes" skipped when the node was "killed," the bug would not exist as a discrete issue — but currently "_sanitizeAttributes" is the only line of defense for a node that "_sanitizeElements" could not actually detach. Why the clobber works In Chromium/WebKit/Firefox, "HTMLFormElement" carries the WebIDL "[LegacyOverrideBuiltIns]" extended attribute on its named-property getter. A descendant element with "name="X"" (or "id="X"", for radio-button-like names) shadows the matching property on the form, including properties inherited from "Element", "Node", and "EventTarget" prototypes. This is the same primitive the just-landed "89da34e" fix addresses for shadow-root traversal, but "_isClobbered"'s typeof checks (and the bypass-by-detection-failure path here) are independent of that fix. Verified clobber targets (each name= value independently triggers "_isClobbered"): | "name=" value | property "_isClobbered" checks | typeof on clobbered form | |---|---|---| | "nodeName" | "typeof element.nodeName !== 'string'" | object (an "") | | "setAttribute" | "typeof element.setAttribute !== 'function'" | object (not callable) — but ""/""/"<iframe>" ARE callable; see "Note on callable elements" below | | "namespaceURI" | "typeof element.namespaceURI !== 'string'" | object | | "insertBefore" | "typeof element.insertBefore !== 'function'" | object | | "hasChildNodes" | "typeof element.hasChildNodes !== 'function'" | object | | "childNodes" | "!(element.childNodes && typeof element.childNodes.length === 'number')" | object — "" has no ".length" | | "attributes" | "!(element.attributes instanceof NamedNodeMap)" | object (an "" is not a NamedNodeMap) | | "textContent" | "typeof element.textContent !== 'string'" | object | | "removeChild" | "typeof element.removeChild !== 'function'" | object (non-callable) | | "removeAttribute" | "typeof element.removeAttribute !== 'function'" | object (non-callable) | Any single one of the ten property names in "_isClobbered"'s checklist is sufficient as the bypass trigger. Proof of concept (1) Minimal — runnable in a single browser context <!doctype html> <script src="dist/purify.js"></script> <script> const root = document.createElement('form'); root.setAttribute('onmouseover', 'window.__rooted = 1'); const clobber = document.createElement('input'); clobber.setAttribute('name', 'nodeName'); root.appendChild(clobber); // typeof root.nodeName === 'object' (an element), not 'string'. // _isClobbered fires; _forceRemove(root) becomes a no-op because root.parentNode === null. DOMPurify.sanitize(root, { IN_PLACE: true }); console.log('output:', root.outerHTML); // // ^^^^^^^^^^^^^^^^^^ event handler survived ^^^^^^^^^^^^^^^^^^ document.body.appendChild(root); root.dispatchEvent(new MouseEvent('mouseover', { bubbles: true })); console.log('handler fired:', window.__rooted === 1); // true </script> (2) End-to-end — Playwright against "main" HEAD const { chromium } = require('playwright'); const path = require('path'); (async () => { const browser = await chromium.launch(); const page = await browser.newPage(); await page.setContent('<!doctype html>'); await page.addScriptTag({ path: path.resolve('dist/purify.js') }); const result = await page.evaluate(() => { const root = document.createElement('form'); root.setAttribute('onmouseover', 'window.__rooted = 1'); const clobber = document.createElement('input'); clobber.setAttribute('name', 'nodeName'); root.appendChild(clobber); DOMPurify.sanitize(root, { IN_PLACE: true }); document.body.appendChild(root); window.__rooted = 0; root.dispatchEvent(new MouseEvent('mouseover', { bubbles: true })); return { version: DOMPurify.version, output: root.outerHTML, handlerFired: window.__rooted === 1, }; }); console.log(result); await browser.close(); })(); Observed (Chromium 148.0.7778.96, DOMPurify 3.4.5, HEAD "89da34e"): { version: '3.4.5', output: '', handlerFired: true } (3) Variant matrix — six distinct clobber-target properties Every property name in "_isClobbered"'s typeof checklist works as the bypass trigger: [BYPASS] name="nodeName" → [BYPASS] name="setAttribute" → [BYPASS] name="namespaceURI" → [BYPASS] name="insertBefore" → [BYPASS] name="hasChildNodes" → [BYPASS] name="childNodes" → This makes the fix less of a one-line patch — every property "_isClobbered" checks for the typeof-spoofing pattern needs to be considered. Impact Direct Two distinct impact paths from the same root-attribute-survival primitive: (a) XSS via event-handler attribute on the surviving root. Any consumer that uses "DOMPurify.sanitize(node, { IN_PLACE: true })" where "node" originated from untrusted HTML and is re-inserted into the live document is vulnerable to XSS. The typical pattern is: const t = document.createElement('template'); t.innerHTML = untrustedHtml; DOMPurify.sanitize(t.content.firstElementChild, { IN_PLACE: true }); container.appendChild(t.content.firstElementChild); If "untrustedHtml" is "…", the resulting node has the "onmouseover" attribute intact when re-inserted into the live document. (b) Every attribute-level defense is bypassed on the surviving root, not just event handlers. The "_sanitizeAttributes" early-return at ":1490" skips the entire attribute walk for clobbered nodes, so the root preserves attributes that the attribute walk would otherwise sanitize. Verified additional attributes that survive: - "action="javascript:..."" and "formaction="javascript:..."" — URI validation at ":1413" never runs. A user click on a submit button inside the sanitized form navigates to the "javascript:" URL, executing the handler. Adds a click-triggered XSS path on top of the mouseover/focus event-handler attributes already documented. - "id=""" — the DOM-clobbering guard at ":1352-1359" ("SANITIZE_DOM && (lcName === 'id' || lcName === 'name') && (value in document || value in formElement)") lives inside "_sanitizeAttributes" and is skipped. An attacker can therefore land "id="cookie"", "id="body"", "id="head"", "id="firstChild"", etc. on the surviving form root and use it as a DOM-clobbering primitive against any consumer code that does "document.cookie", "document.body", etc. - "target="_top"", "autofocus", "formenctype", "formmethod" — all survive untouched. - Custom event handlers DOMPurify wouldn't have explicit list entries for (e.g., newly-spec'd "oncontentvisibilityautostatechange") survive on the clobbered root via the same skip; the per-name allow-list at ":1361-1364" never runs. Verified — full attribute set survives on a single payload (PoC): const root = document.createElement('form'); root.setAttribute('action', 'javascript:alert(1)'); root.setAttribute('target', '_top'); root.setAttribute('onclick', 'alert(2)'); root.setAttribute('onmouseover', 'alert(3)'); root.setAttribute('autofocus', ''); root.setAttribute('formaction', 'javascript:alert(4)'); root.setAttribute('id', 'cookie'); // DOM-clobbering primitive root.innerHTML += ''; DOMPurify.sanitize(root, { IN_PLACE: true }); console.log(root.outerHTML); // <form action="javascript:alert(1)" target="_top" onclick="alert(2)" // onmouseover="alert(3)" autofocus="" formaction="javascript:alert(4)" // id="cookie"> (c) Defense-in-depth re-sanitization on the same node is INEFFECTIVE — the clobber is sticky. Chromium's "HTMLFormElement" named-property cache appears to retain the named child reference even after the child's "name" attribute is removed during the sanitization pass. Empirically verified — after the first sanitize pass, the input's "name="nodeName"" attribute is correctly stripped (the output shows "" with no attributes), yet "typeof form.nodeName === 'object'" is still true and the input element is still returned. Calling "DOMPurify.sanitize(sameNode, { IN_PLACE: true })" a second time hits the same "_isClobbered" → "_forceRemove" → "_sanitizeAttributes" early-return path. The only effective recovery is serialize-then-reparse: const root = parseAttackerHtml(); // form with input name="nodeName" child DOMPurify.sanitize(root, { IN_PLACE: true }); // bypass: attrs survive DOMPurify.sanitize(root, { IN_PLACE: true }); // STILL bypassed: attrs survive const recovered = (() => { const t = document.createElement('template'); t.innerHTML = root.outerHTML; // forces a fresh parse const r = t.content.firstElementChild; DOMPurify.sanitize(r, { IN_PLACE: true }); return r; })(); // recovered.outerHTML === '' ← finally clean A "belt-and-suspenders" caller that re-runs DOMPurify on its own output is therefore not protected against this primitive on Chromium; the obvious mitigation pattern fails silently. Any user-side workaround needs to route through a string round-trip. (d) SAFE_FOR_TEMPLATES bypass for the root's attributes. When the caller sets "SAFE_FOR_TEMPLATES: true" to defend a downstream template engine (Vue, Angular, Liquid, Handlebars, …) from receiving "{{…}}" / "<%…%>" / "${…}" syntax through DOMPurify's output, attribute-level template-syntax stripping runs in the same "_sanitizeAttributes" pass that early-returns on clobbered roots (":1572-1576"). The root's attributes therefore retain raw template syntax that the downstream engine then evaluates. Verified — same PoC structure, with "SAFE_FOR_TEMPLATES: true": const root = document.createElement('form'); root.setAttribute('title', '{{evil}}'); root.setAttribute('onmouseover', 'window.__x=1'); const c = document.createElement('input'); c.setAttribute('name', 'nodeName'); root.appendChild(c); DOMPurify.sanitize(root, { IN_PLACE: true, SAFE_FOR_TEMPLATES: true }); console.log(root.outerHTML); // // ^^^^^^^^^^^^^^^^ template syntax survives This compounds with (a): a single payload exfiltrates via XSS (immediate) and via SSTI to downstream renderers (delayed). (Text-node content inside the form is still scrubbed correctly — "_scrubTemplateExpressions" at ":1868-1870" walks text/comment/CDATA/PI nodes independently and reaches them via the iterator. Only attribute values on the clobbered root escape.) Indirect / second-order - DOM-based template systems / editors that wrap DOMPurify with an IN_PLACE call for parsed user content (CMSes, comment widgets, WYSIWYG editors persisting structured HTML). - Email/HTML preview libraries that pre-parse received HTML before sanitization for performance reasons. - Frameworks that hand DOMPurify a node tree rather than a string — including, indirectly, any code path that does "el.innerHTML = …; DOMPurify.sanitize(el, { IN_PLACE: true })". The outer "el" is fine (it's not the form), but if the first child of "el" is taken as the sanitization root in a different code path, the bypass triggers. Why current "main" is also vulnerable Commit "89da34e" ("fix: fixed a possible DOM clobbering with IN_PLACE and shadow DOM") hardens "_sanitizeAttachedShadowRoots" via three new cached prototype getters ("getShadowRoot", "getNodeName", "getNodeType") and an "_isClobbered" extension that checks "element.childNodes.length". The fix is correct for its scope — shadow-root traversal — but does not change "_forceRemove"'s parent-less-node behavior or "_sanitizeAttributes"'s clobber-skip early-return. The bypass demonstrated here is in the IN_PLACE main pipeline, not the shadow-root walk, and the verification PoC above runs against HEAD "89da34e" and still succeeds. Suggested fix Two minimal-risk options: 1. Make "forceRemove" honest about failure: return whether the node was actually detached, and have the iterator call site honor that. const forceRemove = function (node: Node): boolean { arrayPush(DOMPurify.removed, { element: node }); try { getParentNode(node).removeChild(node); return true; } catch () { try { remove(node); } catch () {} return node.parentNode === null && / but still attached to itself */ false; } }; Then at ":1855", if "_sanitizeElements" returns true AND IN_PLACE, force-strip all attributes of the root before returning the dirty tree. (This is what the user expects — sanitization either succeeds or refuses to return a "sanitized" handle to an unsanitized tree.) 2. Strip attributes inside "_sanitizeAttributes" for clobbered roots: when "_isClobbered(currentNode)" is true at ":1490", instead of early-returning, iterate "currentNode.attributes" (using the cached "getAttributes" if you add one) and remove each via "removeAttribute". This preserves the existing semantics for non-root clobbered nodes (their attributes-of-a-removed-node will be GC'd anyway) and removes the attack surface for root. 3. Refuse IN_PLACE on parent-less clobbered roots: at the top of the iterator, check that the root either has a parent OR is not "_isClobbered". If both fail, throw. This is the most defensive option but breaks any existing caller that hands in a clobbered detached root expecting "sanitized = empty/safe." Note on callable elements In Chromium and WebKit, "HTMLEmbedElement", "HTMLAppletElement", "HTMLIFrameElement", and "HTMLScriptElement" have "typeof === 'function'" because they expose plugin/iframe "[[Call]]" traps at the WebIDL level. A "name="setAttribute"" child of one of these tags spoofs the "setAttribute typeof === 'function'" check — but only matters for the attribute re-set path at ":1619", not the bypass demonstrated here (which uses "nodeName" and friends). The callable-element vector is worth checking separately as a potential "SAFE_FOR_TEMPLATES"-bypass primitive; the present report does not depend on it.
Publish Date: 2026-06-15
URL: CVE-2026-49459
CVSS 3 Score Details (6.1)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: Required
- Scope: Changed
- Impact Metrics:
- Confidentiality Impact: Low
- Integrity Impact: Low
- Availability Impact: None
For more information on CVSS3 Scores, click here.
Suggested Fix
Type: Upgrade version
Origin: GHSA-r47g-fvhr-h676
Release Date: 2026-06-15
Fix Resolution: https://github.com/cure53/DOMPurify.git - 3.4.6,dompurify - 3.4.6
⛑️Automatic Remediation will be attempted for this issue.
Path to dependency file: /tutorials/vonage_video_react_app-feature-config/project/package.json
Path to vulnerable library: /tutorials/vonage_video_react_app-feature-config/project/package.json
Found in HEAD commit: f400f39c07df86338418f7902a27a7c22c1442b4
Vulnerabilities
*For some transitive vulnerabilities, there is no version of direct dependency with a fix. Check the "Details" section below to see if there is a version of transitive dependency where vulnerability is fixed.
**In some cases, Remediation PR cannot be created automatically for a vulnerability despite the availability of remediation
Details
Vulnerable Library - uuid-11.1.0.tgz
RFC9562 UUIDs
Library home page: https://registry.npmjs.org/uuid/-/uuid-11.1.0.tgz
Path to dependency file: /tutorials/vonage_video_react_app-feature-config/project/package.json
Path to vulnerable library: /tutorials/vonage_video_react_app-feature-config/project/package.json
Dependency Hierarchy:
Found in HEAD commit: f400f39c07df86338418f7902a27a7c22c1442b4
Found in base branch: main
Vulnerability Details
uuid is for the creation of RFC9562 (formerly RFC4122) UUIDs. Prior to 14.0.0, v3, v5, and v6 accept external output buffers but do not reject out-of-range writes (small buf or large offset). This allows silent partial writes into caller-provided buffers. This vulnerability is fixed in 14.0.0.
Publish Date: 2026-04-24
URL: CVE-2026-41907
CVSS 3 Score Details (9.8)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: High
- Integrity Impact: High
- Availability Impact: High
For more information on CVSS3 Scores, click here.Suggested Fix
Type: Upgrade version
Origin: GHSA-w5hq-g745-h8pq
Release Date: 2026-04-24
Fix Resolution: https://github.com/uuidjs/uuid.git - v11.1.1,https://github.com/uuidjs/uuid.git - v12.0.1,https://github.com/uuidjs/uuid.git - v13.0.1
Vulnerable Library - xmldom-0.8.11.tgz
A pure JavaScript W3C standard-based (XML DOM Level 2 Core) DOMParser and XMLSerializer module.
Library home page: https://registry.npmjs.org/@xmldom/xmldom/-/xmldom-0.8.11.tgz
Path to dependency file: /tutorials/vonage_video_react_app-feature-config/project/package.json
Path to vulnerable library: /tutorials/vonage_video_react_app-feature-config/project/package.json
Dependency Hierarchy:
Found in HEAD commit: f400f39c07df86338418f7902a27a7c22c1442b4
Found in base branch: main
Vulnerability Details
xmldom is a pure JavaScript W3C standard-based (XML DOM Level 2 Core) "DOMParser" and "XMLSerializer" module. In @xmldom/xmldom prior to versions 0.9.10 and 0.8.13 and xmldom version 0.6.0 and prior, the package allows attacker-controlled processing instruction data to be serialized into XML without validating or neutralizing the PI-closing sequence ?>. As a result, an attacker can terminate the processing instruction early and inject arbitrary XML nodes into the serialized output. This issue has been patched in versions @xmldom/xmldom versions 0.9.10 and 0.8.13.
Publish Date: 2026-05-07
URL: CVE-2026-41675
CVSS 3 Score Details (7.5)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: High
- Availability Impact: None
For more information on CVSS3 Scores, click here.Suggested Fix
Type: Upgrade version
Release Date: 2026-04-22
Fix Resolution: https://github.com/xmldom/xmldom.git - 0.8.13,https://github.com/xmldom/xmldom.git - 0.9.10
Vulnerable Library - xmldom-0.8.11.tgz
A pure JavaScript W3C standard-based (XML DOM Level 2 Core) DOMParser and XMLSerializer module.
Library home page: https://registry.npmjs.org/@xmldom/xmldom/-/xmldom-0.8.11.tgz
Path to dependency file: /tutorials/vonage_video_react_app-feature-config/project/package.json
Path to vulnerable library: /tutorials/vonage_video_react_app-feature-config/project/package.json
Dependency Hierarchy:
Found in HEAD commit: f400f39c07df86338418f7902a27a7c22c1442b4
Found in base branch: main
Vulnerability Details
xmldom is a pure JavaScript W3C standard-based (XML DOM Level 2 Core) "DOMParser" and "XMLSerializer" module. In @xmldom/xmldom prior to versions 0.9.10 and 0.8.13 and xmldom version 0.6.0 and prior, the package serializes DocumentType node fields (internalSubset, publicId, systemId) verbatim without any escaping or validation. When these fields are set programmatically to attacker-controlled strings, XMLSerializer.serializeToString can produce output where the DOCTYPE declaration is terminated early and arbitrary markup appears outside it. This issue has been patched in versions @xmldom/xmldom versions 0.9.10 and 0.8.13.
Publish Date: 2026-05-07
URL: CVE-2026-41674
CVSS 3 Score Details (7.5)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: High
- Availability Impact: None
For more information on CVSS3 Scores, click here.Suggested Fix
Type: Upgrade version
Release Date: 2026-04-22
Fix Resolution: https://github.com/xmldom/xmldom.git - 0.8.13,https://github.com/xmldom/xmldom.git - 0.9.10
Vulnerable Library - xmldom-0.8.11.tgz
A pure JavaScript W3C standard-based (XML DOM Level 2 Core) DOMParser and XMLSerializer module.
Library home page: https://registry.npmjs.org/@xmldom/xmldom/-/xmldom-0.8.11.tgz
Path to dependency file: /tutorials/vonage_video_react_app-feature-config/project/package.json
Path to vulnerable library: /tutorials/vonage_video_react_app-feature-config/project/package.json
Dependency Hierarchy:
Found in HEAD commit: f400f39c07df86338418f7902a27a7c22c1442b4
Found in base branch: main
Vulnerability Details
xmldom is a pure JavaScript W3C standard-based (XML DOM Level 2 Core) "DOMParser" and "XMLSerializer" module. In @xmldom/xmldom prior to versions 0.9.10 and 0.8.13 and xmldom version 0.6.0 and prior, seven recursive traversals in lib/dom.js operate without a depth limit. A sufficiently deeply nested DOM tree causes a RangeError: Maximum call stack size exceeded, crashing the application. This issue has been patched in versions @xmldom/xmldom versions 0.9.10 and 0.8.13.
Publish Date: 2026-05-07
URL: CVE-2026-41673
CVSS 3 Score Details (7.5)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: None
- Availability Impact: High
For more information on CVSS3 Scores, click here.Suggested Fix
Type: Upgrade version
Release Date: 2026-04-22
Fix Resolution: https://github.com/xmldom/xmldom.git - 0.8.13,https://github.com/xmldom/xmldom.git - 0.9.10
Vulnerable Library - xmldom-0.8.11.tgz
A pure JavaScript W3C standard-based (XML DOM Level 2 Core) DOMParser and XMLSerializer module.
Library home page: https://registry.npmjs.org/@xmldom/xmldom/-/xmldom-0.8.11.tgz
Path to dependency file: /tutorials/vonage_video_react_app-feature-config/project/package.json
Path to vulnerable library: /tutorials/vonage_video_react_app-feature-config/project/package.json
Dependency Hierarchy:
Found in HEAD commit: f400f39c07df86338418f7902a27a7c22c1442b4
Found in base branch: main
Vulnerability Details
xmldom is a pure JavaScript W3C standard-based (XML DOM Level 2 Core) "DOMParser" and "XMLSerializer" module. In @xmldom/xmldom prior to versions 0.9.10 and 0.8.13 and xmldom version 0.6.0 and prior, the package allows attacker-controlled comment content to be serialized into XML without validating or neutralizing comment-breaking sequences. As a result, an attacker can terminate the comment early and inject arbitrary XML nodes into the serialized output. This issue has been patched in versions @xmldom/xmldom versions 0.9.10 and 0.8.13.
Publish Date: 2026-05-07
URL: CVE-2026-41672
CVSS 3 Score Details (7.5)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: High
- Availability Impact: None
For more information on CVSS3 Scores, click here.Suggested Fix
Type: Upgrade version
Release Date: 2026-04-22
Fix Resolution: https://github.com/xmldom/xmldom.git - 0.8.13,https://github.com/xmldom/xmldom.git - 0.9.10
Vulnerable Library - xmldom-0.8.11.tgz
A pure JavaScript W3C standard-based (XML DOM Level 2 Core) DOMParser and XMLSerializer module.
Library home page: https://registry.npmjs.org/@xmldom/xmldom/-/xmldom-0.8.11.tgz
Path to dependency file: /tutorials/vonage_video_react_app-feature-config/project/package.json
Path to vulnerable library: /tutorials/vonage_video_react_app-feature-config/project/package.json
Dependency Hierarchy:
Found in HEAD commit: f400f39c07df86338418f7902a27a7c22c1442b4
Found in base branch: main
Vulnerability Details
xmldom is a pure JavaScript W3C standard-based (XML DOM Level 2 Core) "DOMParser" and "XMLSerializer" module. In xmldom versions 0.6.0 and prior and @xmldom/xmldom prior to versions 0.8.12 and 0.9.9, xmldom/xmldom allows attacker-controlled strings containing the CDATA terminator ]]> to be inserted into a CDATASection node. During serialization, XMLSerializer emitted the CDATA content verbatim without rejecting or safely splitting the terminator. As a result, data intended to remain text-only became active XML markup in the serialized output, enabling XML structure injection and downstream business-logic manipulation. This issue has been patched in xmldom version 0.6.0 and @xmldom/xmldom versions 0.8.12 and 0.9.9.
Publish Date: 2026-04-02
URL: CVE-2026-34601
CVSS 3 Score Details (7.5)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: High
- Availability Impact: None
For more information on CVSS3 Scores, click here.Suggested Fix
Type: Upgrade version
Release Date: 2026-04-01
Fix Resolution: https://github.com/xmldom/xmldom.git - 0.9.9
Vulnerable Library - dompurify-3.3.3.tgz
DOMPurify is a DOM-only, super-fast, uber-tolerant XSS sanitizer for HTML, MathML and SVG. It's written in JavaScript and works in all modern browsers (Safari, Opera (15+), Internet Explorer (10+), Firefox and Chrome - as well as almost anything else usin
Library home page: https://registry.npmjs.org/dompurify/-/dompurify-3.3.3.tgz
Path to dependency file: /tutorials/vonage_video_react_app-feature-config/project/package.json
Path to vulnerable library: /tutorials/vonage_video_react_app-feature-config/project/package.json
Dependency Hierarchy:
Found in HEAD commit: f400f39c07df86338418f7902a27a7c22c1442b4
Found in base branch: main
Vulnerability 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.
Mend Note: The description of this vulnerability differs from MITRE.
Publish Date: 2026-04-23
URL: CVE-2026-41238
CVSS 3 Score Details (6.9)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: High
- Privileges Required: None
- User Interaction: Required
- Scope: Changed
- Impact Metrics:
- Confidentiality Impact: High
- Integrity Impact: Low
- Availability Impact: None
For more information on CVSS3 Scores, click here.Suggested Fix
Type: Upgrade version
Origin: GHSA-v9jr-rg53-9pgp
Release Date: 2026-04-22
Fix Resolution (dompurify): 3.4.0
Direct dependency fix Resolution (@vonage/vivid): 5.16.0
⛑️ Automatic Remediation will be attempted for this issue.
Vulnerable Library - dompurify-3.3.3.tgz
DOMPurify is a DOM-only, super-fast, uber-tolerant XSS sanitizer for HTML, MathML and SVG. It's written in JavaScript and works in all modern browsers (Safari, Opera (15+), Internet Explorer (10+), Firefox and Chrome - as well as almost anything else usin
Library home page: https://registry.npmjs.org/dompurify/-/dompurify-3.3.3.tgz
Path to dependency file: /tutorials/vonage_video_react_app-feature-config/project/package.json
Path to vulnerable library: /tutorials/vonage_video_react_app-feature-config/project/package.json
Dependency Hierarchy:
Found in HEAD commit: f400f39c07df86338418f7902a27a7c22c1442b4
Found in base branch: main
Vulnerability Details
Summary | Field | Value | |:------|:------| | Severity | Medium | | Affected | DOMPurify "main" at ""883ac15"" (https://github.com/cure53/DOMPurify/tree/883ac15d47f907cb1a3b5a152fe90c4d8c10f9e6), introduced in v1.0.10 (""7fc196db"" (cure53/DOMPurify@7fc196d)) | "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: 1. Per-node — each text node is checked during the tree walk (""purify.ts:1179-1191"" (https://github.com/cure53/DOMPurify/blob/883ac15d47f907cb1a3b5a152fe90c4d8c10f9e6/src/purify.ts#L1179-L1191)): // pass #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; } 2. Final string scrub — after serialization, the full HTML string is scrubbed again (""purify.ts:1679-1683"" (https://github.com/cure53/DOMPurify/blob/883ac15d47f907cb1a3b5a152fe90c4d8c10f9e6/src/purify.ts#L1679-L1683)). 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"" (https://github.com/cure53/DOMPurify/blob/883ac15d47f907cb1a3b5a152fe90c4d8c10f9e6/src/purify.ts#L1637-L1661)): // purify.ts (simplified) if (RETURN_DOM) { // ... build returnNode ... return returnNode; // <-- exits here, pass #2 never runs } // pass #2: only reached by string-mode callers if (SAFE_FOR_TEMPLATES) { serializedHTML = serializedHTML.replace(MUSTACHE_EXPR, ' '); } return serializedHTML; The payload "{{constructor.constructor('alert(1)')()}}" exploits this: 3. Parser creates: "TEXT("{")" → "" → "TEXT("{payload}")" → "" → "TEXT("}")" — no single node contains "{{", so pass #1 misses it 4. "" is not allowed, so DOMPurify removes it but keeps surrounding text 5. The three text nodes are now adjacent — ".outerHTML" reads them as "{{payload}}", which Vue 2 compiles and executes
Mend Note: The description of this vulnerability differs from MITRE.
Publish Date: 2026-04-23
URL: CVE-2026-41239
CVSS 3 Score Details (6.8)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: High
- Privileges Required: None
- User Interaction: Required
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: High
- Integrity Impact: High
- Availability Impact: None
For more information on CVSS3 Scores, click here.Suggested Fix
Type: Upgrade version
Origin: GHSA-crv5-9vww-q3g8
Release Date: 2026-04-22
Fix Resolution (dompurify): 3.4.0
Direct dependency fix Resolution (@vonage/vivid): 5.16.0
⛑️ Automatic Remediation will be attempted for this issue.
Vulnerable Library - dompurify-3.3.3.tgz
DOMPurify is a DOM-only, super-fast, uber-tolerant XSS sanitizer for HTML, MathML and SVG. It's written in JavaScript and works in all modern browsers (Safari, Opera (15+), Internet Explorer (10+), Firefox and Chrome - as well as almost anything else usin
Library home page: https://registry.npmjs.org/dompurify/-/dompurify-3.3.3.tgz
Path to dependency file: /tutorials/vonage_video_react_app-feature-config/project/package.json
Path to vulnerable library: /tutorials/vonage_video_react_app-feature-config/project/package.json
Dependency Hierarchy:
Found in HEAD commit: f400f39c07df86338418f7902a27a7c22c1442b4
Found in base branch: main
Vulnerability Details
There is an inconsistency between FORBID_TAGS and FORBID_ATTR handling when function-based ADD_TAGS is used. Commit "c361baa" (cure53/DOMPurify@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.
Mend Note: The description of this vulnerability differs from MITRE.
Publish Date: 2026-04-23
URL: CVE-2026-41240
CVSS 3 Score Details (6.5)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: Required
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: High
- Availability Impact: None
For more information on CVSS3 Scores, click here.Suggested Fix
Type: Upgrade version
Origin: GHSA-h7mw-gpvr-xq4m
Release Date: 2026-04-23
Fix Resolution (dompurify): 3.4.0
Direct dependency fix Resolution (@vonage/vivid): 5.16.0
⛑️ Automatic Remediation will be attempted for this issue.
Vulnerable Library - dompurify-3.3.3.tgz
DOMPurify is a DOM-only, super-fast, uber-tolerant XSS sanitizer for HTML, MathML and SVG. It's written in JavaScript and works in all modern browsers (Safari, Opera (15+), Internet Explorer (10+), Firefox and Chrome - as well as almost anything else usin
Library home page: https://registry.npmjs.org/dompurify/-/dompurify-3.3.3.tgz
Path to dependency file: /tutorials/vonage_video_react_app-feature-config/project/package.json
Path to vulnerable library: /tutorials/vonage_video_react_app-feature-config/project/package.json
Dependency Hierarchy:
Found in HEAD commit: f400f39c07df86338418f7902a27a7c22c1442b4
Found in base branch: main
Vulnerability Details
If the HTML you give it contains a element, and inside that template there's an element with a shadow DOM attached to it, DOMPurify quietly skips over the shadow contents. Whatever the attacker put in there - an image with an onerror handler, a link with a javascript: URL, even a full script - survives untouched. The moment the application uses that template the way templates are meant to be used (cloning it and inserting the result into the page), the malicious payload comes along and runs as if it had never been sanitized. From there an attacker gets everything XSS normally gets them: session cookies, stored tokens, the ability to act as the user, and the ability to leave persistent payloads behind for the next person who visits. "advisory.pdf" (https://github.com/user-attachments/files/28275600/advisory.pdf) "poc.html" (https://github.com/user-attachments/files/28275708/poc.html)
Publish Date: 2026-06-15
URL: CVE-2026-49978
CVSS 3 Score Details (6.1)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: Required
- Scope: Changed
- Impact Metrics:
- Confidentiality Impact: Low
- Integrity Impact: Low
- Availability Impact: None
For more information on CVSS3 Scores, click here.Suggested Fix
Type: Upgrade version
Release Date: 2026-06-15
Fix Resolution: https://github.com/cure53/DOMPurify.git - 3.4.7
Vulnerable Library - dompurify-3.3.3.tgz
DOMPurify is a DOM-only, super-fast, uber-tolerant XSS sanitizer for HTML, MathML and SVG. It's written in JavaScript and works in all modern browsers (Safari, Opera (15+), Internet Explorer (10+), Firefox and Chrome - as well as almost anything else usin
Library home page: https://registry.npmjs.org/dompurify/-/dompurify-3.3.3.tgz
Path to dependency file: /tutorials/vonage_video_react_app-feature-config/project/package.json
Path to vulnerable library: /tutorials/vonage_video_react_app-feature-config/project/package.json
Dependency Hierarchy:
Found in HEAD commit: f400f39c07df86338418f7902a27a7c22c1442b4
Found in base branch: main
Vulnerability Details
IN_PLACE mode preserves attributes of a clobbered root element, allowing XSS via attacker-controlled root DOM CWE: CWE-79 (XSS — Improper Neutralization of Input During Web Page Generation) via CWE-693 (Protection Mechanism Failure — silent no-op when "_forceRemove" is called on a parent-less node) Summary When "DOMPurify.sanitize(root, { IN_PLACE: true })" is called and "root" is a "
" whose own attributes carry an event handler ("onmouseover", "onfocus", "onclick", etc.), a single descendant element with a "name=" attribute matching any of the property names "_isClobbered" checks ("nodeName", "setAttribute", "namespaceURI", "insertBefore", "hasChildNodes", "childNodes") is sufficient to bypass attribute sanitization on the root. "_forceRemove" silently no-ops because the root has no parent; the iterator drives on to "_sanitizeAttributes", which early-returns on clobbered nodes — and the event handler attribute is never inspected. The sanitized return is the same root, with the handler live. This affects current "main" at "89da34e" (the just-landed DOM-clobbering hardening fix at "89da34e" addressed "_sanitizeAttachedShadowRoots" walk traversal, not the main "_sanitizeElements" / "_sanitizeAttributes" pipeline against the iterator-root node). Affected - DOMPurify ≤ 3.4.5, including "main" at "89da34e03ec17868e561f87f3747a9371b61a9e7" - Any caller that does "DOMPurify.sanitize(node, { IN_PLACE: true })" where "node" is built from untrusted HTML (e.g., parsed via "createElement('template').innerHTML = dirty" then "template.content.firstElementChild" handed in) Not affected: - String-input "DOMPurify.sanitize(dirtyString)" — the library builds the DOM itself inside "_initDocument", the root is the cleanly-created document body, and clobber-named children of the body cannot shadow "body" named properties (HTMLBodyElement does not carry "[LegacyOverrideBuiltIns]") - IN_PLACE where the root is not an HTMLFormElement - IN_PLACE where the attacker cannot place a clobber-named child inside the root Vulnerability details Code paths [A] — "_forceRemove" at "src/purify.ts:930-939": const forceRemove = function (node: Node): void { arrayPush(DOMPurify.removed, { element: node }); try { // eslint-disable-next-line unicorn/prefer-dom-node-remove getParentNode(node).removeChild(node); // [A1] throws when getParentNode returns null } catch () { remove(node); // [A2] WebIDL Node.remove() — spec-defined no-op } // when the node has no parent }; When the iterator-root has no parent (the standard IN_PLACE case where the caller hands in a detached node), "getParentNode(node)" returns "null", "null.removeChild(node)" throws, the catch falls to "remove(node)" — which per WebIDL is "Element.prototype.remove.call(node)", and per spec does nothing if the node has no parent. Nothing about "_forceRemove"'s contract acknowledges this — the function appears to its callers as "the node is gone now," but the node is still in place. [B] — "_sanitizeAttributes" at "src/purify.ts:1490-1492": const _sanitizeAttributes = function (currentNode: Element): void { _executeHooks(hooks.beforeSanitizeAttributes, currentNode, null); const { attributes } = currentNode; /* Check if we have attributes; if not we might have a text node / if (!attributes || _isClobbered(currentNode)) { return; // [B] silently skips ALL attribute checks } // for clobbered nodes ... }; The skip at "[B]" is deliberate — the intent is to avoid touching nodes the library has already decided to discard. The invariant the comment implies is "if "_isClobbered", then "_sanitizeElements" already removed this node, so we will never reach "_sanitizeAttributes" on it." That invariant holds for every non-root node (their "_forceRemove" succeeds in detaching them), but fails for the iterator root in IN_PLACE mode. The mismatch is between [A] and [B]: [A] assumes "removal" means the node will not be observed again, and [B] assumes any clobbered node it sees has already been removed. Neither holds for the iterator root. A correct guard would either make "_forceRemove" fail loudly on parent-less nodes (so the caller can bail out of IN_PLACE entirely) or have "_sanitizeAttributes" strip attributes from clobbered roots before returning. Iterator call site "src/purify.ts:1850-1864" ignores the boolean return value of "_sanitizeElements": const nodeIterator = _createNodeIterator(IN_PLACE ? dirty : body); while ((currentNode = nodeIterator.nextNode())) { _sanitizeElements(currentNode); // returns "true" if killed — IGNORED _sanitizeAttributes(currentNode); // runs unconditionally; relies on [B]'s skip ... } If the return value were checked and "_sanitizeAttributes" skipped when the node was "killed," the bug would not exist as a discrete issue — but currently "_sanitizeAttributes" is the only line of defense for a node that "_sanitizeElements" could not actually detach. Why the clobber works In Chromium/WebKit/Firefox, "HTMLFormElement" carries the WebIDL "[LegacyOverrideBuiltIns]" extended attribute on its named-property getter. A descendant element with "name="X"" (or "id="X"", for radio-button-like names) shadows the matching property on the form, including properties inherited from "Element", "Node", and "EventTarget" prototypes. This is the same primitive the just-landed "89da34e" fix addresses for shadow-root traversal, but "_isClobbered"'s typeof checks (and the bypass-by-detection-failure path here) are independent of that fix. Verified clobber targets (each name= value independently triggers "_isClobbered"): | "name=" value | property "_isClobbered" checks | typeof on clobbered form | |---|---|---| | "nodeName" | "typeof element.nodeName !== 'string'" | object (an "") | | "setAttribute" | "typeof element.setAttribute !== 'function'" | object (not callable) — but ""/""/"<iframe>" ARE callable; see "Note on callable elements" below | | "namespaceURI" | "typeof element.namespaceURI !== 'string'" | object | | "insertBefore" | "typeof element.insertBefore !== 'function'" | object | | "hasChildNodes" | "typeof element.hasChildNodes !== 'function'" | object | | "childNodes" | "!(element.childNodes && typeof element.childNodes.length === 'number')" | object — "" has no ".length" | | "attributes" | "!(element.attributes instanceof NamedNodeMap)" | object (an "" is not a NamedNodeMap) | | "textContent" | "typeof element.textContent !== 'string'" | object | | "removeChild" | "typeof element.removeChild !== 'function'" | object (non-callable) | | "removeAttribute" | "typeof element.removeAttribute !== 'function'" | object (non-callable) | Any single one of the ten property names in "_isClobbered"'s checklist is sufficient as the bypass trigger. Proof of concept (1) Minimal — runnable in a single browser context <!doctype html> <script src="dist/purify.js"></script> <script> const root = document.createElement('form'); root.setAttribute('onmouseover', 'window.__rooted = 1'); const clobber = document.createElement('input'); clobber.setAttribute('name', 'nodeName'); root.appendChild(clobber); // typeof root.nodeName === 'object' (an element), not 'string'. // _isClobbered fires; _forceRemove(root) becomes a no-op because root.parentNode === null. DOMPurify.sanitize(root, { IN_PLACE: true }); console.log('output:', root.outerHTML); // // ^^^^^^^^^^^^^^^^^^ event handler survived ^^^^^^^^^^^^^^^^^^ document.body.appendChild(root); root.dispatchEvent(new MouseEvent('mouseover', { bubbles: true })); console.log('handler fired:', window.__rooted === 1); // true </script> (2) End-to-end — Playwright against "main" HEAD const { chromium } = require('playwright'); const path = require('path'); (async () => { const browser = await chromium.launch(); const page = await browser.newPage(); await page.setContent('<!doctype html>'); await page.addScriptTag({ path: path.resolve('dist/purify.js') }); const result = await page.evaluate(() => { const root = document.createElement('form'); root.setAttribute('onmouseover', 'window.__rooted = 1'); const clobber = document.createElement('input'); clobber.setAttribute('name', 'nodeName'); root.appendChild(clobber); DOMPurify.sanitize(root, { IN_PLACE: true }); document.body.appendChild(root); window.__rooted = 0; root.dispatchEvent(new MouseEvent('mouseover', { bubbles: true })); return { version: DOMPurify.version, output: root.outerHTML, handlerFired: window.__rooted === 1, }; }); console.log(result); await browser.close(); })(); Observed (Chromium 148.0.7778.96, DOMPurify 3.4.5, HEAD "89da34e"): { version: '3.4.5', output: '', handlerFired: true } (3) Variant matrix — six distinct clobber-target properties Every property name in "_isClobbered"'s typeof checklist works as the bypass trigger: [BYPASS] name="nodeName" → [BYPASS] name="setAttribute" → [BYPASS] name="namespaceURI" → [BYPASS] name="insertBefore" → [BYPASS] name="hasChildNodes" → [BYPASS] name="childNodes" → This makes the fix less of a one-line patch — every property "_isClobbered" checks for the typeof-spoofing pattern needs to be considered. Impact Direct Two distinct impact paths from the same root-attribute-survival primitive: (a) XSS via event-handler attribute on the surviving root. Any consumer that uses "DOMPurify.sanitize(node, { IN_PLACE: true })" where "node" originated from untrusted HTML and is re-inserted into the live document is vulnerable to XSS. The typical pattern is: const t = document.createElement('template'); t.innerHTML = untrustedHtml; DOMPurify.sanitize(t.content.firstElementChild, { IN_PLACE: true }); container.appendChild(t.content.firstElementChild); If "untrustedHtml" is "…", the resulting node has the "onmouseover" attribute intact when re-inserted into the live document. (b) Every attribute-level defense is bypassed on the surviving root, not just event handlers. The "_sanitizeAttributes" early-return at ":1490" skips the entire attribute walk for clobbered nodes, so the root preserves attributes that the attribute walk would otherwise sanitize. Verified additional attributes that survive: - "action="javascript:..."" and "formaction="javascript:..."" — URI validation at ":1413" never runs. A user click on a submit button inside the sanitized form navigates to the "javascript:" URL, executing the handler. Adds a click-triggered XSS path on top of the mouseover/focus event-handler attributes already documented. - "id=""" — the DOM-clobbering guard at ":1352-1359" ("SANITIZE_DOM && (lcName === 'id' || lcName === 'name') && (value in document || value in formElement)") lives inside "_sanitizeAttributes" and is skipped. An attacker can therefore land "id="cookie"", "id="body"", "id="head"", "id="firstChild"", etc. on the surviving form root and use it as a DOM-clobbering primitive against any consumer code that does "document.cookie", "document.body", etc. - "target="_top"", "autofocus", "formenctype", "formmethod" — all survive untouched. - Custom event handlers DOMPurify wouldn't have explicit list entries for (e.g., newly-spec'd "oncontentvisibilityautostatechange") survive on the clobbered root via the same skip; the per-name allow-list at ":1361-1364" never runs. Verified — full attribute set survives on a single payload (PoC): const root = document.createElement('form'); root.setAttribute('action', 'javascript:alert(1)'); root.setAttribute('target', '_top'); root.setAttribute('onclick', 'alert(2)'); root.setAttribute('onmouseover', 'alert(3)'); root.setAttribute('autofocus', ''); root.setAttribute('formaction', 'javascript:alert(4)'); root.setAttribute('id', 'cookie'); // DOM-clobbering primitive root.innerHTML += ''; DOMPurify.sanitize(root, { IN_PLACE: true }); console.log(root.outerHTML); // <form action="javascript:alert(1)" target="_top" onclick="alert(2)" // onmouseover="alert(3)" autofocus="" formaction="javascript:alert(4)" // id="cookie"> (c) Defense-in-depth re-sanitization on the same node is INEFFECTIVE — the clobber is sticky. Chromium's "HTMLFormElement" named-property cache appears to retain the named child reference even after the child's "name" attribute is removed during the sanitization pass. Empirically verified — after the first sanitize pass, the input's "name="nodeName"" attribute is correctly stripped (the output shows "" with no attributes), yet "typeof form.nodeName === 'object'" is still true and the input element is still returned. Calling "DOMPurify.sanitize(sameNode, { IN_PLACE: true })" a second time hits the same "_isClobbered" → "_forceRemove" → "_sanitizeAttributes" early-return path. The only effective recovery is serialize-then-reparse: const root = parseAttackerHtml(); // form with input name="nodeName" child DOMPurify.sanitize(root, { IN_PLACE: true }); // bypass: attrs survive DOMPurify.sanitize(root, { IN_PLACE: true }); // STILL bypassed: attrs survive const recovered = (() => { const t = document.createElement('template'); t.innerHTML = root.outerHTML; // forces a fresh parse const r = t.content.firstElementChild; DOMPurify.sanitize(r, { IN_PLACE: true }); return r; })(); // recovered.outerHTML === '' ← finally clean A "belt-and-suspenders" caller that re-runs DOMPurify on its own output is therefore not protected against this primitive on Chromium; the obvious mitigation pattern fails silently. Any user-side workaround needs to route through a string round-trip. (d) SAFE_FOR_TEMPLATES bypass for the root's attributes. When the caller sets "SAFE_FOR_TEMPLATES: true" to defend a downstream template engine (Vue, Angular, Liquid, Handlebars, …) from receiving "{{…}}" / "<%…%>" / "${…}" syntax through DOMPurify's output, attribute-level template-syntax stripping runs in the same "_sanitizeAttributes" pass that early-returns on clobbered roots (":1572-1576"). The root's attributes therefore retain raw template syntax that the downstream engine then evaluates. Verified — same PoC structure, with "SAFE_FOR_TEMPLATES: true": const root = document.createElement('form'); root.setAttribute('title', '{{evil}}'); root.setAttribute('onmouseover', 'window.__x=1'); const c = document.createElement('input'); c.setAttribute('name', 'nodeName'); root.appendChild(c); DOMPurify.sanitize(root, { IN_PLACE: true, SAFE_FOR_TEMPLATES: true }); console.log(root.outerHTML); // // ^^^^^^^^^^^^^^^^ template syntax survives This compounds with (a): a single payload exfiltrates via XSS (immediate) and via SSTI to downstream renderers (delayed). (Text-node content inside the form is still scrubbed correctly — "_scrubTemplateExpressions" at ":1868-1870" walks text/comment/CDATA/PI nodes independently and reaches them via the iterator. Only attribute values on the clobbered root escape.) Indirect / second-order - DOM-based template systems / editors that wrap DOMPurify with an IN_PLACE call for parsed user content (CMSes, comment widgets, WYSIWYG editors persisting structured HTML). - Email/HTML preview libraries that pre-parse received HTML before sanitization for performance reasons. - Frameworks that hand DOMPurify a node tree rather than a string — including, indirectly, any code path that does "el.innerHTML = …; DOMPurify.sanitize(el, { IN_PLACE: true })". The outer "el" is fine (it's not the form), but if the first child of "el" is taken as the sanitization root in a different code path, the bypass triggers. Why current "main" is also vulnerable Commit "89da34e" ("fix: fixed a possible DOM clobbering with IN_PLACE and shadow DOM") hardens "_sanitizeAttachedShadowRoots" via three new cached prototype getters ("getShadowRoot", "getNodeName", "getNodeType") and an "_isClobbered" extension that checks "element.childNodes.length". The fix is correct for its scope — shadow-root traversal — but does not change "_forceRemove"'s parent-less-node behavior or "_sanitizeAttributes"'s clobber-skip early-return. The bypass demonstrated here is in the IN_PLACE main pipeline, not the shadow-root walk, and the verification PoC above runs against HEAD "89da34e" and still succeeds. Suggested fix Two minimal-risk options: 1. Make "forceRemove" honest about failure: return whether the node was actually detached, and have the iterator call site honor that. const forceRemove = function (node: Node): boolean { arrayPush(DOMPurify.removed, { element: node }); try { getParentNode(node).removeChild(node); return true; } catch () { try { remove(node); } catch () {} return node.parentNode === null && / but still attached to itself */ false; } }; Then at ":1855", if "_sanitizeElements" returns true AND IN_PLACE, force-strip all attributes of the root before returning the dirty tree. (This is what the user expects — sanitization either succeeds or refuses to return a "sanitized" handle to an unsanitized tree.) 2. Strip attributes inside "_sanitizeAttributes" for clobbered roots: when "_isClobbered(currentNode)" is true at ":1490", instead of early-returning, iterate "currentNode.attributes" (using the cached "getAttributes" if you add one) and remove each via "removeAttribute". This preserves the existing semantics for non-root clobbered nodes (their attributes-of-a-removed-node will be GC'd anyway) and removes the attack surface for root. 3. Refuse IN_PLACE on parent-less clobbered roots: at the top of the iterator, check that the root either has a parent OR is not "_isClobbered". If both fail, throw. This is the most defensive option but breaks any existing caller that hands in a clobbered detached root expecting "sanitized = empty/safe." Note on callable elements In Chromium and WebKit, "HTMLEmbedElement", "HTMLAppletElement", "HTMLIFrameElement", and "HTMLScriptElement" have "typeof === 'function'" because they expose plugin/iframe "[[Call]]" traps at the WebIDL level. A "name="setAttribute"" child of one of these tags spoofs the "setAttribute typeof === 'function'" check — but only matters for the attribute re-set path at ":1619", not the bypass demonstrated here (which uses "nodeName" and friends). The callable-element vector is worth checking separately as a potential "SAFE_FOR_TEMPLATES"-bypass primitive; the present report does not depend on it.Publish Date: 2026-06-15
URL: CVE-2026-49459
CVSS 3 Score Details (6.1)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: Required
- Scope: Changed
- Impact Metrics:
- Confidentiality Impact: Low
- Integrity Impact: Low
- Availability Impact: None
For more information on CVSS3 Scores, click here.Suggested Fix
Type: Upgrade version
Origin: GHSA-r47g-fvhr-h676
Release Date: 2026-06-15
Fix Resolution: https://github.com/cure53/DOMPurify.git - 3.4.6,dompurify - 3.4.6
⛑️Automatic Remediation will be attempted for this issue.