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
•Technically reviewed by Anupam Mediratta•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

high

MapManager.get() Race Condition Duplicates API Requests

The MapManager's `get(mapUid, cache)` method used a check-then-act pattern that permitted multiple concurrent requests to pass the cache miss check simultaneously, triggering redundant API calls and risking cache corruption. The fix introduces a `_pending` promise map to deduplicate in-flight fetches for identical map UIDs.

critical

Lampa Desktop Auto-Update Heuristic Bypass: Execution of Unverified

Lampa Desktop's auto-update mechanism downloaded JavaScript and CSS from `raw.githubusercontent.com` using only heuristic validation—file size thresholds and string pattern matching—that attackers could trivially satisfy. The fix introduces cryptographic integrity verification by cross-referencing Git blob hashes from the GitHub Contents API, ensuring downloaded code matches the repository's authoritative state before execution.

high

adm-zip 0.6.0 Preserves SUID Bits From ZIPs: CVE-2026-102282

The `adm-zip` dependency resolved to 0.6.0 in this project's dependency tree, a version affected by CVE-2026-102282: during extraction it applies the Unix permission bits stored in each ZIP entry's external file attributes verbatim, including the setuid (`04000`), setgid (`02000`), and sticky bits. An attacker who controls an archive passed to `extractAllTo()` or `extractEntryTo()` can therefore have the extractor create a setuid binary owned by whatever user the extraction process runs as. The

high

requestInput() Type Confusion: NaN and Object Bypass in JavaScript

The `requestInput()` utility function lacked validation on its `type` parameter and failed to handle `NaN` results from float conversions, creating a type confusion weakness. An attacker could supply malformed inputs that propagate unhandled `NaN` values or unexpected object types through the type system. The fix adds explicit guards against `NaN` type parameters and rejects non-primitive type values.

critical

No Rate Limit on /api/uploads/presign Enables DoS

The `/api/uploads/presign` endpoint accepted unlimited concurrent requests to generate storage presigned URLs, giving an attacker a free lever to exhaust storage-provider quotas and server resources. The fix adds an `express-rate-limit` middleware capping each client to 30 requests per minute on that route.

high

CVE-2026-54673: builder-util-runtime Leaks Auth Headers on Redirect

electron-updater and electron-builder rely on builder-util-runtime to fetch update manifests and artifacts over HTTP. A flaw in that shared HTTP executor allowed credential headers attached to the original update-feed request to be re-sent after a redirect, exposing them to any host the redirect pointed to. The project fixes this by upgrading builder-util-runtime to 9.7.0 and collapsing a duplicate, older copy of the package that electron-updater had pinned on its own.