Glob-parent is one of those packages almost nobody installs directly but almost everybody ends up running. It sits deep in the dependency tree of file-watching tools like chokidar, and from there fans out into webpack, gulp, eslint, karma, and dozens of other build-time tools that touch millions of Node.js projects. CVE-2020-28469 describes a Regular Expression Denial of Service (ReDoS) flaw in glob-parent's internal pattern-matching logic: versions before 5.1.2 use a regular expression to detect enclosure characters (braces and brackets) in glob strings that can be forced into catastrophic backtracking when fed a specially crafted, malformed glob pattern. The practical impact is a hung or CPU-pegged process — not remote code execution or data exposure — but because glob-parent runs during build, lint, and file-watch operations, a stalled process can still disrupt CI pipelines, dev servers, and any service that resolves glob patterns from untrusted input.
This post breaks down what's actually vulnerable, how severe it is in practice, and what to do about it if glob-parent is still sitting in your lockfile.
What's affected
- Component:
glob-parent(npm package) - Vulnerable versions: All versions prior to 5.1.2
- Fixed version: 5.1.2 and later
- Root cause: An inefficient regular expression used internally to check for unbalanced or enclosing brace/bracket characters in glob strings. Certain crafted input strings cause the regex engine to backtrack exponentially, consuming CPU cycles disproportionate to input size — the classic signature of a ReDoS.
- Attack vector: Any code path that passes attacker-influenced strings into glob-parent's parsing function. Since glob-parent itself isn't typically called with raw internet input, real-world exploitability depends heavily on how the consuming application or tool exposes glob strings to untrusted sources (for example, a service that lets users submit file-matching patterns, or a build tool that processes user-supplied paths).
Because glob-parent is very rarely a direct dependency, most teams are exposed through a chain: applications depend on tools like chokidar, glob-stream, or various webpack/gulp plugins, which in turn pin or range-match an older glob-parent. This is the pattern that makes ReDoS advisories in small utility packages disproportionately noisy in dependency audits — the vulnerable code is rarely invoked directly by application logic, but it still shows up in every npm audit and SCA scan across the fleet.
Severity: CVSS, EPSS, and KEV context
NVD's entry for CVE-2020-28469 assigns a CVSS v3.1 base score in the medium range (published as 5.3), reflecting a network-exploitable, low-complexity issue whose only real consequence is availability impact — there's no confidentiality or integrity loss, and no privileges or user interaction are required to trigger it if an attacker can control the input string. That "if" is doing a lot of work: for the vast majority of real deployments, glob-parent processes developer-authored or locally-generated glob patterns, not attacker-supplied strings, which meaningfully lowers real-world exploitability even though the theoretical CVSS vector treats the input as network-reachable.
EPSS (Exploit Prediction Scoring System) data for this CVE has consistently sat at the low end of the scale, consistent with a build-time utility ReDoS rather than an internet-facing, actively-weaponized flaw. It is not listed in CISA's Known Exploited Vulnerabilities (KEV) catalog, and there are no public reports of it being exploited in the wild. In short: this is a legitimate bug worth fixing, and it will keep showing up as a finding in dependency scans, but it does not carry the urgency of an actively exploited or KEV-listed vulnerability.
That combination — real CVE, moderate CVSS, low EPSS, no KEV listing — is exactly the kind of finding that clutters vulnerability backlogs. Teams that triage purely on CVSS score end up spending remediation cycles on glob-parent before higher-risk, actively-exploited issues elsewhere in their stack, unless they have a way to layer in exploitability and reachability context.
Timeline
- Vulnerability present: The flawed regular expression existed in glob-parent's codebase across its 5.x line prior to the fix, having shipped in the package for an extended period as one of the npm ecosystem's most widely-depended-upon utility libraries.
- Public disclosure: The issue was reported and published as a GitHub Security Advisory (GHSA-ww39-953v-wcq6) in late 2020, with CVE-2020-28469 assigned to track it in the NVD.
- Fix released: The maintainers shipped a patched regular expression in glob-parent 5.1.2, closing the backtracking condition without changing the package's public API.
- Downstream propagation: Because glob-parent is a transitive dependency of chokidar and numerous file-globbing tools, downstream packages needed their own dependency bumps (or lockfile updates) to actually pull in 5.1.2, which meant the fix propagated through the ecosystem gradually rather than all at once — a common pattern for deeply-nested npm dependencies.
Remediation
- Identify exposure. Run
npm ls glob-parent(or the yarn/pnpm equivalent) across your repositories to find every version currently resolved, direct or transitive. Don't rely on top-levelpackage.json— glob-parent is almost always pulled in indirectly. - Upgrade to 5.1.2 or later. For direct dependents, bump the version constraint. For transitive dependents, update the parent package (e.g., chokidar) to a version that itself depends on a patched glob-parent, or use your package manager's override/resolution mechanism (
overridesin npm,resolutionsin yarn, orpnpm.overrides) to force the resolved version without waiting on every upstream maintainer. - Regenerate and commit lockfiles. A version bump in
package.jsonalone doesn't help ifpackage-lock.json,yarn.lock, orpnpm-lock.yamlstill pins the old resolution. Confirm the lockfile reflects 5.1.2+ after the change. - Re-scan. Re-run your SCA/dependency audit to confirm the finding clears, and check CI build tooling images (not just application repos) — build agents that install dev dependencies like gulp or webpack tooling can carry their own stale glob-parent copies.
- Assess actual reachability, not just presence. If your triage process treats every CVE hit as equally urgent, use this as an opportunity to document why moderate-CVSS, low-EPSS, non-KEV findings like this one can be scheduled into routine dependency maintenance rather than an emergency patch cycle — while still tracking them to closure.
How Safeguard Helps
CVE-2020-28469 is a good stress test for any vulnerability management program: it's real, it's everywhere, and it's easy to either over-react to (burning an incident response cycle on a build-time ReDoS) or ignore entirely (letting it sit unpatched for years because it never seems urgent). Safeguard is built to get that triage decision right automatically.
- Full transitive visibility: Safeguard builds a complete, continuously-updated SBOM across your codebases and build pipelines, so glob-parent's presence is surfaced wherever it's resolved — including nested inside chokidar, glob-stream, or CI tooling images — not just where it's a direct dependency.
- Exploitability-aware prioritization: Rather than ranking findings by CVSS alone, Safeguard enriches each CVE with EPSS trends and CISA KEV status, so a medium-severity, low-EPSS, non-KEV issue like this one is correctly triaged below actively exploited vulnerabilities in your queue — while still being tracked, not dropped.
- Reachability context: Safeguard helps distinguish dependencies that are merely present from those actually invoked with attacker-influenced input, so teams can tell the difference between "glob-parent is in our lockfile" and "glob-parent processes user-controlled strings in our service."
- Automated remediation guidance: When a fix is available — as it is here, in glob-parent 5.1.2 — Safeguard identifies the minimal safe upgrade path, including override/resolution recommendations for transitive dependencies, so teams aren't stuck waiting on every upstream maintainer to bump their own dependency graph.
- Continuous drift detection: Because transitive dependencies can silently regress (a downstream package downgrading its own pin, a new build image reintroducing an old version), Safeguard continuously re-verifies that fixed versions stay fixed across your fleet, not just at the moment of a one-time scan.
CVE-2020-28469 will likely never be an active headline vulnerability, but it's a permanent fixture in software supply chains built on the npm ecosystem. Safeguard's job is to make sure findings like this one get resolved efficiently, in proportion to their actual risk — freeing up security and engineering time for the vulnerabilities that genuinely warrant urgency.