A high-severity Regular Expression Denial of Service (ReDoS) flaw in minimatch, one of the most heavily depended-upon glob-matching libraries in the npm ecosystem, allows an attacker to hang a Node.js process with a single crafted string. Tracked as CVE-2022-3517 (GHSA-f8q6-p94x-37v3), the bug lives in minimatch's brace-expansion logic and affects every release prior to 3.0.5. Because minimatch sits transitively beneath thousands of packages — glob, eslint, tar, webpack, jest, mocha, rimraf, and even parts of the npm CLI itself — the practical blast radius of this advisory is far larger than the raw CVE count suggests. For teams running CI pipelines, build tooling, or any service that resolves user-influenced file paths and ignore patterns, this is a dependency worth confirming is patched, not assumed to be.
What the vulnerability actually does
Minimatch uses brace expansion to turn glob shorthand like {a,b,c} into its fully expanded form (a, b, c) before pattern matching runs. To decide whether a given pattern needs expansion, the pre-3.0.5 code ran a regular expression against the input string. That expression contained overlapping, nested quantifiers, which means its matching time can grow exponentially rather than linearly with certain crafted inputs — the textbook definition of catastrophic backtracking.
In practice, an attacker who can get an arbitrarily long or malformed brace sequence into a call to minimatch() — or into the underlying braceExpand() helper directly — can force the JavaScript regex engine into a pathological backtracking loop. A string built from a few thousand repeated { characters with no matching closing brace, or similarly degenerate brace nesting, is enough to peg a single CPU core for seconds to minutes depending on input length and Node.js version. Since Node.js runs JavaScript on a single event-loop thread by default, one such call can stall an entire process, not just the request that triggered it.
This is a pure availability issue. There is no confidentiality or integrity impact, no code execution, and no data exposure — it's a denial-of-service primitive, and a cheap one: the "exploit" is a short, easily generated string, not a sophisticated payload.
Affected versions and components
- Vulnerable: minimatch versions prior to 3.0.5, including the widely deployed 1.x and early 3.x lines.
- Patched: minimatch 3.0.5 and all subsequent releases (the fix was carried forward into the 5.x, 6.x, and later major lines as the project moved versions).
- Transitive exposure: minimatch is a foundational dependency of
glob, which itself is embedded in an enormous share of the npm registry — linters, test runners, bundlers, task runners, and file-watching utilities. Many organizations have never installed minimatch directly, but carry a vulnerable copy several layers deep innode_modules, sometimes duplicated multiple times at different versions across the dependency graph. - Realistic attack surface: exploitation requires attacker-controlled input to reach a minimatch pattern-matching call. This is common in build-time and CI contexts (ignore-file parsing, path filtering, static-site generation) but less common in request-handling paths of production runtime services — an important distinction we come back to below.
CVSS, EPSS, and KEV context
- CVSS v3.1 Base Score: 7.5 (High) — vector
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. The score reflects a network-exploitable, low-complexity, unauthenticated availability impact with no privileges or user interaction required. - EPSS: the exploit prediction score for CVE-2022-3517 has consistently sat well below the threshold typically associated with active mass exploitation. That's consistent with the vulnerability's shape: it's a single-request DoS against a dependency that, for most consuming applications, is exercised at build time rather than on a live, internet-facing request path. High CVSS severity and low observed/predicted exploitation likelihood are not contradictory here — they describe two different questions ("how bad if triggered" vs. "how likely to be triggered against you specifically").
- CISA KEV: CVE-2022-3517 is not listed in CISA's Known Exploited Vulnerabilities catalog. There is no confirmed evidence of in-the-wild exploitation campaigns targeting this specific flaw.
The net read: this is a legitimate, fixable issue that deserves patching as part of routine dependency hygiene, but it is not the kind of finding that should trigger an emergency incident-response posture on its own — unless your reachability analysis shows attacker-controlled strings actually flow into a minimatch call in a network-facing service.
Timeline
- Introduced: the vulnerable brace-expansion regex existed in minimatch's codebase for years prior to disclosure, shipping in the 1.x and 3.x release lines that became deeply embedded across the npm dependency graph.
- October 2022: the flaw was reported and disclosed as a ReDoS in minimatch's
braceExpandhandling; a GitHub Security Advisory (GHSA-f8q6-p94x-37v3) and corresponding NVD entry (CVE-2022-3517) were published. - Fix released: minimatch 3.0.5 shipped with a rewritten, non-backtracking-prone check for brace patterns, closing the exponential-time path.
- Downstream propagation (ongoing): because minimatch is buried multiple levels deep in so many dependency trees, the patched version has propagated unevenly. Projects pinned to older lockfiles, or consuming packages that themselves haven't bumped their
glob/minimatchrequirement, can still resolve a vulnerable copy today — nearly four years after the fix shipped — simply because nobody re-ran an audit or regenerated a lockfile.
Remediation steps
- Identify every instance, not just the top-level one. Run
npm ls minimatch(or the Yarn/pnpm equivalent) to enumerate every resolved version across your dependency tree. Because minimatch is frequently duplicated at multiple versions within a singlenode_modulestree, a singlenpm updateat the root may not touch nested copies pinned by transitive dependencies. - Upgrade to minimatch ≥ 3.0.5, and prefer a current major release (9.x or later) where practical for ongoing support. Run
npm audit fixor your package manager's equivalent, and regenerate lockfiles so the fix is durable rather than a one-time local patch. - Force resolution for stubborn transitive dependencies. If an upstream package still specifies a vulnerable minimatch range, use
overrides(npm),resolutions(Yarn), orpnpm.overridesinpackage.jsonto pin a safe version across the whole tree without waiting on every maintainer to release a bump. - Re-test brace-expansion-dependent logic. The fix changes how malformed or edge-case brace patterns are parsed. Anything relying on exact
.gitignore-style pattern behavior, build-tool file filters, or test-path globs should get a quick regression pass after upgrading. - Add a guardrail for untrusted input, defense in depth. Where user-supplied strings can reach any glob-matching call — not just minimatch — consider input length caps and execution timeouts around pattern-matching operations, so a future unknown ReDoS in this class of library can't fully stall a process.
- Re-scan after remediation. Confirm via SCA tooling or a fresh SBOM diff that no other package in the tree has silently reintroduced a pre-3.0.5 minimatch through a new transitive path — this happens more often than teams expect when dependencies are updated piecemeal.
How Safeguard helps
Finding "minimatch appears in my dependency tree" is trivial; knowing whether it matters for your specific application is the harder, more valuable question — and that's where generic vulnerability scanning stops short. Safeguard's reachability analysis traces whether attacker-influenced input can actually flow into a vulnerable minimatch call path in your codebase, distinguishing a build-time linter dependency from a live, network-exposed pattern match that genuinely deserves urgent attention. Our SBOM generation and ingestion continuously maps every nested copy of minimatch across your dependency graph — including duplicates buried several layers deep — so nothing is missed between audits. Griffin AI correlates that exposure against your runtime and code context to prioritize this finding relative to everything else competing for your team's attention, rather than surfacing it as an isolated CVSS number. When remediation is warranted, Safeguard opens an auto-fix pull request that bumps or overrides the vulnerable minimatch version directly in your manifest and lockfile, so the fix ships as a reviewable diff instead of a manual chase through node_modules.