CVE-2022-25901

What it actually does

CVE-2022-25901 is a Regular Expression Denial of Service vulnerability in the cookiejar package before version 2.1.4. The vulnerable Cookie.parse function uses an inefficient regular expression that can exhibit excessive backtracking when processing specially crafted Cookie header input. Because parsing occurs during normal request handling in applications that use this library, an unauthenticated remote attacker can supply malformed cookie data and consume CPU resources, causing request latency, event-loop blocking, worker exhaustion, or service unavailability. The vulnerability affects availability only; it does not directly provide confidentiality or integrity compromise.

Why it matters to the business

Applications or services that rely on vulnerable versions of the cookiejar package may be disrupted by crafted HTTP requests containing malicious cookie values. Successful exploitation can cause degraded performance or outages without requiring authentication, which may affect customer-facing services, APIs, background integrations, and operational reliability. Although it is not listed in CISA KEV and has relatively low EPSS, public exploit availability and the low attack complexity increase practical risk for exposed web services. Organizations with many Node.js dependencies should treat this as a supply-chain hygiene issue because vulnerable transitive dependencies can remain embedded in applications long after publication.

How an attack unfolds

An attacker identifies an application or API endpoint that uses a vulnerable version of the cookiejar package to parse incoming Cookie headers or other cookie-formatted input. The attacker sends one or more HTTP requests containing a specially crafted cookie string designed to trigger catastrophic backtracking in the regular expression used by Cookie.parse. When the vulnerable parser processes the input, CPU usage spikes and the application thread or worker can become blocked for an extended period. By repeating requests or sending them concurrently, the attacker can exhaust available processing capacity, increase response times, trigger health-check failures, and potentially cause denial of service for legitimate users. No authentication or user interaction is required if the vulnerable parsing path is reachable over the network.

How to fix it

Upgrade the cookiejar package to version 2.1.4 or later wherever it is used directly or transitively. If no fixed version is pinned in application manifests, refresh lockfiles and rebuild deployments so the corrected dependency is actually packaged and shipped. Use package manager tooling such as npm audit, yarn audit, pnpm audit, npm ls cookiejar, yarn why cookiejar, or equivalent software composition analysis to find all occurrences. If immediate upgrade is not possible, reduce exposure by enforcing strict maximum Cookie header size, rejecting malformed cookie syntax at an edge proxy or application gateway, applying request-rate limits, setting per-request parsing timeouts where feasible, and isolating affected services with resource limits so parser CPU exhaustion does not impact unrelated workloads. These mitigations reduce risk but should not replace upgrading to a fixed version.

How to confirm the fix worked

Confirm that all deployed applications and build artifacts use cookiejar version 2.1.4 or later. Check package manifests and lockfiles, then verify the runtime image or deployed artifact rather than only source repositories. Run dependency scans across direct and transitive packages and ensure no vulnerable versions remain in container images, serverless bundles, or vendored dependencies. Functional validation should include sending oversized or malformed Cookie headers in a controlled test environment and confirming the service rejects them quickly without abnormal CPU spikes, event-loop stalls, worker crashes, or request timeouts. Also validate that edge controls such as header-size limits and rate limits are active where used as compensating controls.

Typical attack path

1. Identify a web application, API, or service that processes Cookie headers using the vulnerable cookiejar package.
2. Send HTTP requests with malformed or intentionally complex Cookie header values targeting the Cookie.parse code path.
3. Trigger excessive regular-expression backtracking during cookie parsing.
4. Repeat or parallelize requests to consume CPU and block event-loop or worker execution.
5. Cause degraded service, timeouts, failed health checks, autoscaling pressure, or application unavailability.

How to detect it

To assess prior exploitation, review web server, reverse proxy, CDN, WAF, load balancer, and application logs for bursts of requests containing unusually long or malformed Cookie headers, especially where those requests correlate with CPU spikes, event-loop lag, increased response latency, HTTP 408/429/500/502/503/504 responses, worker restarts, container OOM or liveness-probe failures, or autoscaling events. Focus on unauthenticated endpoints and repeated requests from the same IP address, ASN, user agent, or distributed source pattern. Application performance monitoring and runtime metrics are important because ReDoS exploitation may leave no file-system artifacts; the strongest signal is temporal correlation between suspicious Cookie header input and abnormal CPU-bound request handling. If available, inspect request bodies/headers captured by WAF or full-fidelity HTTP logging for cookie strings with excessive repeated delimiters, repeated key-value fragments, abnormal whitespace, or very large Cookie header length. There are no known product-specific malware artifacts for this vulnerability; detection should center on malicious input patterns and denial-of-service telemetry.

• Cookie header length unusually large
• Repeated malformed Cookie headers
• Cookie.parse
• HTTP 408 responses correlated with large Cookie headers
• HTTP 429 responses correlated with large Cookie headers
• HTTP 500 responses correlated with large Cookie headers
• HTTP 502 responses correlated with large Cookie headers
• HTTP 503 responses correlated with large Cookie headers
• HTTP 504 responses correlated with large Cookie headers
• upstream timed out while reading response header
• request header too large
• large_client_header_buffers
• HPE_HEADER_OVERFLOW
• event loop lag
• JavaScript heap out of memory
• npm ls cookiejar
• cookiejar@2.1.3
• cookiejar@2.1.2
• cookiejar@2.1.1
• cookiejar@2.1.0

What your security team should do

• Inventory all applications, services, container images, and serverless packages that include the cookiejar dependency.
• Prioritize remediation for internet-facing applications and APIs that parse Cookie headers from unauthenticated users.
• Upgrade cookiejar to version 2.1.4 or later and regenerate lockfiles to remove vulnerable transitive versions.
• Add dependency scanning to CI/CD and fail builds that introduce cookiejar versions before 2.1.4.
• Apply interim controls such as Cookie header size limits, malformed-header rejection, and rate limiting on exposed web endpoints.
• Monitor application CPU saturation, request latency, event-loop lag, worker restarts, and HTTP 5xx/timeout spikes for signs of attempted denial-of-service activity.
• Review access logs for repeated requests with unusually long, malformed, or high-entropy Cookie headers, especially from a small set of source IPs.
• Ensure autoscaling and resource limits are configured so one vulnerable service cannot consume shared infrastructure capacity.