The glob npm package is one of the most-installed modules in the Node ecosystem — over 360 million downloads a week — and in November 2025 it was assigned CVE-2025-64756, a command-injection flaw in its command-line interface that made countless projects light up red overnight. If your CI suddenly reported a vulnerable glob you did not remember adding, this is almost certainly why, and the fix is more nuanced than "bump the version." Here is what actually happened.
What glob does and why it is everywhere
glob matches file paths against shell-style wildcard patterns — src/**/*.js, test/*.spec.ts, and so on. It is the pattern-matching engine underneath build tools, test runners, and any script that walks a directory tree. Because Webpack, Gulp, dozens of CLIs, and countless internal scripts depend on it directly or transitively, npm glob shows up in nearly every node_modules folder in existence. That ubiquity is exactly why a single advisory rippled so far.
Most projects never install glob on purpose. It arrives as a transitive dependency several layers down, which is why so many teams were surprised to find it in their tree at all.
What CVE-2025-64756 actually is
CVE-2025-64756 is a command-injection vulnerability in the glob CLI, specifically the -c / --cmd option. That flag lets you run a shell command for each file a pattern matches — handy for one-liners like running a formatter over every matched file.
The problem: in vulnerable versions the CLI passed matched filenames into a shell with shell: true enabled. A filename crafted to contain shell metacharacters could therefore break out and execute arbitrary commands. If an attacker could influence filenames in a directory that someone then globbed with --cmd, they could get code execution in that context.
Per the published advisory, the affected range is glob 10.3.7 through 11.0.3, and the maintainer shipped the fix in 11.1.0. The vulnerability lives in the command-line surface, not in the programmatic API that build tools call — a distinction that matters enormously for triage, as we will see.
Why "critical everywhere" was mostly noise
Here is the part that caused the most confusion. Because glob is a transitive dependency of almost everything, version-based scanners flagged it as a critical finding across huge numbers of projects the moment the advisory landed. But the vulnerable code path is the CLI's --cmd option. The overwhelming majority of projects use glob programmatically — they import it and call its functions — and never invoke the CLI with --cmd at all.
For those projects the practical exploitability is effectively nil, even though the scanner shows critical. This is the textbook case for reachability analysis: a version match tells you the vulnerable package is present, but only reachability tells you whether the vulnerable function is on a path your code can actually reach. An SCA tool such as Safeguard that models reachability will de-prioritize a glob finding when nothing in your project touches the CLI command path — which is the difference between a two-minute triage and a frantic all-hands patch. You can see the same reasoning applied to other ecosystems in our npm security best practices guide.
None of this means you should ignore it. It means you should fix it calmly rather than treating every transitive glob as an active breach.
How to remediate
Remediation depends on how glob got into your tree.
If you depend on glob directly, bump it. The patched line starts at 11.1.0, and the package has since moved on — the current major line is 13.x, which also cleared out older ReDoS-class concerns. Update and re-lock:
npm install glob@latest
npm ls glob # confirm no old versions remain
If glob is transitive, the version you get is dictated by whatever depends on it. Check what is pulling it in:
npm ls glob
If the parent package has released a version that requires the patched glob, updating the parent is the clean fix. When the parent lags, you have two levers. With npm you can force resolution with an overrides block in package.json:
{
"overrides": {
"glob": ">=11.1.0"
}
}
Yarn offers resolutions for the same purpose. Overrides are effective but blunt — you are overriding what a dependency asked for, so run your test suite afterward to make sure the parent still works against the newer glob.
If you genuinely do not use the CLI, and cannot easily upgrade, the practical exposure is low. Document that reasoning, suppress the finding with a note referencing CVE-2025-64756, and schedule the upgrade rather than firefighting it. Deprecated and unpatched glob versions accumulate other issues over time, so "low urgency" is not "never."
Preventing the next glob moment
This will happen again with the next foundational package. The durable defenses are the same ones that made this incident manageable for teams that had them:
- Reachability-aware scanning so a critical-by-version transitive finding gets triaged by whether your code can reach the flaw, not just by its presence.
- A live SBOM so you can answer "where is glob in our tree, and at what version" in seconds instead of grepping lockfiles.
npm ciin CI against a committed lockfile so builds are reproducible and a resolution can be verified before it ships.
Teams with those three in place spent an afternoon on CVE-2025-64756. Teams without them spent a week.
FAQ
Which glob versions are affected by CVE-2025-64756?
Versions 10.3.7 through 11.0.3 of the glob npm package are affected. The command-injection fix shipped in version 11.1.0, and later major lines (through 13.x) are unaffected.
Is my project actually exploitable if it uses glob?
Only if you invoke the glob CLI with the -c/--cmd option on filenames an attacker can influence. Projects that use glob programmatically through its API do not touch the vulnerable code path, so real-world exploitability for them is very low despite the critical severity label.
How do I fix a transitive glob dependency?
First run npm ls glob to find the parent. Update the parent if it now requires a patched glob; otherwise force the version with an overrides block (npm) or resolutions (Yarn) pinning glob to >=11.1.0, then re-run your tests to confirm the parent still works.
Why did every Node project suddenly show a vulnerable glob?
Because glob is a transitive dependency of an enormous share of the npm ecosystem, and version-based scanners flag any project containing an affected version regardless of whether the vulnerable CLI path is reachable. Most of those alerts are present-but-not-exploitable.