A single crafty HTTP request can knock your Node.js server offline, and the culprit is a regular expression tucked inside a library you might not even know you’re using. In January 2023, security researchers disclosed CVE-2022-25881, a denial-of-service vulnerability in http-cache-semantics, a package that helps applications decide whether to cache web content. The fix is a one-line version bump to 4.1.1, but because the library is pulled into thousands of projects as a transitive dependency, cleaning it up demands more than a quick npm update—it requires a supply chain scavenger hunt that can leave services exposed for months.

The Flaw at a Glance

http-cache-semantics is a Node.js package that reads HTTP headers like Cache-Control and Pragma to figure out caching policies. It sits inside many popular HTTP clients and proxies, quietly making decisions about what content to reuse. The problem is in the regular expression it uses to parse incoming header values. Under normal conditions, the regex hums along. But an attacker who sends a header with a long pattern of repeating characters and a mismatched ending can trigger “catastrophic backtracking”—a behavior where the regex engine explores an exponential number of possibilities before failing. A single malicious request can spike CPU usage to 100% and hang the Node.js event loop, effectively denying service to all other users.

Microsoft’s advisory on the issue describes the result as “total loss of availability”—either sustained while the attacker keeps sending crafted packets, or persistent if the service craters until it’s restarted. No data leaks out, and nobody gains remote code execution, but for public-facing APIs, login endpoints, or microservices that depend on real‑time responses, an availability hit is a business outage.

Your Exposure Is Probably Deeper Than You Think

http-cache-semantics is not a package most developers install directly. Instead, it’s a dependency of higher-level tools like make-fetch-happen, certain versions of undici, and various caching-proxy libraries. That means the vulnerability can sneak into your project through a third‑party package you trust.

When you run npm install, yarn, or a container build, the affected code lands in your node_modules folder and may get executed whenever your application processes incoming request headers—even before authentication checks. The attack requires no credentials: a remote user simply sends a malformed header to any endpoint that constructs a CachePolicy object from request headers. In a typical Node.js cluster or cloud function setup, one CPU‑bound process can cascade into front‑end timeouts and load balancer retries, multiplying the damage.

Home users who run a personal web server, a development VM, or a self‑hosted application like a bookmark manager or a wiki are unlikely to be targeted on purpose, but a bot scanning the internet for the vulnerability could still stumble into them. For enterprise administrators, the risk is acute: a single unpatched service can become the weakest link that an attacker uses to degrade a whole platform.

How a Single Malicious Header Can Crash Your Server

To understand why a regex can be so dangerous, imagine a pattern that tries to match an opening bracket, some characters, and then a closing bracket. If it encounters a long string of brackets without a proper match, the engine tries every possible way to group the characters, doubling the number of attempts each time. After just a few dozen characters, the processing time explodes into seconds or minutes.

In the case of http-cache-semantics, the problematic expression parses a Cache-Control header that looks something like this:

Cache-Control: public, max-age=3600

An attacker can replace the legitimate value with a long string of spaces or repeated commas followed by a non‑matching character. The library’s regex starts to backtrack, and the single request consumes 100% of a CPU core for an extended period. Send a handful of these requests in parallel, and a server with even modest hardware will become unresponsive.

Security researchers at Snyk published a proof‑of‑concept script that measures the time it takes to construct a CachePolicy object as the input string grows. The timing graph shows a sharp upward curve, confirming the exponential behavior. If you run a vulnerable server and can reproduce the test, you’ll see your process monitor spike the moment the poisoned request arrives.

The Patching Paradox: Easy Fix, Hard Rollout

Upstream, the vulnerability is fixed in http-cache-semantics version 4.1.1. The maintainer replaced the greedy regex with a safer alternative and added unit tests to prevent a regression. For a developer who controls a single project, the remedy is straightforward:

  1. Find where the library is used (npm ls http-cache-semantics or search your lockfile).
  2. Upgrade the direct parent package if the author has already released a compatible version.
  3. If a parent package hasn’t been updated, use npm-force-resolutions, yarn’s resolutions field, or an overrides block in package.json to pin the transitive dependency to 4.1.1.
  4. Rebuild and redeploy.

But in a corporate environment, things get messy. The library might be buried inside a container image provided by a vendor, or bundled into an appliance where you can’t easily patch the internals. Microsoft, IBM, SUSE, Oracle, and others have released their own advisories because http-cache-semantics appears inside their products. Until each vendor ships an updated image or patch, your service remains vulnerable even if your own code is clean.

For administrators who can’t upgrade immediately, compensating controls can cut the risk:

  • WAF / reverse proxy rules: Limit Cache-Control header length to a sensible maximum (many legitimate headers stay below 1,024 characters). Block values that contain long runs of repeated characters.
  • Rate limiting: Throttle the number of requests per IP, especially those that exercise caching paths. This doesn’t stop the first attack attempt but prevents sustained CPU drain.
  • Input validation at the application edge: Have your web framework filter headers before they reach downstream caching logic. Reject any header that exceeds a length limit or matches a suspicious pattern.
  • Process isolation: Run Node.js workers with separate CPU quotas so a single compromised process can’t starve the entire server. Tools like cluster, pm2, or container orchestration can contain the blast radius.

No WAF rule is a perfect substitute for patching, but these measures buy time while you coordinate with vendors and schedule a maintenance window.

A Timeline of Disclosure

The story began in late January 2023, when the vulnerability was reported to the http-cache-semantics maintainer and assigned CVE-2022-25881. Within days, version 4.1.1 was released with the fix. Advisories from Snyk and the National Vulnerability Database appeared shortly after, flagging it as a high‑severity availability risk. By early February, major Linux distributions and enterprise vendors had published their own bulletins.

Microsoft’s own advisory, which we reference here, emphasizes the “total loss of availability” that could be sustained or persistent. The company updated its guidance to reflect the severity and continues to recommend upgrading as the primary mitigation.

Despite the early fix, the transitive nature of the dependency means that many projects and products are still dragging around a vulnerable version. Automatic dependency scanners like GitHub’s Dependabot, Snyk, and OWASP Dependency‑Check will flag the issue if you run them against your codebase or container images—provided someone on the team pays attention to the alerts.

Your Remediation Playbook

For developers:
- Run npm audit or yarn audit from your project root. If the report flags http-cache-semantics with a high severity, check your package-lock.json or yarn.lock to see which top‑level dependency pulled it in.
- If a direct parent package has a newer version that depends on http-cache-semantics ≥4.1.1, upgrade that parent. For example, some versions of make-fetch-happen already shipped the fix.
- If no upgrade is available, use your package manager’s override mechanism to force the fixed version. For npm >=8.3.0, add an overrides block to package.json:
json "overrides": { "http-cache-semantics": "4.1.1" }
- After updating, verify the fix by running a test that sends a malformed header and watching CPU usage. Snyk’s PoC can be adapted for this purpose.

For system administrators and SREs:
- Scan your container registries and production images for the vulnerable library. Most SCA tools will flag it—don’t mute the alert just because it’s a transitive dependency.
- Prioritize internet‑facing services first. Internal tools that only accept authenticated traffic are lower risk, but they can still be abused by an attacker who has a foothold inside your network.
- If you rely on a vendor‑supplied appliance or image that bundles Node.js components, check the vendor’s security portal. IBM’s Product Security Incident Response Team, for instance, listed affected Cloud Pak for Data components and provided patches. Apply those as soon as they’re available.
- While waiting for a vendor patch, deploy network‑layer protections: shorten header length limits on your load balancer, set rate limits on caching endpoints, and monitor CPU metrics for any node that processes HTTP requests.

For everyone:
- Treat CVE-2022-25881 as a canary for your overall dependency management. The library is small; if a similarly obscure package with a ReDoS bug enters your stack tomorrow, your detection process should catch it quickly. Automate vulnerability scanning in your CI/CD pipeline so you never release code with known critical‑ and high‑severity flaws.

Staying Ahead of Regex Risks

ReDoS vulnerabilities are stubborn because they hide in the parsing logic that processes untrusted input. They’re often missed by static analysis tools and only appear when a creative tester—or attacker—crafts the right input. The http-cache-semantics fix shows the pattern: a well‑intentioned regular expression, a missing anchor or greedy quantifier, and suddenly a network‑exposed service is vulnerable.

Going forward, developers can adopt a few habits that raise the bar:

  • When writing your own regexes, use tools like rxxr2 or the ESLint no-regex-spaces and security/detect-unsafe-regex plugins to catch potentially exponential complexity.
  • Prefer non‑backtracking regex engines (e.g., re2 for Node.js) when processing untrusted input, especially in performance‑sensitive paths.
  • Fuzz your HTTP parsing code. A simple fuzzer that throws random header strings at your caching layer can uncover ReDoS conditions before they ship.

The next headline about a ReDoS flaw in a ubiquitous Node.js package is probably already in the works. What makes today’s story different is how you respond: don’t let a version bump sit in your backlog while a single bad request can knock you offline.