How Denial of Service via Regex Happens in Node.js and how to fix it

How Denial of Service via Regex Happens in Node.js and how to fix it

Introduction

The superset-frontend/cypress-base/ directory in Apache Superset houses the Cypress end-to-end testing harness. It is easy to dismiss test tooling as a low-risk area of the codebase, but its package-lock.json sits in the production repository, is pulled during CI, and—critically—was pinned to a version of brace-expansion that carries a confirmed denial-of-service vulnerability: CVE-2026-14257.

Trivy flagged brace-expansion 5.0.7 in this lockfile as HIGH severity. The fix was a single-version bump to 5.0.8, but understanding why this matters requires a closer look at what brace-expansion does, how its regex went wrong, and what an attacker can do with it.

The Vulnerability Explained

What is brace-expansion?

brace-expansion is a tiny but widely-used npm package that expands shell-style brace expressions like {a,b,c} or file{1..5}.txt into their constituent strings. It is a transitive dependency of tools like glob, minimatch, and mocha—meaning it quietly powers file-matching logic across the Node.js ecosystem.

The Root Cause: Catastrophic Backtracking

In versions through 5.0.7, brace-expansion contained a regular expression used to parse brace tokens. That regex was susceptible to catastrophic backtracking—a class of bug where the regex engine explores an exponentially growing number of possible match paths when given a specially crafted input.

The vulnerable pattern looked structurally similar to:

// Simplified illustration of the problematic regex shape in brace-expansion ≤5.0.7
const re = /(\{[^{}]*\})+/;

When an attacker supplies a deeply nested or repetitive brace string—such as:

{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{

—the engine must consider every possible way the nested groups can match or fail before concluding the string is invalid. The evaluation time grows exponentially with input length, not linearly. A string of ~50 characters can stall a Node.js event loop for seconds; a string of ~100 characters can stall it for minutes.

Why This Matters for Superset

Superset's Cypress base runs in CI pipelines that are often exposed to external pull requests or parameterized build triggers. If any part of the build pipeline passes user-controlled strings through a glob or minimatch call backed by the vulnerable brace-expansion, an attacker can submit a crafted PR or trigger a parameterized build that hangs the runner indefinitely—a classic Continuous Integration denial of service attack.

Even outside CI, the package is present in the production repository. Trivy's assessment of "likely exploitable" reflects that the vulnerable code path is reachable, not merely theoretical.

The Fix

The fix is a precise version bump in two places within superset-frontend/cypress-base/:

package-lock.json — Before

"node_modules/brace-expansion": {
  "version": "5.0.7",
  "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-5.0.7.tgz",
  "integrity": "sha512-7oFy703dxfY3/NLxC1fh2SUCQ0H9rmAY+5EpDVfXjUTTs+HEwR2nYaqLv+GWcTsumwxPfiz6CzCNkwXwBUwqCA==",
  "dev": true,
  "peer": true,
  "dependencies": {
    "balanced-match": "^4.0.2"
  },
  "engines": {
    "node": "18 || 20 || >=22"
  }
}

package-lock.json — After

"node_modules/brace-expansion": {
  "version": "5.0.8",
  "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-5.0.8.tgz",
  "integrity": "sha512-JZyDyq3D4AUifKTPOB7DELf6XsB3WdPuNxCtob1vFXPsSXhdAiHBWJ/tJ8HAc9aH84BK+5JFZLNkJKx3G9kzQg==",
  "dev": true,
  "license": "MIT",
  "peer": true,
  "dependencies": {
    "balanced-match": "^4.0.2"
  },
  "engines": {
    "node": "20 || >=22"
  }
}

Three concrete changes stand out:

The integrity hash change is especially important from a supply-chain perspective: it means the lockfile now pins to a specific, audited tarball. Any attempt to serve the old 5.0.7 tarball under the new version number would fail the integrity check.

The same version bump is reflected in the flat "brace-expansion" entry lower in the lockfile (the legacy npm v1/v2 format section), ensuring both resolution paths point to the patched package.

Prevention & Best Practices

1. Run a Software Composition Analysis (SCA) scanner on every PR

Tools like Trivy, Snyk, or OWASP Dependency-Check will catch known-CVE package versions before they reach main. Integrate them as a required CI check, not an optional advisory one.

# Example: Trivy filesystem scan targeting the lockfile
trivy fs superset-frontend/cypress-base/package-lock.json \
  --severity HIGH,CRITICAL \
  --exit-code 1

2. Keep lockfiles committed and regularly updated

A committed package-lock.json gives scanners a precise target. Use npm audit or Dependabot/Renovate to automate patch-version bumps for known CVEs.

npm audit fix --package-lock-only

3. Treat test-tooling dependencies as production dependencies for security purposes

The dev: true flag in a lockfile does not mean "safe to ignore." If the lockfile lives in the repo, scanners will (correctly) flag it. Apply the same patching discipline to devDependencies as to runtime dependencies.

4. Avoid writing custom brace/glob parsers with hand-rolled regexes

If you ever need to parse shell-style patterns in Node.js, use a well-maintained library and keep it current. If you write your own regex for pattern matching, test it against tools like vuln-regex-detector or the ReDoS checker.

5. Relevant standards

• CWE-400: Uncontrolled Resource Consumption — the canonical classification for ReDoS
• CWE-1333: Inefficient Regular Expression Complexity — the more specific sub-classification
• OWASP A05:2021 – Security Misconfiguration: Outdated or vulnerable components fall under this category
• OWASP Dependency-Check: https://owasp.org/www-project-dependency-check/

Key Takeaways

• brace-expansion ≤5.0.7 is vulnerable to ReDoS; any Node.js project with this version in its lockfile should upgrade immediately, regardless of whether the dependency is dev or peer.
• Lockfile integrity hashes are a security control, not just a reproducibility aid—the new sha512 hash in 5.0.8 ensures the patched tarball is the only one npm will accept.
• CI pipelines are attack surfaces; a crafted brace-expansion string passed through a glob call can hang a build runner, wasting compute and blocking deployments.
• The engines field change (dropping Node 18 support) is a signal that 5.0.8 is a deliberate maintenance release, not just a patch bump—review your Node version compatibility when upgrading.
• Trivy flagging a package-lock.json as "likely exploitable" should be treated as a blocking issue, not a warning to defer.

How Orbis AppSec Detected This

• Source: The brace-expansion package version 5.0.7 declared in superset-frontend/cypress-base/package-lock.json, which is user-influenced in the sense that any contributor or automated tool can propose a lockfile containing this version.
• Sink: The regex evaluation path inside brace-expansion's token parser, reachable whenever a glob pattern containing brace expressions is evaluated during the Cypress test run or any tooling that imports the package.
• Missing control: No version constraint in package.json or lockfile pinning excluded the vulnerable 5.0.7 release; no SCA gate blocked the vulnerable version from being merged.
• CWE: CWE-400 — Uncontrolled Resource Consumption (ReDoS variant, also CWE-1333).
• Fix: Upgraded brace-expansion from 5.0.7 to 5.0.8 in both the node_modules and legacy flat sections of package-lock.json, replacing the vulnerable tarball integrity hash with the patched one.

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-14257 is a reminder that no dependency is too small to be dangerous. brace-expansion is a 200-line utility package, but its flawed regex was enough to earn a HIGH severity rating and a Trivy alert in one of the most widely deployed open-source analytics platforms in the world. The fix—bumping one version number and updating two integrity hashes—took seconds to apply but required a scanner to find in the first place.

Keep your lockfiles current, run SCA on every PR, and never assume that devDependencies are outside your threat model. The build pipeline that tests your secure code needs to be just as secure as the code it tests.

References

• CWE-400: Uncontrolled Resource Consumption
• CWE-1333: Inefficient Regular Expression Complexity
• OWASP Vulnerable and Outdated Components (A06:2021)
• OWASP Dependency-Check Project
• npm audit documentation
• Semgrep rules for ReDoS / vulnerable npm packages
• fix: upgrade brace-expansion to 5.0.8 (CVE-2026-14257)