CVE-2022-25881

What it actually does

CVE-2022-25881 is a denial-of-service vulnerability in the Node.js http-cache-semantics package before version 4.1.1. When an application uses this library to evaluate cache policy from attacker-controlled HTTP request headers, specially crafted header values can trigger excessive processing in the library’s header parsing logic. Because the vulnerability is remotely reachable, requires no authentication, and can consume server CPU/event-loop capacity, it can degrade or halt request handling for affected services.

Why it matters to the business

Public-facing Node.js services that depend on vulnerable versions of http-cache-semantics may be taken offline or made unreliable by a small volume of malicious HTTP requests. The CVSS score is high for availability impact, public exploit information exists, and the package is commonly pulled in transitively through other JavaScript dependencies, so organizations should treat this as a practical service-disruption risk even though it is not listed in CISA KEV and is not known to be used in ransomware campaigns.

How an attack unfolds

An attacker identifies a web service or API that processes inbound HTTP requests using a vulnerable version of http-cache-semantics. The attacker sends crafted HTTP requests containing malicious cache-related header values, such as Cache-Control-style input designed to exercise inefficient parsing behavior. When the server passes those headers into the library to construct or evaluate a cache policy, the parser can consume disproportionate CPU time. Repeating the request or sending it concurrently can block the Node.js event loop, slow responses, exhaust worker capacity, and produce an application-level denial of service without requiring credentials or user interaction.

How to fix it

Upgrade http-cache-semantics to version 4.1.1 or later wherever it is present, including transitive dependency paths. For npm/yarn/pnpm projects, refresh lockfiles after upgrading and verify the resolved installed version is not below 4.1.1. If a direct upgrade is not immediately possible, use package-manager overrides/resolutions to force http-cache-semantics >=4.1.1, then run application tests to confirm compatibility. As compensating controls, reject or cap excessively long request header values, enforce web server and reverse proxy header-size limits, rate-limit suspicious clients, and ensure Node.js services have request timeouts and worker isolation to reduce denial-of-service blast radius.

How to confirm the fix worked

Confirm the deployed dependency tree resolves http-cache-semantics to 4.1.1 or later using tools such as npm ls http-cache-semantics, yarn why http-cache-semantics, pnpm why http-cache-semantics, npm audit, SCA tooling, SBOM scans, and container image scans. Inspect package-lock.json, yarn.lock, pnpm-lock.yaml, and bundled node_modules contents for versions below 4.1.1. Validate that edge proxies and application servers enforce maximum header sizes and request timeouts. In staging, safely test malformed or oversized cache-related headers and verify the service rejects them quickly rather than showing high CPU, event-loop blocking, or request timeout behavior.

Typical attack path

1. Identify a Node.js application, proxy, API gateway, SSR service, or caching middleware that may evaluate client-supplied HTTP cache headers.
2. Send probing requests with unusual or oversized cache-related request headers to observe latency, timeout, or CPU behavior.
3. Deliver crafted malicious header values that trigger excessive parsing in vulnerable http-cache-semantics versions.
4. Repeat or parallelize requests to monopolize the Node.js event loop or worker processes.
5. Cause degraded response times, request timeouts, health-check failures, autoscaling events, or service unavailability.

How to detect it

To determine whether this was already exploited, review HTTP access logs, load balancer logs, WAF logs, API gateway logs, and application logs for requests containing unusually long, malformed, or repetitive cache-related headers followed by elevated response latency, upstream timeouts, 502/503/504 responses, process restarts, or high CPU. Correlate suspicious requests with Node.js runtime telemetry such as event-loop lag, worker saturation, container CPU throttling, autoscaling activity, and health-check failures. Because this is a denial-of-service issue, successful exploitation may not leave a persistent file artifact; the strongest evidence is temporal correlation between crafted request headers and service degradation. Also inspect dependency manifests and deployed artifacts for vulnerable versions to distinguish exposure from confirmed exploitation.

• node_modules/http-cache-semantics/package.json
• "http-cache-semantics"
• http-cache-semantics@4.0
• http-cache-semantics@4.1.0
• Cache-Control:
• Pragma:
• Age:
• Expires:
• upstream timed out
• request timed out
• HTTP 503
• HTTP 504
• event loop lag
• JavaScript heap out of memory

What your security team should do

• Prioritize upgrading or overriding http-cache-semantics to version 4.1.1 or later in all JavaScript/Node.js applications and container images.
• Search source repositories, lockfiles, SBOMs, and artifact registries for vulnerable transitive dependency paths because the package may not be declared directly.
• Apply or verify HTTP request header length limits at reverse proxies, load balancers, API gateways, and application frameworks.
• Add monitoring for sudden spikes in 4xx/5xx responses, request latency, Node.js CPU saturation, event-loop lag, and repeated requests with abnormal cache-related headers.
• Review web access logs and application logs for historical latency spikes correlated with unusual Cache-Control, Pragma, Age, Expires, or other cache-policy headers.
• If exploitation is suspected, preserve access logs, application logs, process metrics, container metrics, and load balancer telemetry before restarting or redeploying services.