Back to Blog
high SEVERITY7 min read

How Denial of Service via Unbounded Intermediate Arrays happens in JavaScript and how to fix it

CVE-2026-69152 is a high-severity Denial of Service vulnerability in the `brace-expansion` npm package (versions prior to 1.1.18/2.1.4/3.0.6/5.0.9) that allows attackers to crash a Node.js application by crafting glob patterns that generate unbounded intermediate arrays, effectively bypassing the earlier CVE-2026-14257 mitigation. The fix upgrades `brace-expansion` from 1.1.14 to 1.1.18 in `frontend/package-lock.json`, closing the bypass and restoring safe memory bounds during pattern expansion.

O
By Orbis AppSec
•Published August 26, 2026•Reviewed August 26, 2026
#security#denial-of-service#javascript#nodejs#npm-dependency

Answer Summary

CVE-2026-69152 is a Denial of Service vulnerability (CWE-400: Uncontrolled Resource Consumption) in the `brace-expansion` npm package affecting versions before 1.1.18, 2.1.4, 3.0.6, and 5.0.9. Attackers supply a specially crafted brace-expansion pattern that causes the library to allocate unbounded intermediate arrays during expansion, exhausting process memory and crashing the application — even on builds that applied the earlier CVE-2026-14257 patch. The fix is a version upgrade: pin `brace-expansion` to 1.1.18 (or the appropriate major-version equivalent) in `package-lock.json` and lock the transitive `minimatch` dependency to consume only the patched release.

Vulnerability at a Glance

cweCWE-400
fixUpgrade brace-expansion to 1.1.18 in frontend/package-lock.json and pin minimatch's dependency to the patched version
riskAn attacker can crash or hang a Node.js process by supplying a malicious glob/brace-expansion pattern
languageJavaScript / Node.js
root causebrace-expansion 1.1.14 failed to bound intermediate array growth during recursive pattern expansion, bypassing the CVE-2026-14257 mitigation
vulnerabilityDenial of Service via Unbounded Intermediate Array Allocation

How Denial of Service via Unbounded Intermediate Arrays Happens in JavaScript and How to Fix It

Introduction

The frontend/package-lock.json file governs every transitive JavaScript dependency the frontend build installs — including low-level utility libraries that most developers never think about. One of those utilities, brace-expansion, is responsible for expanding shell-style brace patterns like {a,b,c} or {1..100} into flat string arrays. It is pulled in automatically by minimatch, which is itself a dependency of many popular build tools.

In this project, brace-expansion was pinned at version 1.1.14. That version contains a high-severity Denial of Service vulnerability tracked as CVE-2026-69152: a carefully crafted input pattern causes the library to build intermediate arrays with no upper bound on their size, consuming all available heap memory and crashing the Node.js process. What makes this CVE particularly interesting is that it is not a brand-new class of bug — it is a bypass of the mitigation that was already shipped for the earlier CVE-2026-14257. The attacker community found a way around the guard rail, and 1.1.14 never received the follow-up patch.

The Vulnerability Explained

What brace-expansion does

brace-expansion takes a string such as "file.{js,ts,tsx}" and returns ["file.js", "file.ts", "file.tsx"]. For numeric ranges like "{1..10000}" it generates every integer in that range. Internally the library builds intermediate arrays at each expansion step before concatenating them into the final result.

Where 1.1.14 falls short

The CVE-2026-14257 patch added a check to limit the total number of final expanded strings. However, the intermediate arrays assembled during the recursive expansion steps were not subject to the same limit. An attacker can craft a nested pattern where the intermediate arrays grow exponentially before the final-count guard is ever evaluated:

# Example of a pathological pattern (illustrative)
"{a,b,c,d,e,f,g,h}{a,b,c,d,e,f,g,h}{a,b,c,d,e,f,g,h}...{...}"

Each nested brace group multiplies the size of the intermediate result array. Because 1.1.14's guard only inspects the output length, not the working memory during expansion, the process can allocate gigabytes of heap before the check fires — or before the check fires at all if the pattern is designed to stay just under the output threshold while maximising intermediate allocations.

The vulnerable dependency declaration in package-lock.json

Before the fix, the node_modules/brace-expansion block read:

"node_modules/brace-expansion": {
  "version": "1.1.14",
  "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-1.1.14.tgz",
  "integrity": "sha512-MWPGfDxnyzKU7rNOW9SP/c50vi3xrmrua/+6hfPbCS2ABNWfx24vPidzvC7krjU/RTo235sV776ymlsMtGKj8g==",
  "dependencies": {
    "balanced-match": "^1.0.0",
    "concat-map": "0.0.1"
  }
}

And the legacy "dependencies" section of the lockfile mirrored the same version. Meanwhile, minimatch declared a loose range:

"minimatch": {
  "requires": {
    "brace-expansion": "^1.1.7"
  }
}

The ^1.1.7 range permits any 1.x release ≥ 1.1.7, but npm install had resolved it to 1.1.14 and frozen that in the lockfile — meaning the vulnerable version was locked in place and would not auto-upgrade.

Real-world attack scenario

If any part of this frontend's build pipeline or server-side rendering layer passes user-controlled strings to a function that internally calls minimatch or brace-expansion (e.g., a file-glob API, a template engine, or a search filter that supports glob syntax), an attacker can send a POST body containing a malicious pattern. The Node.js process expands the pattern, intermediate arrays balloon unchecked, the heap limit is hit, and the process crashes or becomes unresponsive — a classic CWE-400 Uncontrolled Resource Consumption scenario.

Even if the application does not expose glob inputs directly today, the vulnerability lives in the dependency tree and can be triggered by future feature additions or by tooling that runs in CI/CD pipelines.

The Fix

Upgrading brace-expansion to 1.1.18

The pull request makes two targeted changes to frontend/package-lock.json (and a corresponding update to frontend/package.json).

Change 1 — the node_modules/brace-expansion block:

 "node_modules/brace-expansion": {
-  "version": "1.1.14",
-  "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-1.1.14.tgz",
-  "integrity": "sha512-MWPGfDxnyzKU7rNOW9SP/c50vi3xrmrua/+6hfPbCS2ABNWfx24vPidzvC7krjU/RTo235sV776ymlsMtGKj8g==",
+  "version": "1.1.18",
+  "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-1.1.18.tgz",
+  "integrity": "sha512-Edep/X9fGqVNmzKBVsDYIOtD+z1tuezV70LBjdCst9Tqu76lsnvRiZ6oTic1n+/BIwX6QDGAO94PN4N2SADvtw==",
+  "license": "MIT",
   "dependencies": {
     "balanced-match": "^1.0.0",
     "concat-map": "0.0.1"
   }
 }

Change 2 — the legacy "dependencies" section:

 "brace-expansion": {
-  "version": "1.1.14",
-  "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-1.1.14.tgz",
-  "integrity": "sha512-MWPGfDxnyzKU7rNOW9SP/c50vi3xrmrua/+6hfPbCS2ABNWfx24vPidzvC7krjU/RTo235sV776ymlsMtGKj8g==",
+  "version": "1.1.18",
+  "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-1.1.18.tgz",
+  "integrity": "sha512-Edep/X9fGqVNmzKBVsDYIOtD+z1tuezV70LBjdCst9Tqu76lsnvRiZ6oTic1n+/BIwX6QDGAO94PN4N2SADvtw==",
   "requires": {
     "balanced-match": "^1.0.0",
     "concat-map": "0.0.1"
   }
 }

Change 3 — pinning minimatch's transitive requirement:

 "minimatch": {
   "requires": {
-    "brace-expansion": "^1.1.7"
+    "brace-expansion": "1.1.18"
   }
 }

Why each change matters

Change Purpose
Bump node_modules/brace-expansion to 1.1.18 Ensures npm ci installs the patched version in the module tree
Bump the legacy lockfile brace-expansion entry Keeps both lockfile formats consistent; older npm clients read the flat section
Pin minimatch → brace-expansion to exact 1.1.18 Prevents a future npm install from resolving the loose ^1.1.7 range back to a vulnerable version

Version 1.1.18 introduces bounds checking on the intermediate arrays during recursive expansion, not just on the final output count. This closes the bypass that made CVE-2026-14257's mitigation ineffective.

Key Takeaways

  • The CVE-2026-14257 mitigation in brace-expansion 1.1.14 was incomplete: it guarded final output size but left intermediate array allocation unbounded, creating a bypass that CVE-2026-69152 exploits.
  • Lockfile pinning matters: the loose "brace-expansion": "^1.1.7" range in minimatch's requires block would have allowed npm to resolve back to a vulnerable version; the fix pins it to the exact safe release 1.1.18.
  • Transitive dependencies carry real risk: brace-expansion is three levels deep in the dependency tree, yet a single malicious string passed to minimatch can crash the process.
  • Both lockfile sections must be updated: package-lock.json contains both a node_modules/ tree section and a legacy flat "dependencies" section; updating only one leaves the other out of sync and can cause inconsistent installs across npm versions.
  • Trivy caught what manual review would likely miss: no developer routinely audits the integrity hash of a three-level-deep transitive dependency — automated scanning is the practical defence here.

How Orbis AppSec Detected This

  • Source: The brace-expansion package version string ("1.1.14") declared in frontend/package-lock.json — data that originates from the npm registry resolution of user-installed dependencies.
  • Sink: Any call site within the application's dependency tree that invokes brace-expansion's internal array-building logic with an attacker-controlled pattern string (reachable through minimatch and any library that depends on it).
  • Missing control: No upper bound on intermediate array allocation during recursive brace expansion; the existing CVE-2026-14257 guard only checked final output length, not working memory.
  • CWE: CWE-400 — Uncontrolled Resource Consumption.
  • Fix: brace-expansion was upgraded from 1.1.14 to 1.1.18 in both sections of frontend/package-lock.json, and minimatch's transitive requirement was pinned to the exact patched version.

Orbis AppSec automatically detected this vulnerability and opened a pull request with the fix. Try Orbis AppSec on your repositories to find and fix issues like this automatically.

Conclusion

CVE-2026-69152 is a sharp reminder that security patches are not always final. The brace-expansion maintainers shipped a fix for CVE-2026-14257, but an attacker-visible bypass remained in the intermediate array allocation path — and versions that never received the follow-up patch (like 1.1.14) stayed vulnerable. Upgrading to 1.1.18 closes both the original issue and the bypass in one step.

For JavaScript developers, the lesson is clear: keep lockfiles up to date, scan them automatically in CI, and treat transitive dependencies with the same security scrutiny you apply to first-party code. A three-line change to package-lock.json is all it takes to eliminate a high-severity DoS vector.

Prevention and further reading

View the Security Fix

Check out the pull request that fixed this vulnerability

View PR #464
View Repository →

Related Articles

critical

deleteNestedProperty Prototype Pollution via Dot-Notation Path

The `deleteNestedProperty` function in propertyUtils.ts allowed attackers to manipulate JavaScript object prototypes by passing specially crafted dot-notation paths like `__proto__.polluted`. A fix now blocks dangerous keys before processing, preventing prototype pollution attacks that could affect all objects in the application.

high

How Denial of Service via Infinite Loop Happens in JavaScript Dependencies and How to Fix It

CVE-2026-67213 is a high-severity denial of service vulnerability in nanoid before version 5.1.6 that triggers an infinite loop during random ID generation when processing specially crafted input. We upgraded nanoid across the entire dependency tree to patch this flaw and prevent attackers from freezing application threads. This fix ensures that ID generation remains resilient even when handling adversarial input patterns.

high

How Sensitive Data Exposure happens in Zotero plugins and how to fix it

A high-severity data exposure vulnerability in `Zotero.ts` automatically transmitted complete document metadata—including private notes, attachment paths, and tags—to external LLM services without user consent. The fix replaces broad `item.toJSON()` serialization with explicit field selection, sending only essential bibliographic data.

high

How missing dependency update cooldowns happen in GitHub Dependabot configurations and how to fix it

A semgrep scan flagged `.github/dependabot.yml` for lacking a cooldown period, meaning Dependabot would immediately propose updates to brand-new package versions across npm, Bundler, and Docker ecosystems. The fix adds a `cooldown: default-days: 7` block to every `package-ecosystem` entry, forcing a one-week waiting period before newly published releases are considered — reducing exposure to malicious or unstable package drops.

high

How Path Traversal Happens in TensorFlow's Data Service and How to Fix It

TensorFlow's data service dispatcher validated dataset IDs against forward-slash traversal attacks but overlooked backslash characters on non-Windows platforms, allowing attackers to escape the root directory. A targeted fix adds explicit backslash validation across all platforms, closing a high-severity path traversal vulnerability in the snapshot management system.

critical

How Unbounded WebSocket Message Handling Causes Resource Exhaustion in Node.js and How to Fix It

The WebSocketCrossServerAdapter class in a popular Node.js WebSocket library lacked any rate limiting on inbound messages, allowing attackers to flood Redis nodes and WebSocket servers with high-volume traffic. The fix introduces a configurable `rateLimit` option that caps messages per connection per second, preventing resource exhaustion while preserving legitimate functionality.