CVE-2022-25883: ReDoS in semver package

CVE-2022-25883 is a regular expression denial of service (ReDoS) vulnerability in semver, the version-parsing library that underpins nearly every corner of the JavaScript ecosystem — from the npm CLI itself to build tools, linters, and framework CLIs that need to compare or satisfy version ranges. An attacker who can get a crafted version string or range into a call to a vulnerable semver function can trigger catastrophic backtracking in the library's internal regular expressions, pegging a CPU core and freezing the single-threaded Node.js event loop for the process that called it. Because semver is almost never a direct, visible dependency — it's buried three, four, or five levels deep in most node_modules trees — this is a textbook example of a transitive supply chain risk: the vulnerable code ships into production without most teams ever having chosen to depend on it directly.

What the vulnerability actually does

semver (also published as node-semver) uses a set of regular expressions to tokenize and validate version strings like 1.2.3-beta.1 and range expressions like >=1.2.3 <2.0.0. Some of those regexes were constructed in a way that allowed pathological, attacker-supplied input — long strings with specific repeating patterns of whitespace and version-like tokens — to force the regex engine into exponential backtracking rather than linear-time matching. A single malicious string passed to functions such as new Range() or satisfies() could take an application from parsing in microseconds to hanging for seconds or longer, without needing authentication, elevated privileges, or any user interaction beyond the application accepting attacker-influenced input into a version comparison.

The practical impact is availability, not confidentiality or integrity: this is a denial-of-service bug. Any Node.js service that parses semver ranges or versions coming from an untrusted source — a package manifest fetched from a third party, a query parameter, a webhook payload, a plugin configuration — is a candidate for abuse if it's running a vulnerable semver version.

Affected versions and components

The vulnerability affects semver (npm package semver) prior to the version that shipped the fix, 7.5.2. Because semver has been published across multiple active major lines (5.x, 6.x, and 7.x) for years, and because so many other widely-used packages pin or transitively require older semver ranges, the practical blast radius extends well beyond anyone who typed npm install semver directly. It's a dependency of the npm CLI itself, of node-gyp, and of a long tail of build, lint, and tooling packages that resolve or validate version ranges as part of their normal operation. In most real-world audits, organizations find several different semver versions coexisting in a single node_modules tree — some patched, some not — because npm's dependency resolution does not automatically de-duplicate or upgrade nested copies unless a lockfile refresh or npm dedupe forces it.

If your project or its dependencies pin semver below 7.5.2 anywhere in the tree, you are exposed to this issue in any code path that hands that copy of the library a string an attacker can influence.

CVSS, EPSS, and KEV context

The advisory tracking this issue (GitHub Security Advisory GHSA-c2qf-rxjj-qqgw) is scored under CVSS v3.1 as a High-severity, availability-only issue — network-exploitable, low attack complexity, no privileges or user interaction required, with impact limited to availability rather than confidentiality or integrity. That scoring pattern is typical for ReDoS bugs: the "blast radius" is real (a process can be hung), but there's no data exposure or code execution on its own.

CVE-2022-25883 is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog as of this writing, and there is no public evidence of active, widespread exploitation in the wild. As with any ReDoS finding, its real-world EPSS (Exploit Prediction Scoring System) probability tends to run low relative to remote-code-execution bugs, since exploitation requires a specific, somewhat narrow condition: an attacker-controlled string reaching a vulnerable semver parsing call. That said, EPSS and KEV status are point-in-time signals, not guarantees — teams should check current values directly against FIRST.org and CISA's KEV feed rather than relying on a snapshot, since scores shift as researchers publish new exploitation research or proof-of-concept payloads.

The practical takeaway: this is not a bug to treat as an emergency all-hands page, but it is also not one to leave unpatched indefinitely, especially in any service that exposes version-string parsing to untrusted input — for example, a registry proxy, a dependency-analysis tool, or a CI system that ingests third-party manifests.

Timeline

• 2022 — A CVE identifier (CVE-2022-25883) was reserved for the semver ReDoS issue as part of the coordinated disclosure process, ahead of a public fix.
• June 2023 — The GitHub Security Advisory (GHSA-c2qf-rxjj-qqgw) was published publicly, disclosing the technical details of the regex-based denial-of-service condition and its scope across semver's parsing functions.
• June 2023 — semver 7.5.2 was released, hardening the vulnerable regular expressions and adding input-length safeguards to reduce the practical attack surface for pathological inputs.
• Following disclosure — Downstream projects, including the npm CLI and a wide range of build and tooling packages, began bumping their semver dependency to the patched line, though — as with most transitive dependency fixes — adoption across the broader ecosystem lagged the actual patch release by months in many codebases.

If you maintain a project with a long-lived lockfile, it is worth explicitly checking whether that lag applies to you rather than assuming a routine npm install picked up the fix automatically.

Remediation steps

1. Upgrade semver to 7.5.2 or later wherever it appears in your dependency tree, not just at the top level. Run npm ls semver or yarn why semver to enumerate every resolved copy and its requesting parent, since nested, out-of-date copies are the most common way this vulnerability survives a routine top-level update.
2. Regenerate your lockfile (package-lock.json, yarn.lock, or pnpm-lock.yaml) after upgrading, and confirm via a fresh npm ls/yarn why pass that no vulnerable version remains resolvable anywhere in the tree.
3. Check pinned or vendored copies. If any internal tooling vendors semver directly, bundles it into a Docker image layer, or pins an old major version (5.x or 6.x) for compatibility reasons, verify a patched release exists on that line or plan a migration to the current major.
4. Add defense in depth at the input boundary. If your application passes externally-influenced strings into semver.satisfies(), new Range(), or similar functions, apply a reasonable length cap and basic format validation before those strings ever reach the parser — regardless of the library version — so a future regex-based issue in any dependency doesn't have a direct path to your process.
5. Re-scan after remediation. Run your SCA/dependency-scanning tooling again post-upgrade to confirm the finding clears, including in any container images or build artifacts that may cache an older node_modules snapshot separately from your source repository.

How Safeguard helps

CVE-2022-25883 is a useful illustration of why supply chain security has to look past an organization's direct dependency list. semver is rarely something a team chooses — it arrives nested inside a dozen other packages, and the same repository can easily carry three or four different versions of it at once, some fixed and some not. Safeguard is built for exactly that kind of resolution problem.

Safeguard continuously generates and maintains an accurate software bill of materials (SBOM) across your full dependency graph — direct and transitive — so a finding like this one surfaces against every actual copy of semver in your build, not just the version pinned in your top-level manifest. Our scanning pipeline correlates known vulnerabilities like CVE-2022-25883 against that live SBOM, factoring in CVSS severity, current EPSS exploitation probability, and CISA KEV status so your team can prioritize the handful of findings that matter over the hundreds that don't.

Beyond detection, Safeguard's CI/CD policy gates let you block a build or pull request from merging when it would introduce a known-vulnerable dependency version, and our remediation guidance points directly at the patched release and the specific manifest or lockfile entries that need to change — turning a multi-hour dependency-tree archaeology exercise into a scoped, verifiable fix. For ReDoS-class issues in particular, where exploitability depends on whether untrusted input actually reaches the vulnerable code path, Safeguard's reachability analysis helps distinguish theoretical exposure from real risk, so security and engineering teams can spend their remediation effort where it actually reduces attack surface.