In October 2022, a Regular Expression Denial of Service (ReDoS) vulnerability was disclosed in minimatch, one of the most widely depended-upon packages in the npm ecosystem. Tracked as CVE-2022-3517, the flaw sits in how minimatch converts glob patterns into JavaScript regular expressions. When an attacker can influence the pattern argument passed to minimatch — not just the string being matched against it — they can craft input that triggers catastrophic backtracking, pinning a Node.js event loop thread at 100% CPU and freezing the process. Because minimatch is a transitive dependency of an enormous share of the JavaScript tooling world (npm itself, glob, eslint, jest, webpack plugins, and thousands of other packages pull it in), a single unpatched copy buried three or four layers deep in a dependency tree is enough to expose an application to this issue.
What Went Wrong
minimatch's core job is deceptively simple: take a glob pattern like *.js or **/{a,b}/*.ts and turn it into a regular expression the JavaScript engine can execute against file paths or strings. The vulnerable code path lived in the pattern-to-regex conversion logic used for brace expansion and pattern parsing. Certain crafted patterns produced a regex with nested quantifiers and ambiguous matching paths — the classic ingredients of catastrophic backtracking. Feed that generated regex a moderately long, adversarial input and the regex engine's execution time grows exponentially rather than linearly, effectively hanging the thread.
The important nuance here — and the one that trips up a lot of triage — is that the dangerous input in this CVE is the pattern itself, not the string being tested. Most ReDoS advisories worry about untrusted data being matched; this one is about untrusted glob patterns being compiled in the first place. Any application, build tool, linter, or CI step that accepts user-supplied ignore rules, file filters, or glob expressions and hands them to minimatch is a candidate for this vulnerability, even if the strings it's matching against are entirely trusted.
Affected Versions and Components
The advisory (published on GitHub as GHSA-f8q6-p94x-37v3 and mirrored to NVD as CVE-2022-3517) affects minimatch versions prior to 3.0.5. The fix landed in minimatch 3.0.5, which hardened the pattern parser against the pathological regex construction. Because minimatch has shipped multiple major lines over the years (1.x, 2.x, and 3.x remain in circulation across older dependency trees, alongside the newer 5.x/9.x lines used by modern tooling), the practical exposure for any given project depends entirely on which major version — and which specific patch — is resolved in its lockfile.
This is the part that makes minimatch CVEs disproportionately painful compared to a typical library bug: minimatch is rarely a direct dependency. It's almost always pulled in transitively by glob, which is itself pulled in by dozens of build, test, and lint tools. That means a project's package.json can look completely clean while node_modules still contains three or four different vulnerable copies of minimatch installed by unrelated tools. Standard "do we depend on minimatch" checks against direct dependencies miss this entirely — you have to walk the full resolved dependency graph, including dev dependencies and nested transitive trees, to know your real exposure.
Severity: CVSS, EPSS, and KEV Status
The GitHub Security Advisory for this issue carries a CVSS 3.1 base score of 7.5 (High), reflecting a network-exploitable, low-complexity attack requiring no privileges or user interaction, with a high impact on availability and no impact on confidentiality or integrity — consistent with the denial-of-service nature of the flaw.
This CVE is not listed in CISA's Known Exploited Vulnerabilities (KEV) catalog, and it does not carry the profile of a vulnerability under active, widespread exploitation in the wild. ReDoS bugs in general tend to sit in this bracket: high theoretical severity because a single request can hang a process, but lower observed exploitation because they usually require an attacker to control a specific input path (here, a glob pattern) that many applications don't expose to untrusted users directly. That combination — high CVSS, no KEV listing — is exactly why EPSS-style exploitation-probability scoring and dependency-graph context matter as much as the raw severity number when you're deciding what to patch first. A ReDoS in a build-time tool used only on trusted CI patterns is a very different risk than the same bug reachable from an internet-facing API that accepts user-defined filters.
Timeline
- Prior to disclosure: minimatch versions before 3.0.5 ship with the vulnerable pattern-to-regex conversion logic, present in the codebase for an extended period before the issue was identified.
- October 2022: The vulnerability is disclosed and published as a GitHub Security Advisory (GHSA-f8q6-p94x-37v3), with a corresponding CVE identifier, CVE-2022-3517, assigned and mirrored into the NVD.
- Fix released: minimatch 3.0.5 ships with the corrected pattern parsing, closing the backtracking path.
- Post-disclosure: Downstream maintainers of
glob,eslint, and other high-traffic packages bump their minimatch dependency ranges over the following weeks and months, but because so many packages pin or loosely range their own dependency on minimatch, vulnerable transitive copies persist in real-worldnode_modulestrees for a long time after the fix is available — a pattern typical of deep-tree npm CVEs.
Remediation
- Identify every resolved copy of minimatch in your dependency tree, not just what's listed in
package.json. Runnpm ls minimatch(or the equivalent for your package manager) across every workspace and lockfile to surface direct and transitive installs, including those pulled in by dev dependencies and build tooling. - Upgrade to minimatch 3.0.5 or later wherever a vulnerable version is resolved. If the vulnerable copy is transitive, use your package manager's override/resolution mechanism (
overridesin npm,resolutionsin Yarn, orpnpm.overrides) to force a safe version without waiting on every upstream maintainer to bump their range. - Regenerate and commit your lockfile after applying overrides, and re-run
npm ls/npm audit(or your SCA tool of choice) to confirm no vulnerable copies remain anywhere in the tree. - Audit where glob patterns originate in your own code. If any service, CLI, or build step accepts a glob or ignore pattern from an untrusted source — user input, an uploaded config file, a webhook payload — treat that as an injection surface. Validate pattern length and complexity, or replace user-supplied patterns with an allowlist of accepted filters rather than passing raw strings straight into minimatch.
- Add regression coverage in CI that fails the build if a known-vulnerable minimatch version reappears in the resolved tree — dependency drift is how these fixes silently regress after a routine
npm installreintroduces an old transitive version.
How Safeguard Helps
CVE-2022-3517 is a textbook example of why supply chain security has to operate at the level of the resolved dependency graph, not the manifest file. Safeguard continuously scans your full node_modules tree — direct, dev, and every layer of transitive dependencies — so a vulnerable minimatch copy buried inside eslint, glob, or a build plugin four levels deep gets flagged the same way a top-level dependency would.
Beyond detection, Safeguard correlates each finding with real-world exploitation signals — CVSS severity, EPSS trend data, and KEV status — so your team can tell the difference between a high-CVSS bug with no active exploitation, like this one, and something that needs to jump the queue. For CVE-2022-3517 specifically, Safeguard's reachability analysis can help determine whether your application actually passes untrusted input into a minimatch pattern argument, turning a generic "vulnerable package present" alert into an actionable, prioritized finding.
When a fix is available, Safeguard's remediation guidance points you to the exact override or upgrade path needed to close every vulnerable instance in one pass, and ongoing monitoring catches regressions if a future install reintroduces the vulnerable version — closing the loop on exactly the kind of silent drift that let CVE-2022-3517 linger in production dependency trees long after a fix existed.