Vulnerable Library - vivid-5.9.0.tgz
Path to dependency file: /package.json
Path to vulnerable library: /package.json
Found in HEAD commit: 9e46d67b86f46339ecc0d6e70236da26187a1734
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
CVE-2025-27789
Vulnerable Library - runtime-7.23.2.tgz
Library home page: https://registry.npmjs.org/@babel/runtime/-/runtime-7.23.2.tgz
Path to dependency file: /package.json
Path to vulnerable library: /package.json
Dependency Hierarchy:
- vivid-5.9.0.tgz (Root Library)
- video.js-8.23.4.tgz
- ❌ runtime-7.23.2.tgz (Vulnerable Library)
Found in HEAD commit: 9e46d67b86f46339ecc0d6e70236da26187a1734
Found in base branch: master
Reachability Analysis
The vulnerable code is unreachable
Vulnerability Details
Babel is a compiler for writing next generation JavaScript. When using versions of Babel prior to 7.26.10 and 8.0.0-alpha.17 to compile regular expression named capturing groups, Babel will generate a polyfill for the ".replace" method that has quadratic complexity on some specific replacement pattern strings (i.e. the second argument passed to ".replace"). Generated code is vulnerable if all the following conditions are true: Using Babel to compile regular expression named capturing groups, using the ".replace" method on a regular expression that contains named capturing groups, and the code using untrusted strings as the second argument of ".replace". This problem has been fixed in "@babel/helpers" and "@babel/runtime" 7.26.10 and 8.0.0-alpha.17. It's likely that individual users do not directly depend on "@babel/helpers", and instead depend on "@babel/core" (which itself depends on "@babel/helpers"). Upgrading to "@babel/core" 7.26.10 is not required, but it guarantees use of a new enough "@babel/helpers" version. Note that just updating Babel dependencies is not enough; one will also need to re-compile the code. No known workarounds are available.
Publish Date: 2025-03-11
URL: CVE-2025-27789
Threat Assessment
Exploit Maturity: Not Defined
EPSS: 0.1%
CVSS 3 Score Details (6.2)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Local
- 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
Origin: GHSA-968p-4wvh-cqc8
Release Date: 2025-03-11
Fix Resolution (@babel/runtime): 7.26.10
Direct dependency fix Resolution (@vonage/vivid): 5.10.0
In order to enable automatic remediation, please create workflow rules
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: /package.json
Path to vulnerable library: /package.json
Dependency Hierarchy:
- vivid-5.9.0.tgz (Root Library)
- video.js-8.23.4.tgz
- mpd-parser-1.3.1.tgz
- ❌ xmldom-0.8.11.tgz (Vulnerable Library)
Found in HEAD commit: 9e46d67b86f46339ecc0d6e70236da26187a1734
Found in base branch: master
Vulnerability Details
Summary "@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. The sequence "]]>" is not allowed inside CDATA content and must be rejected or safely handled during serialization. ("MDN Web Docs" (https://developer.mozilla.org/)) Attack surface "Document.createCDATASection(data)" is the most direct entry point, but it is not the only one. The WHATWG DOM spec intentionally does not validate "]]>" in mutation methods — only "createCDATASection" carries that guard. The following paths therefore also allow "]]>" to enter a CDATASection node and reach the serializer: - "CharacterData.appendData()" - "CharacterData.replaceData()" - "CharacterData.insertData()" - Direct assignment to ".data" - Direct assignment to ".textContent" (Note: assigning to ".nodeValue" does not update ".data" in this implementation — the serializer reads ".data" directly — so ".nodeValue" is not an exploitable path.) Parse path Parsing XML that contains a CDATA section is not affected. The SAX parser's non-greedy "CDSect" regex stops at the first "]]>", so parsed CDATA data never contains the terminator. Impact If an application uses "xmldom" to generate "trusted" XML documents that embed untrusted user input inside CDATA (a common pattern in exports, feeds, SOAP/XML integrations, etc.), an attacker can inject additional XML elements/attributes into the generated document. This can lead to: - Integrity violation of generated XML documents. - Business-logic injection in downstream consumers (e.g., injecting "true", "admin", workflow flags, or other security-relevant elements). - Unexpected privilege/workflow decisions if downstream logic assumes injected nodes cannot appear. This issue does not require malformed parsers or browser behavior; it is caused by serialization producing attacker-influenced XML markup. Root Cause (with file + line numbers) File: "lib/dom.js" 1. No validation in "createCDATASection" "createCDATASection: function (data)" accepts any string and appends it directly. - Lines 2216–2221 (0.9.8) 2. Unsafe CDATA serialization Serializer prints CDATA sections as: without handling "]]>" in the data. - Lines 2919–2920 (0.9.8) Because CDATA content is emitted verbatim, an embedded "]]>" closes the CDATA section early and the remainder of the attacker-controlled payload is interpreted as markup in the serialized XML. Proof of Concept — Fix A: "createCDATASection" now throws On patched versions, passing "]]>" directly to "createCDATASection" throws "InvalidCharacterError" instead of silently accepting the payload: const { DOMImplementation } = require('./lib'); const doc = new DOMImplementation().createDocument(null, 'root', null); try { doc.createCDATASection('SAFE]]>'); console.log('VULNERABLE — no error thrown'); } catch (e) { console.log('FIXED — threw:', e.name); // InvalidCharacterError } Expected output on patched versions: FIXED — threw: InvalidCharacterError Proof of Concept — Fix B: mutation vector now safe On patched versions, injecting "]]>" via a mutation method ("appendData", "replaceData", ".data =", ".textContent =") no longer produces injectable output. The serializer splits the terminator so the result round-trips as safe text: const { DOMImplementation, XMLSerializer } = require('./lib'); const { DOMParser } = require('./lib'); const doc = new DOMImplementation().createDocument(null, 'root', null); // Start with safe data, then mutate to include the terminator const cdata = doc.createCDATASection('safe'); doc.documentElement.appendChild(cdata); cdata.appendData(']]>TEXT 0; console.log('Injected element found in reparsed doc:', injected); // VULNERABLE: true | FIXED: false Expected output on patched versions: Serialized: TEXT Injected element found in reparsed doc: false Fix Applied Both mitigations were implemented: Option A — Strict/spec-aligned: reject "]]>" in "createCDATASection()" "Document.createCDATASection(data)" now throws "InvalidCharacterError" (per the "WHATWG DOM spec" (https://dom.spec.whatwg.org/#dom-document-createcdatasection)) when "data" contains "]]>". This closes the direct entry point. Code that previously passed a string containing "]]>" to "createCDATASection" and relied on the silent/unsafe behaviour will now receive "InvalidCharacterError". Use a mutation method such as "appendData" if you intentionally need "]]>" in a CDATASection node's data (the serializer split in Option B will keep the output safe). Option B — Defensive serialization: split the terminator during serialization "XMLSerializer" now replaces every occurrence of "]]>" in CDATA section data with the split sequence "]]]]>" before emitting. This closes all mutation-vector paths that Option A alone cannot guard, and means the serialized output is always well-formed XML regardless of how "]]>" entered the node.
Publish Date: 2026-04-01
URL: CVE-2026-34601
Threat Assessment
Exploit Maturity: Not Defined
EPSS:
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-0540
Vulnerable Library - dompurify-3.3.1.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.1.tgz
Path to dependency file: /package.json
Path to vulnerable library: /package.json
Dependency Hierarchy:
- vivid-5.9.0.tgz (Root Library)
- ❌ dompurify-3.3.1.tgz (Vulnerable Library)
Found in HEAD commit: 9e46d67b86f46339ecc0d6e70236da26187a1734
Found in base branch: master
Vulnerability Details
DOMPurify 3.1.3 through 3.3.1 and 2.5.3 through 2.5.8, fixed in commit 729097f, contain a cross-site scripting vulnerability that allows attackers to bypass attribute sanitization by exploiting five missing rawtext elements (noscript, xmp, noembed, noframes, iframe) in the SAFE_FOR_XML regex. Attackers can include payloads like 
in attribute values to execute JavaScript when sanitized output is placed inside these unprotected rawtext contexts.
Mend Note: The description of this vulnerability differs from MITRE.
Publish Date: 2026-03-03
URL: CVE-2026-0540
Threat Assessment
Exploit Maturity: Not Defined
EPSS: 0.0%
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-v2wj-7wpq-c8vv
Release Date: 2026-03-03
Fix Resolution: dompurify - 3.3.2,dompurify - 2.5.9
In order to enable automatic remediation for this issue, please create workflow rules
Path to dependency file: /package.json
Path to vulnerable library: /package.json
Found in HEAD commit: 9e46d67b86f46339ecc0d6e70236da26187a1734
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 - runtime-7.23.2.tgz
Library home page: https://registry.npmjs.org/@babel/runtime/-/runtime-7.23.2.tgz
Path to dependency file: /package.json
Path to vulnerable library: /package.json
Dependency Hierarchy:
Found in HEAD commit: 9e46d67b86f46339ecc0d6e70236da26187a1734
Found in base branch: master
Reachability Analysis
The vulnerable code is unreachable
Vulnerability Details
Babel is a compiler for writing next generation JavaScript. When using versions of Babel prior to 7.26.10 and 8.0.0-alpha.17 to compile regular expression named capturing groups, Babel will generate a polyfill for the ".replace" method that has quadratic complexity on some specific replacement pattern strings (i.e. the second argument passed to ".replace"). Generated code is vulnerable if all the following conditions are true: Using Babel to compile regular expression named capturing groups, using the ".replace" method on a regular expression that contains named capturing groups, and the code using untrusted strings as the second argument of ".replace". This problem has been fixed in "@babel/helpers" and "@babel/runtime" 7.26.10 and 8.0.0-alpha.17. It's likely that individual users do not directly depend on "@babel/helpers", and instead depend on "@babel/core" (which itself depends on "@babel/helpers"). Upgrading to "@babel/core" 7.26.10 is not required, but it guarantees use of a new enough "@babel/helpers" version. Note that just updating Babel dependencies is not enough; one will also need to re-compile the code. No known workarounds are available.
Publish Date: 2025-03-11
URL: CVE-2025-27789
Threat Assessment
Exploit Maturity: Not Defined
EPSS: 0.1%
CVSS 3 Score Details (6.2)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Local
- 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
Origin: GHSA-968p-4wvh-cqc8
Release Date: 2025-03-11
Fix Resolution (@babel/runtime): 7.26.10
Direct dependency fix Resolution (@vonage/vivid): 5.10.0
In order to enable automatic remediation, please create workflow rules
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: /package.json
Path to vulnerable library: /package.json
Dependency Hierarchy:
Found in HEAD commit: 9e46d67b86f46339ecc0d6e70236da26187a1734
Found in base branch: master
Vulnerability Details
Summary "@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. The sequence "]]>" is not allowed inside CDATA content and must be rejected or safely handled during serialization. ("MDN Web Docs" (https://developer.mozilla.org/)) Attack surface "Document.createCDATASection(data)" is the most direct entry point, but it is not the only one. The WHATWG DOM spec intentionally does not validate "]]>" in mutation methods — only "createCDATASection" carries that guard. The following paths therefore also allow "]]>" to enter a CDATASection node and reach the serializer: - "CharacterData.appendData()" - "CharacterData.replaceData()" - "CharacterData.insertData()" - Direct assignment to ".data" - Direct assignment to ".textContent" (Note: assigning to ".nodeValue" does not update ".data" in this implementation — the serializer reads ".data" directly — so ".nodeValue" is not an exploitable path.) Parse path Parsing XML that contains a CDATA section is not affected. The SAX parser's non-greedy "CDSect" regex stops at the first "]]>", so parsed CDATA data never contains the terminator. Impact If an application uses "xmldom" to generate "trusted" XML documents that embed untrusted user input inside CDATA (a common pattern in exports, feeds, SOAP/XML integrations, etc.), an attacker can inject additional XML elements/attributes into the generated document. This can lead to: - Integrity violation of generated XML documents. - Business-logic injection in downstream consumers (e.g., injecting "true", "admin", workflow flags, or other security-relevant elements). - Unexpected privilege/workflow decisions if downstream logic assumes injected nodes cannot appear. This issue does not require malformed parsers or browser behavior; it is caused by serialization producing attacker-influenced XML markup. Root Cause (with file + line numbers) File: "lib/dom.js" 1. No validation in "createCDATASection" "createCDATASection: function (data)" accepts any string and appends it directly. - Lines 2216–2221 (0.9.8) 2. Unsafe CDATA serialization Serializer prints CDATA sections as: without handling "]]>" in the data. - Lines 2919–2920 (0.9.8) Because CDATA content is emitted verbatim, an embedded "]]>" closes the CDATA section early and the remainder of the attacker-controlled payload is interpreted as markup in the serialized XML. Proof of Concept — Fix A: "createCDATASection" now throws On patched versions, passing "]]>" directly to "createCDATASection" throws "InvalidCharacterError" instead of silently accepting the payload: const { DOMImplementation } = require('./lib'); const doc = new DOMImplementation().createDocument(null, 'root', null); try { doc.createCDATASection('SAFE]]>'); console.log('VULNERABLE — no error thrown'); } catch (e) { console.log('FIXED — threw:', e.name); // InvalidCharacterError } Expected output on patched versions: FIXED — threw: InvalidCharacterError Proof of Concept — Fix B: mutation vector now safe On patched versions, injecting "]]>" via a mutation method ("appendData", "replaceData", ".data =", ".textContent =") no longer produces injectable output. The serializer splits the terminator so the result round-trips as safe text: const { DOMImplementation, XMLSerializer } = require('./lib'); const { DOMParser } = require('./lib'); const doc = new DOMImplementation().createDocument(null, 'root', null); // Start with safe data, then mutate to include the terminator const cdata = doc.createCDATASection('safe'); doc.documentElement.appendChild(cdata); cdata.appendData(']]>TEXT 0; console.log('Injected element found in reparsed doc:', injected); // VULNERABLE: true | FIXED: false Expected output on patched versions: Serialized: TEXT Injected element found in reparsed doc: false Fix Applied Both mitigations were implemented: Option A — Strict/spec-aligned: reject "]]>" in "createCDATASection()" "Document.createCDATASection(data)" now throws "InvalidCharacterError" (per the "WHATWG DOM spec" (https://dom.spec.whatwg.org/#dom-document-createcdatasection)) when "data" contains "]]>". This closes the direct entry point. Code that previously passed a string containing "]]>" to "createCDATASection" and relied on the silent/unsafe behaviour will now receive "InvalidCharacterError". Use a mutation method such as "appendData" if you intentionally need "]]>" in a CDATASection node's data (the serializer split in Option B will keep the output safe). Option B — Defensive serialization: split the terminator during serialization "XMLSerializer" now replaces every occurrence of "]]>" in CDATA section data with the split sequence "]]]]>" before emitting. This closes all mutation-vector paths that Option A alone cannot guard, and means the serialized output is always well-formed XML regardless of how "]]>" entered the node.
Publish Date: 2026-04-01
URL: CVE-2026-34601
Threat Assessment
Exploit Maturity: Not Defined
EPSS:
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.1.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.1.tgz
Path to dependency file: /package.json
Path to vulnerable library: /package.json
Dependency Hierarchy:
Found in HEAD commit: 9e46d67b86f46339ecc0d6e70236da26187a1734
Found in base branch: master
Vulnerability Details
DOMPurify 3.1.3 through 3.3.1 and 2.5.3 through 2.5.8, fixed in commit 729097f, contain a cross-site scripting vulnerability that allows attackers to bypass attribute sanitization by exploiting five missing rawtext elements (noscript, xmp, noembed, noframes, iframe) in the SAFE_FOR_XML regex. Attackers can include payloads like
in attribute values to execute JavaScript when sanitized output is placed inside these unprotected rawtext contexts.
Mend Note: The description of this vulnerability differs from MITRE.
Publish Date: 2026-03-03
URL: CVE-2026-0540
Threat Assessment
Exploit Maturity: Not Defined
EPSS: 0.0%
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-v2wj-7wpq-c8vv
Release Date: 2026-03-03
Fix Resolution: dompurify - 3.3.2,dompurify - 2.5.9
In order to enable automatic remediation for this issue, please create workflow rules