The semver package—ubiquitous in the npm ecosystem—contained a Regular Expression Denial of Service (ReDoS) flaw that lets attackers hang or crash Node.js processes when untrusted input is parsed as a version
range, and the vulnerability is tracked as CVE-2022-25883 with fixes released in semver 5.7.2, 6.3.1, and 7.5.2.
Background
semver is the canonical semantic-version parser used across the Node.js and npm ecosystems. It is referenced (directly or transitively) by tens of thousands of packages and developer tools that need to compare, satisfy, or normalize version strings. Because of that pervasiveness, a flaw in semver can ripple widely through the supply chain, affecting both server-side applications and developer workflows.
CVE-2022-25883 was publicly disclosed in June 2023 after being reported earlier in the year. The vulnerability specifically concerns the internal handling of version
ranges in semver’s Range constructor (new Range). When untrusted user data is fed into that code path, certain crafted strings can trigger catastrophic backtracking in regular expression evaluation—consuming CPU and causing denial of service. The GitHub Advisory and national vulnerability entries list affected branches and patched versions.
Why this matters: availability, supply chain, and common usage patterns
Most developers think of semver as a benign utility for comparing versions, but that very role puts it on performance-critical code paths. Consider the following real-world contexts where semver is invoked:
- CLI tools that compute compatibility or display latest versions.
- Package managers and update-checkers triggered by HTTP requests or CI jobs.
- Server-side code that accepts user-provided version constraints (for example, API endpoints that allow querying compatible versions or performing dependency resolution).
- Tooling that scans or validates package manifests.
If any of these code paths accept user-supplied ranges and pass them directly to semver.Range (or semver.validRange, or minVersion/maxSatisfying which call into the same machinery), the application can be induced to spend an inordinate amount of CPU on regular expression matching—potentially stalling a worker process or saturating the host CPU. This is a classic availability attack; no data is exfiltrated, but services become unusable.
The vulnerability’s CVSS scores vary across CNAs and advisories (NVD lists a high score reflecting
availability impact; some vendors assessed it as moderate). Those differences reflect how exposure depends entirely on whether an application actually parses untrusted user ranges with semver. Where the dependency is present but only used for developer-controlled data, the exploitability is low; where it parses user input, the risk is real and immediate.
Technical anatomy: how new Range becomes a ReDoS vector
At the heart of this CVE is an inefficient regular expression in semver’s internal range parsing logic. Regular expressions that allow ambiguous repetition can suffer
catastrophic backtracking—an exponential blow-up in evaluation time—when given carefully crafted inputs of increasing length. That is the signature of ReDoS attacks.
semver’s Range constructor needs to parse complex range grammars (e.g., ">=1.2.3 <2.0.0 || >=3.0.0 <4.0.0"), which forces it to use non-trivial regexes to tokenize and validate the input. The faulty patterns included optional whitespace handling and grouped constructs that, when combined with attacker-supplied payloads (long runs of characters or specially structured tokens), made the regex engine explore many possible match paths, consuming CPU for each character of the malicious input. The effect is proportional to the payload length: short strings may be harmless; long or specially structured strings hang the parser.
Proof-of-concept code widely circulated during disclosure demonstrates how a simple loop that calls semver.validRange or constructs new semver.Range on progressively long inputs shows dramatic increases in elapsed time, confirming the ReDoS behavior. Exploitability is straightforward when an attacker can control a field that is parsed as a range.
Exposure model: where applications are vulnerable and where they are not
Not all semver installations are equally risky. The key exposure question is: does the application ever parse
untrusted version ranges?
- High exposure: public APIs or web applications that accept version-range parameters from remote clients, CI systems that process external manifests, and parsers that handle user-provided configuration files. In these contexts, an attacker can supply long crafted strings and cause CPU exhaustion.
- Medium exposure: background services or internal tools that parse manifests but are reachable through indirect means (malicious packages, supply-chain insertion).
- Low exposure: code paths that only parse developer-authorized or hard-coded version strings—these are typically not susceptible because the input is trusted and controlled. Many vendors that consume semver in-house validated their builds and determined they were not exploitable for this reason.
When evaluating exposure, teams must map where semver is used (direct dependencies) and where older versions are pulled transitively by other modules—because even if your package.json pins a safe semver, a transitive dependency may include an older semver in your node_modules tree. That transitive surface is how many organizations discovered they were vulnerable even after updating top-level packages.
The patch: what was changed, and which versions to adopt
Maintainers fixed the flaw by tightening the regular expression logic and changing how whitespace and range tokens are processed—preventing the ambiguous match paths that allowed catastrophic backtracking. The GitHub Advisory and the semver release notes list the patched versions:
- semver 7.x: upgrade to 7.5.2 or later
- semver 6.x: upgrade to 6.3.1 or later
- semver 5.x: upgrade to 5.7.2 or later
These are the versions that incorporate the reworked regexes and related safety checks. Upgrading to those specific patched releases is the recommended immediate remediation.
Mitigation strategies beyond simple upgrading
Upgrading is the correct action, but the real world is messier—constraints on changing transitive dependencies, legacy systems, and vendor-managed packages can delay or prevent upgrades. Here are pragmatic mitigations to reduce risk while you plan and test upgrades:
- Input validation / sanitization: refuse to accept version-range inputs longer than a conservative threshold or reject suspicious characters (very long runs of punctuation or repeated tokens). Do not assume this is a permanent fix—it's a mitigation to reduce blast radius.
- Limit parsing to trusted contexts: enforce that only authenticated, internal sources can supply version ranges to parsing endpoints. Where possible, never parse arbitrary strings from untrusted users as semver ranges.
- Timeouts and worker isolation: run untrusted parsing in a separate worker process with CPU/time limits or in a sandbox that can be killed/restarted if it hangs. This turns persistent availability issues into contained failures.
- Dependency pinning and shrinkwrapping: ensure lockfiles are up-to-date and that your CI uses
npm ci or equivalent to reproduce deterministic dependency trees, so you can track whether semver appears transitively.
- Web application rate-limiting and WAF rules: detect anomalous request sizes or content patterns and throttle or block them before they reach backend parsers.
Hard choices: backport requests and the maintenance dilemma
When semver maintainers published the fix, some organizations asked for backports to older branches because their dependency graph constrained them to older major versions. The semver maintainers' stance prioritized correctness and maintainability: backporting complex regex changes to older branches is non-trivial and risks regressions. That choice left many teams with painful options—refactor, forcefully upgrade, or implement mitigations until a full upgrade is possible. This is a recurring theme in OSS maintenance: engineering debt and API compatibility make security patches difficult to retrofit.
From a security operations perspective, the lesson is clear: critical utility libraries that live in the middle of the dependency graph must be actively managed, and organizations should favor dependency hygiene to reduce the cost of applying urgent fixes.
Detection: how to find your exposure quickly
To evaluate whether your environment is vulnerable, follow these detection steps:
- Inventory direct dependencies: scan your package.json and package-lock.json for semver and its version. If you use yarn or pnpm, inspect their lockfiles similarly.
- Scan transitive dependencies: automated tools (npm ls semver, dependency-checkers, SCA tools like Snyk/Wiz/OSS scanners) will show where older semver versions are pulled in.
- Map runtime usage: identify code paths that invoke semver.Range, semver.validRange, or any API that resolves ranges. Static analysis and runtime tracing in staging environments help to flag potentially exposed endpoints.
- Pen-test with caution: simulate ReDoS payloads only in controlled test environments. Use the known PoC patterns to observe CPU behavior, but never run exploits against production services.
Automated CI scans and SCA (software composition analysis) tools flagged CVE-2022-25883 rapidly after disclosure; many advisories and vendor bulletins referenced Snyk, GitHub, and NVD entries as part of triage workflows.
Real-world vendor responses and timeline
Multiple vendors and downstream products published advisories indicating whether their builds were exploitable and the remediation status. Some vendors concluded there was no exploitable path because they never parse untrusted ranges; others released updates or hotfixes. Operating system distributors and enterprise vendors (Ubuntu, Oracle, SUSE, IBM) incorporated the advisory into their vulnerability bulletins and applied their own scoring and remediation guidance. These vendor notices reflect the ecosystem reality: the same CVE produces different operational guidance depending on product architecture and exposure.
The public timeline shows initial disclosure in June 2023, with the fix published and merged into semver’s code base soon afterward and patched versions released on npm and recognized by the GitHub Advisory Database. Organizations that treated the advisory as high priority and applied upgrades or mitigations quickly eliminated the window for attack.
Practical remediation checklist (engineer-friendly)
- Immediate (hours)
- Run
npm ls semver or equivalent to locate instances of semver in your repositories and CI images.
- Identify any endpoints that accept version-range strings from untrusted inputs; add temporary input length checks and validation to reject suspicious payloads.
- For public-facing services, enable rate limiting to reduce the impact of scraping or abuse.
- Short-term (days)
- Update direct package.json entries to semver >= 7.5.2 (or the appropriate patched branch for your major version).
- Run a full dependency rebuild (regenerate lockfiles) and run CI tests to catch regressions from upgrades.
- Medium-term (weeks)
- For transitive dependencies that block upgrades, coordinate with the upstream maintainers or create pull requests to bump the semver dependency where feasible.
- Implement worker isolation or timeouts for expensive parsing tasks to prevent single-request CPU exhaustion.
- Long-term (months)
- Integrate SCA tooling into CI to detect such advisories automatically.
- Maintain a dependency upgrade cadence and deprecation policy to reduce future technical debt.
- Consider fuzz-testing parsing logic used in production for performance edge cases.
Monitoring and post-remediation validation
After patching, validate success with these checks:
- Confirm that lockfiles include patched versions of semver.
- Re-run the PoC datasets in a controlled environment against your updated dependency tree to ensure parsing completes within expected time bounds.
- Monitor CPU and request latency metrics for endpoints that previously parsed version ranges; look for reductions in error rates, worker restarts, or CPU spikes.
- Keep an eye on security feeds and advisories for follow-up patches, backports, or exploit sightings. The ReDoS category is actively monitored by SCA vendors and OSS communities, and new PoCs or variations can emerge.
Broader takeaways for WindowsForum readers: dependency hygiene and ReDoS as a systemic risk
CVE-2022-25883 is a textbook lesson in how seemingly small utility libraries can become systemic risks. A few pragmatic conclusions:
- Treat parsing libraries—especially those using complex regexes—as security critical. They need the same lifecycle attention as encryption or networking libraries.
- Regular expression vulnerabilities are not exotic; they are common and often overlooked. ReDoS affects availability and can be weaponized easily. Use timeouts, sandboxing, and input constraints for any code that applies regexes to untrusted data.
- Supply chain hygiene is more than "update when convenient." For high-impact packages with many dependents, establish an upgrade window and automated tracking so that when advisories like GHSA-c2qf-rxjj-qqgw surface, you can act quickly.
Risk assessment: how dangerous is CVE-2022-25883 in practice?
The danger of this CVE is proportional to two factors: whether the vulnerable API is reachable by untrusted actors, and whether the runtime environment isolates or contains runaway CPU usage.
- In a typical monolithic web server that parses untrusted input on the main thread or within worker processes without CPU limits, this vulnerability can lead to a full denial of service—either sustained while attack traffic continues, or persistent if processes become unresponsive and require manual intervention. That matches severity accounts in multiple advisories.
- Conversely, in hardened environments that place parsing in restricted workers with enforced timeouts and do not parse user-supplied ranges, the real-world risk is substantially reduced. Vendor advisories that report "no exploitable path" are typically describing this situation. Still, those conclusions depend on accurate architecture mapping, so verification is required.
Closing analysis and recommendations
CVE-2022-25883 is not a theoretical puzzle: it is a practical ReDoS with a well-understood exploit vector, patched releases, and a straightforward remediation path. The core technical fix involved reworking regex handling in semver’s range parsing and shipping patched versions across the maintained branches. That said, the incident crystallizes recurring security themes:
- Regular expressions are powerful but risky; complex grammars should be implemented defensively.
- Transitive dependencies are an operational blind spot; automated scanning must be routine.
- OSS maintainers face painful trade-offs when backporting fixes; downstream users must plan for such scenarios.
For WindowsForum readers responsible for Node.js applications or developer tooling, the actionable summary is:
- Inventory semver usage now.
- Upgrade to semver 7.5.2, 6.3.1, or 5.7.2 where appropriate.
- Add mitigations (input length checks, worker isolation, timeouts) to any service that parses external version ranges.
- Integrate SCA into CI and maintain a dependency upgrade policy to reduce future windows of exposure.
By treating parsing libraries as security-sensitive, and by operationalizing dependency hygiene, teams can reduce the probability that a minor bug in a small library turns into a major availability incident in production.
Source: MSRC
Security Update Guide - Microsoft Security Response Center