Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
10 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Expanding {a},b}-shaped input takes time quadratic in the number of literal } characters, blocking the event loop. Bash preserves a quirk where a brace group followed by a comma set still expands ({a},b}). The parser implements this by rewriting the string and restarting the scan. Each pass absorbs exactly one } and re-scans from the beginning, so n trailing braces cost n full passes. Reproduction | n | input | time | results | |---|---|---|---| | 8,000 | 8 KB | 110 ms | 2 | | 16,000 | 16 KB | 446 ms | 2 | | 32,000 | 32 KB | 1.7 s | 2 | | 64,000 | 64 KB | 6.9 s | 2 | | 128,000 | 128 KB | 27.7 s | 2 | ms/n^2 is flat at ~1.7 and each doubling of n costs exactly 4.0x - quadratic. 128 KB of input blocks the event loop for nearly half a minute to produce two results. Mechanism Instrumenting the rewrite branch confirms it runs exactly n + 1 times, once per literal }, each re-scanning the whole string. There is a second multiplier. The rewrite replaces the group's closing } with the…
Recommended action: Upgrade to 5.0.12, 3.0.9, 2.1.7 or 1.1.21 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
expand() recurses once per level of brace nesting. Deeply nested input exhausts the native stack and crashes the process. This is distinct from CVE-2026-14257 / GHSA-mh99-v99m-4gvg, which made the tail iterative (recursion on m.post, driven by how many groups are chained). Nesting depth drives a different recursion that the tail fix never touched, so the documented constant-stack-depth guarantee only ever covered chained input, not nested input. It is also distinct from GHSA-6j4f-fj2g-mc7p, which fixed recursion in parseCommaParts(). Both payloads below still crash with that fix applied. Two recursion sites Comma members. Each alternative of a brace set is expanded by a recursive call, so nesting a set inside every alternative recurses once per level: Crashes at depth 3,907 - about 15.6 KB of input. Single set. A brace set whose body parses to a single part is expanded by a recursive call before being re-wrapped (x{{a,b}}y - x{a}y x{b}y), which recurses once per nesting…
Recommended action: Upgrade to 5.0.11, 3.0.8, 2.1.6 or 1.1.20 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
parseCommaParts() can exhaust the native stack and crash the process. There are two distinct ways to trigger it, both reachable from a single untrusted pattern string. This is the parsing-side counterpart to CVE-2026-14257 / GHSA-mh99-v99m-4gvg. That fix made expand() iterative and documented a constant-stack-depth guarantee, but parseCommaParts() was left recursive, so the guarantee only held for one of the two parsing paths. Vector 1 - unbounded recursion on post parseCommaParts() recursed on the remainder of the string once per brace group: A brace group containing many comma-separated groups drives one recursion level per group: About 7,300 repetitions - roughly 29 KB of input - is enough on Node 24; roughly 6,300 (25 KB) on Node 18. The threshold is identical on every affected release line. Vector 2 - push.apply with an unbounded array Even with the recursion removed, parseCommaParts() spread whole arrays into an argument list: Function.prototype.apply places one…
Recommended action: Upgrade to 5.0.10, 3.0.7, 2.1.5 or 1.1.19 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The maxLength mitigation added in 5.0.8 for GHSA-mh99-v99m-4gvg / CVE-2026-14257 is incomplete. It bounds the accumulator where results are combined, but not the intermediate arrays that feed it. A ~25 KB input still crashes the Node process with an uncatchable out-of-memory error, so try/catch around expand() does not help. A second, related path in the same function lets a ~400 KB input block the event loop for over two minutes without ever exceeding the memory bound. Details maxLength was enforced in combine(), the single place output grows. Two arrays are built before combine() runs, and neither was bounded. 1. Comma alternatives accumulate without a running total (memory exhaustion) Each alternative in {a,b,c,...} is expanded by its own recursive expand() call, so each receives a full, independent maxLength allowance. The results were then concatenated into a single values array with no cumulative limit: With A alternatives, values can reach A maxLength characters before…
Recommended action: Upgrade to 5.0.9, 3.0.6, 2.1.4 or 1.1.18 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
expand() bounds the number of results it produces (the max option, 100000 by default) but not their length. By chaining many brace groups, an attacker keeps the result count under max while making every result grow with the number of groups. Building max long results — plus the intermediate arrays combined at each brace group — exhausts memory and crashes the Node process with an uncatchable out-of-memory error. try/catch around expand() does not help: the fatal error terminates the process. A ~7.5 KB input ('{a,b}'.repeat(1500)) is enough to crash a default Node process. Details For N chained brace groups such as '{a,b}'.repeat(N): - the result count is 2^N, immediately capped at max (100000), so the max protection appears to hold, but - each result is N characters long, so the total output size is max × N characters, which grows without bound in N. expand combines each brace set with the fully-expanded tail: The loop guard expansions.length < max limits how many strings are…
Recommended action: Upgrade to 5.0.8, 3.0.3, 2.1.3 or 1.1.17 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
brace-expansion's expand() exhibits exponential-time - O(2ⁿ) - behavior in the number of consecutive non-expanding {} groups. A short, all-ASCII input (~90 bytes/30 groups) blocks the calling thread for minutes; a slightly longer input hangs it effectively indefinitely. Because the dominant consumers run on Node's single-threaded event loop, one small input can fully stall a worker/process. In expand, post is computed unconditionally at the top of the function, before the early-return branches that don't use it: For input like a{},{},…, the first {} is non-expanding, so control reaches the {a},b} rewrite branch - but expand has already recursed into post over the entire remaining tail, only to throw the result away. Each level therefore spawns two recursive expansions over essentially the same remaining work: T(n) = 2·T(n−1) ⇒ O(2ⁿ). The max option does not mitigate this: max only bounds the output-building loops; neither the post recursion nor the rewrite recursion consults…
Recommended action: Upgrade to 5.0.7, 2.1.2 or 1.1.16 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The max option was being applied too late: When expanding a single large numeric range like {1..10000000}, the sequence generation loop generates all 10 million intermediate elements before the max limit is applied With max=10, the output is correctly limited to 10 items, but the process still allocates ~505 MB and spends ~800ms building the full intermediate array. Workaround Ensure the string to be expanded doesn't contain more values than the desired max item count.
Recommended action: Upgrade to 5.0.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A brace pattern with a zero step value (e.g., {1..2..0}) causes the sequence generation loop to run indefinitely, making the process hang for seconds and allocate heaps of memory. The loop in question: https://github.com/juliangruber/brace-expansion/blob/daa71bcb4a30a2df9bcb7f7b8daaf2ab30e5794a/src/index.ts#L184 test() is one of https://github.com/juliangruber/brace-expansion/blob/daa71bcb4a30a2df9bcb7f7b8daaf2ab30e5794a/src/index.ts#L107-L113 The increment is computed as Math.abs(0) = 0, so the loop variable never advances. On a test machine, the process hangs for about 3.5 seconds and allocates roughly 1.9 GB of memory before throwing a RangeError. Setting max to any value has no effect because the limit is only checked at the output combination step, not during sequence generation. This affects any application that passes untrusted strings to expand(), or by error sets a step value of 0. That includes tools built on minimatch/glob that resolve patterns from CLI arguments or…
Recommended action: Upgrade to 5.0.5, 3.0.2, 2.0.3 or 1.1.13 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A vulnerability was found in juliangruber brace-expansion up to 1.1.11/2.0.1/3.0.0/4.0.0. It has been rated as problematic. Affected by this issue is the function expand of the file index.js. The manipulation leads to inefficient regular expression complexity. The attack may be launched remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. Upgrading to version 1.1.12, 2.0.2, 3.0.1 and 4.0.1 is able to address this issue. The name of the patch is a5b98a4f30d7813266b221435e1eaaf25a1b0ac5. It is recommended to upgrade the affected component.
Recommended action: Upgrade to 4.0.1, 3.0.1, 2.0.2 or 1.1.12 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Affected versions of brace-expansion are vulnerable to a regular expression denial of service condition. Proof of Concept Recommendation Update to version 1.1.7 or later.
Recommended action: Upgrade to 1.1.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.