How ReDoS happens in Node.js path-to-regexp and how to fix it

The Hidden Danger in Your Dependency Tree

The backend/package-lock.json file in this project quietly pulls in path-to-regexp as a transitive dependency — meaning no developer explicitly installed it, yet it sits in the resolved dependency tree and runs in production. When security scanner Trivy flagged CVE-2024-52798, it revealed that the version of path-to-regexp being resolved belonged to the unpatched 0.1.x branch — a legacy line that contains a catastrophically backtracking regular expression with no upstream fix planned for that branch.

This is the uncomfortable reality of modern JavaScript development: your node_modules folder contains hundreds of packages you never consciously chose, and any one of them can introduce a critical vulnerability. In this case, the attack surface is a regex that processes URL path strings — exactly the kind of input that flows in from the internet.

The Vulnerability Explained

What is path-to-regexp?

path-to-regexp is a utility that converts Express-style route strings like /users/:id into regular expressions for URL matching. It's one of the most downloaded npm packages ever, used under the hood by Express.js, Koa, and many other frameworks and tools.

The ReDoS Problem in 0.1.x

CVE-2024-52798 describes a Regular Expression Denial of Service (ReDoS) flaw in the path-to-regexp 0.1.x branch. The root cause is a regex pattern that exhibits catastrophic backtracking — a phenomenon where the regex engine's attempt to find a match causes it to explore an exponentially growing number of possible paths through the input string.

A simplified illustration of the kind of pattern that causes this:

// Vulnerable pattern (conceptual illustration of catastrophic backtracking)
const re = /^(\w+\s?)*$/;

// Benign input — matches instantly
re.test("hello world");

// Malicious input — causes exponential backtracking
re.test("aaaaaaaaaaaaaaaaaaaaaaaaaaaa!");

In path-to-regexp 0.1.x, the generated regex for certain route patterns contains nested quantifiers that interact badly with malformed path strings. An attacker who can influence the URL path being matched — for example, by sending a crafted HTTP request — can trigger this backtracking.

Why Node.js Is Especially Vulnerable

Node.js runs JavaScript on a single-threaded event loop. Unlike multi-threaded servers that can isolate a slow request to one thread, a ReDoS attack in Node.js blocks all request processing for the duration of the backtracking. A single malicious HTTP request can render the entire application unresponsive.

The Vulnerable Dependency Chain

The vulnerable version was pulled in transitively through websocket-driver 0.7.4:

websocket-driver@0.7.4
  └── websocket-extensions (which resolves path-to-regexp@0.1.x)

The package-lock.json before the fix resolved:

"node_modules/websocket-driver": {
  "version": "0.7.4",
  "resolved": "https://registry.npmjs.org/websocket-driver/-/websocket-driver-0.7.4.tgz",
  "integrity": "sha512-b17KeDIQVjvb0ssuSDF2cYXSg2iztliJ4B9WdsuB6J952qCPKmnVq4DyW5motImXHDC1cBT/1UezrJVsKw5zjg=="
}

This older version of websocket-driver depended on a sub-dependency that resolved path-to-regexp into the vulnerable 0.1.x range.

Attack Scenario

Consider a WebSocket handshake endpoint in this application. The websocket-driver package processes the HTTP Upgrade request, and internally path-to-regexp 0.1.x is used to match the request path. An attacker sends a stream of HTTP Upgrade requests with carefully crafted paths:

GET /aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa!!! HTTP/1.1
Connection: Upgrade
Upgrade: websocket

Each request triggers catastrophic backtracking in the regex engine. Because Node.js is single-threaded, the event loop stalls, and legitimate users receive no responses. The server is effectively down — with no memory exhaustion, no crashes, just a frozen process.

The Fix

What Changed

The fix involved two coordinated changes across frontend/package.json and frontend/package-lock.json.

1. package-lock.json — Upgrading the resolved version

 "node_modules/websocket-driver": {
-  "version": "0.7.4",
-  "resolved": "https://registry.npmjs.org/websocket-driver/-/websocket-driver-0.7.4.tgz",
-  "integrity": "sha512-b17KeDIQVjvb0ssuSDF2cYXSg2iztliJ4B9WdsuB6J952qCPKmnVq4DyW5motImXHDC1cBT/1UezrJVsKw5zjg==",
+  "version": "0.7.5",
+  "resolved": "https://registry.npmjs.org/websocket-driver/-/websocket-driver-0.7.5.tgz",
+  "integrity": "sha512-ZL2+3c7kMBdIRCMz6l8jQMHyGVxj+UL+xVk74Ombiciboca8rHa15L86B19E5oh1pL9Ii/uj54gtsIrZGMo6zA==",
+  "license": "Apache-2.0",

websocket-driver 0.7.5 updates its own dependency chain so that path-to-regexp 0.1.x is no longer resolved. The new integrity hash (sha512-ZL2+3c7...) confirms the package contents have changed and pins the exact safe artifact.

2. package.json — Adding an override to enforce the safe version

 "overrides": {
-  "shell-quote": "1.9.0"
+  "shell-quote": "1.9.0",
+  "websocket-driver": "0.7.5"
 }

This is the critical second step. npm's overrides field forces all resolutions of websocket-driver in the dependency tree — direct and transitive — to use version 0.7.5. Without this override, a future npm install could potentially re-resolve an older version if another dependency requested it. The override acts as a security policy enforced at the package manager level.

Why Both Changes Are Necessary

The package-lock.json change fixes the current resolved state. The package.json override ensures the fix is durable — it survives future dependency updates and npm install runs by any developer on the team. Together, they provide both an immediate fix and a long-term guard.

Key Takeaways

• path-to-regexp 0.1.x is permanently vulnerable — there is no patch for the 0.1.x branch. Any project resolving this version is exposed to CVE-2024-52798 until the dependency chain is updated.
• websocket-driver 0.7.4 was the direct parent pulling in the vulnerable version — upgrading it to 0.7.5 in package-lock.json was the first required step.
• The package.json override "websocket-driver": "0.7.5" is what makes the fix permanent — without it, the vulnerable version could return after the next npm install.
• A single malicious HTTP request is enough to trigger this ReDoS and freeze the Node.js event loop, making it a low-effort, high-impact attack.
• Transitive dependency scanning must be part of your CI pipeline — neither path-to-regexp nor websocket-driver appears in this project's direct dependencies, yet both were present in the resolved tree.

How Orbis AppSec Detected This

• Source: Attacker-controlled URL path strings arriving via HTTP/WebSocket Upgrade requests processed by websocket-driver
• Sink: The regex compilation and matching logic inside path-to-regexp 0.1.x, invoked transitively through websocket-driver@0.7.4's dependency chain in frontend/package-lock.json
• Missing control: No version constraint or override existed to prevent npm from resolving the vulnerable path-to-regexp 0.1.x range; the package.json overrides block did not include websocket-driver
• CWE: CWE-1333 — Inefficient Regular Expression Complexity
• Fix: websocket-driver was upgraded from 0.7.4 to 0.7.5 in package-lock.json, and "websocket-driver": "0.7.5" was added to the overrides field in package.json to permanently enforce the safe version across the entire dependency tree

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-2024-52798 is a reminder that the most dangerous vulnerabilities in modern Node.js applications are often ones you never wrote yourself. The path-to-regexp 0.1.x ReDoS flaw lives three levels deep in a dependency tree, invisible to casual inspection, yet capable of taking down a production server with a single crafted request.

The fix here is precise and durable: upgrading websocket-driver to 0.7.5 evicts the vulnerable package version, while the package.json override ensures no future npm install can silently reintroduce it. Both changes together — one in the lock file, one in the manifest — represent the correct, complete approach to remediating transitive dependency vulnerabilities.

For your own projects: run npm audit and a dedicated SCA scanner like Trivy regularly, use overrides as an active security policy, and treat your package-lock.json as a security artifact that deserves the same review attention as your source code.