The minimatch npm package is a glob-pattern matcher used almost everywhere in the JavaScript toolchain, and its main security concern is a regular expression denial of service (ReDoS) flaw fixed in version 3.0.5. If you have anything below that in your dependency tree, npm minimatch can be forced to burn CPU on a maliciously crafted pattern, and because it is a transitive dependency of so many tools, most projects carry a copy without ever installing it directly.
That ubiquity is the whole story with minimatch: you rarely choose it, but it is almost certainly there.
What minimatch does
minimatch converts glob patterns like *.js or src/**/*.ts into regular expressions and tests strings against them. It is the matching engine behind glob, and glob is the engine behind an enormous amount of tooling: test runners, bundlers, linters, file watchers, and build systems all lean on it to expand file patterns. That is why npm ls minimatch on almost any project returns a long list of parents.
Because it is so deeply embedded, a vulnerability in minimatch propagates widely and quietly. You do not get a security alert for a package you meant to install; you get one for something buried under your test framework.
The ReDoS vulnerability
The notable flaw is CVE-2022-3517, a regular expression denial of service in the braceExpand function. ReDoS happens when a regular expression can backtrack catastrophically: for certain crafted inputs, the time the regex engine spends grows exponentially with input length. An attacker who can influence the pattern passed to minimatch can supply a string that makes the process hang, consuming CPU and starving other work.
The vulnerable range is minimatch below 3.0.5, and the fix landed in version 3.0.5. The remediation is straightforward: upgrade to 3.0.5 or later. Modern major versions (5.x and up) are well clear of this issue.
The practical risk depends on whether attacker-controlled input can reach a minimatch pattern. In a build tool that only ever matches your own file paths, exploitability is low. In a service that accepts user-supplied glob patterns, it is real. Either way, the fix is cheap enough that there is no reason to leave it unpatched.
Finding vulnerable copies
Because minimatch is almost always transitive, checking your direct dependencies is not enough. List every copy and its resolved version:
npm ls minimatch
You will often see several versions coexisting, pulled in by different parents. To see why a particular vulnerable copy is present:
npm why minimatch
That tells you which parent dependency dragged in the old version, which is what you actually need to fix.
Fixing it without breaking the tree
You cannot always just npm install minimatch@latest, because the vulnerable copy belongs to a parent package that pins its own range. A few approaches, in order of preference:
-
Update the parent. If your test runner or bundler has a newer release that depends on a patched minimatch, upgrading the parent is the cleanest fix and the one that survives future installs.
-
Use an override. When you cannot update the parent quickly, force the resolved version with an override in
package.json:
{
"overrides": {
"minimatch": ">=3.0.5"
}
}
Yarn uses resolutions for the same purpose. Overrides are a stopgap; they can cause subtle incompatibilities if a parent genuinely needed old behavior, so verify your tests pass afterward.
- Audit and let npm suggest fixes:
npm audit
npm audit fix
npm audit fix will apply compatible upgrades automatically and tell you which ones need manual intervention.
Keeping deep dependencies honest
The lesson minimatch teaches is that your real attack surface is the transitive graph, not the handful of packages in your package.json. Most teams have no idea how many copies of a utility like this they ship until something forces them to look.
Continuous scanning closes that gap. An SCA tool walks the full resolved dependency tree, matches each package and version against advisory databases, and flags a vulnerable minimatch wherever it lives, including copies four levels deep that no manual review would catch. Wiring that into CI means a newly disclosed ReDoS in a transitive dependency shows up as a failed build rather than a surprise in a customer's scan. Our academy covers how to set severity thresholds so you gate on what matters without drowning in noise.
FAQ
What is the minimatch npm package used for?
minimatch converts glob patterns like *.js into regular expressions and matches file paths against them. It is the matching engine behind glob and is used transitively by most JavaScript build tools, test runners, and bundlers.
Which minimatch version fixes the ReDoS vulnerability?
Version 3.0.5 fixed CVE-2022-3517, the ReDoS flaw in the braceExpand function. Any version below 3.0.5 is affected. Upgrade to 3.0.5 or later, or use a modern major version.
Why does npm minimatch show up when I never installed it?
Because it is a transitive dependency. Tools like glob, test frameworks, and bundlers depend on it, so it enters your tree through them. Run npm why minimatch to see which parent pulled it in.
How dangerous is the minimatch ReDoS in practice?
It depends on whether attacker-controlled input can reach a minimatch pattern. In build tooling matching your own paths, risk is low. In a service accepting user-supplied glob patterns, it is a real denial-of-service vector. The fix is cheap either way, so patch it.