CVE-2021-23343: ReDoS in path-parse

CVE-2021-23343 is a Regular Expression Denial of Service (ReDoS) vulnerability in path-parse, a small but widely-depended-upon npm package that splits file system paths into their component parts (root, directory, base, extension, name). The flaw lives in the regular expressions path-parse uses internally to parse Windows-style and POSIX-style paths. When path-parse is asked to parse a specially crafted, pathological input string, its splitting regex can be forced into catastrophic backtracking — causing CPU usage to spike and the parsing call (and, in single-threaded Node.js, the entire event loop) to hang.

path-parse itself doesn't sound like a headline-grabbing package, but that's exactly what makes this CVE worth understanding: it sits deep in the dependency tree of tools like webpack, resolve, and countless build and bundling pipelines. A ReDoS bug several layers down the dependency graph can quietly become a denial-of-service vector in any application that ultimately calls into it with attacker-influenced input — for example, a service that parses user-supplied file paths, uploaded filenames, or URL segments as part of a resolve/build step.

What ReDoS Means in Practice

Regular Expression Denial of Service occurs when a regex engine, given a certain class of malicious input, takes exponential (or high-polynomial) time to evaluate a pattern instead of the expected linear time. This typically happens with regexes containing nested or overlapping quantifiers (e.g., patterns resembling (a+)+ ) that force the engine to try an enormous number of matching paths before failing. An attacker doesn't need memory corruption or code execution — they just need to hand the vulnerable function a string engineered to trigger worst-case backtracking. In path-parse's case, the vulnerable regex logic is part of how the library separates a path's root/device prefix from the rest of the string, and a long, repetitive path-like string can trigger the slow path.

The practical impact is availability, not confidentiality or integrity. A successful trigger can pin a CPU core and, in Node.js's single-threaded execution model, stall request processing for every other user hitting that process until the regex evaluation finally completes (or the process is killed and restarted).

Affected Versions and Components

• Affected: path-parse versions prior to 1.0.7.
• Fixed in: path-parse 1.0.7, which patched the vulnerable regular expression to avoid catastrophic backtracking.
• Exposure path: path-parse is rarely installed directly by application developers — it's almost always pulled in transitively as a dependency of other tooling (most notably resolve, which itself underpins module resolution in webpack and many other build tools). This means many organizations were exposed without path-parse ever appearing in their direct package.json, and remediation required updating upstream dependencies rather than a single package.

Because of this transitive-dependency pattern, the real-world blast radius of CVE-2021-23343 is best understood not as "who imports path-parse" but as "how deep is path-parse buried in my build and runtime dependency graph, and does any code path feed it attacker-controlled strings."

CVSS, EPSS, and KEV Context

This vulnerability is tracked publicly as CVE-2021-23343 and also carries the GitHub Security Advisory identifier GHSA-hj48-42vr-x3v9. Public advisory sources classify it as a low-to-moderate severity issue, consistent with its nature as a CPU-exhaustion/availability bug rather than a data-exposure or remote-code-execution flaw — ReDoS findings of this shape typically score in the low-to-medium CVSS range because exploitation requires the application to pass attacker-influenced strings into the vulnerable parsing function, which is not universally true of every deployment.

We have not seen evidence that CVE-2021-23343 is listed in CISA's Known Exploited Vulnerabilities (KEV) catalog, and there are no widely reported incidents of active, targeted exploitation in the wild. Its EPSS (Exploit Prediction Scoring System) probability, in line with most ReDoS findings in narrowly-scoped utility libraries, is low — these bugs are more commonly surfaced by automated dependency scanners and security researchers than by active attacker campaigns, since exploitation value is limited to a denial-of-service effect and depends heavily on how the surrounding application uses the library. That said, "low exploitation likelihood" is not the same as "no impact" — for services where availability is the primary security property (payment processing, real-time systems, high-throughput APIs), a cheap, unauthenticated CPU-exhaustion trigger is still a meaningful risk to close.

Timeline

• Root cause introduced: The vulnerable splitting regex existed in path-parse's parsing logic across its 1.0.x release line prior to the fix.
• Public disclosure: The issue was reported and published as a security advisory in 2021, cataloged as CVE-2021-23343 / GHSA-hj48-42vr-x3v9, describing the ReDoS condition in the path-splitting regular expression.
• Fix released: The maintainers shipped path-parse 1.0.7, which replaced or hardened the offending regex to eliminate the catastrophic-backtracking case.
• Ecosystem propagation: Because path-parse is a transitive dependency of tools like resolve and webpack, downstream projects needed their own dependency trees to pick up path-parse@1.0.7 (directly or via lockfile/resolution overrides) before the fix actually reached production installs — a common lag pattern for deeply nested npm dependencies.

Remediation Steps

1. Identify exposure. Run npm ls path-parse (or the equivalent for Yarn/pnpm) across your services to find every version in use, including transitive copies pulled in by different major versions of resolve, webpack, or other build tooling. A single project can end up with multiple path-parse versions installed side by side.
2. Upgrade to 1.0.7 or later. Update path-parse directly if it's a direct dependency, or update the parent packages (resolve, webpack, etc.) to versions that depend on the patched release.
3. Force resolution where needed. If an outdated path-parse is nested several layers deep behind a dependency that hasn't bumped its own requirement, use overrides (npm), resolutions (Yarn), or pnpm.overrides to pin path-parse to >=1.0.7 across the whole tree without waiting on every upstream maintainer.
4. Regenerate and commit your lockfile after the override/upgrade so the fixed version is actually installed in CI and production, not just declared in a manifest.
5. Add input validation at trust boundaries. Independent of this specific CVE, avoid passing unvalidated, attacker-controlled strings (uploaded filenames, raw URL paths, user-supplied config values) directly into path-parsing utilities without length limits or sanitization — this reduces exposure to this class of bug generally, including any similar ReDoS issues not yet discovered.
6. Verify with a dependency scanner after remediation to confirm no build artifact, container image, or serverless bundle still embeds a pre-1.0.7 copy of path-parse.

How Safeguard Helps

CVE-2021-23343 is a textbook example of why point-in-time dependency reviews aren't enough: the vulnerable package is almost never a direct dependency, so teams relying on manual audits or a one-off npm audit run can easily miss where path-parse actually lives in their build and runtime graph — especially across multiple lockfiles, monorepo packages, and container images built at different times.

Safeguard continuously maps your full software supply chain, including transitive dependencies buried behind tools like resolve and webpack, so a vulnerability like CVE-2021-23343 is surfaced with the exact file, package, and version path that introduces it — not just a name in a flat dependency list. Safeguard correlates the finding against CVSS severity, EPSS exploitation likelihood, and CISA KEV status to help you prioritize it correctly relative to the rest of your open findings, rather than treating every low-severity ReDoS the same as a critical remote-code-execution bug.

When a fix is available, Safeguard identifies the minimal safe upgrade path — including whether an overrides/resolutions pin is needed because the vulnerable package is nested behind an unpatched parent — and tracks remediation status across every repository and build artifact where the vulnerable version was detected, so you can confirm closure instead of hoping the lockfile update actually shipped everywhere it needed to.

For engineering teams, that means fewer surprises from dependencies you never explicitly chose, faster triage grounded in real exploitability signals rather than raw CVE counts, and a verifiable record that supply chain findings like CVE-2021-23343 were actually resolved — not just logged.