CVE-2022-2596

What it actually does

The vulnerability stems from an inefficient regular expression in node-fetch that is susceptible to catastrophic backtracking, allowing remote attackers to supply specially crafted input (such as URLs or response data) that consumes excessive CPU resources and results in denial of service.

Why it matters to the business

Applications relying on node-fetch for outbound requests can experience sudden slowdowns or outages, disrupting dependent services and increasing operational costs until the affected processes are restarted or mitigated.

How an attack unfolds

An attacker identifies an application using a vulnerable version of node-fetch, crafts a malicious input designed to trigger exponential regex backtracking (commonly via a crafted URL or header), and sends it through the fetch call to exhaust server CPU without authentication.

How to fix it

Upgrade node-fetch to a fixed version containing commit 28802387292baee467e042e168d92597b5bbbe3d (equivalent to 3.2.10 or later). Pin dependencies to the patched release and re-test all code paths that invoke fetch.

How to confirm the fix worked

Review package.json or lockfiles for node-fetch versions older than the fixed commit; run unit tests with known ReDoS payloads to confirm absence of excessive CPU; monitor process resource usage under load after upgrade.

Typical attack path

1. Identify a target application that imports node-fetch for HTTP requests
2. Craft a payload containing input that forces catastrophic backtracking in the vulnerable regex
3. Deliver the payload through a fetch invocation (URL, redirect, or response handling)
4. Observe sustained high CPU usage leading to service degradation or crash

How to detect it

Review application and system logs for sudden spikes in CPU utilization correlated with fetch-related requests; inspect process dumps or performance profiles for regex execution time; search web server access logs for anomalous URL patterns that could trigger backtracking.

What your security team should do

• Immediately audit all projects for use of node-fetch < 3.2.10 and schedule upgrades
• Implement input validation or timeouts around fetch calls as a temporary control
• Add dependency scanning to CI pipelines to block future vulnerable versions
• Monitor for unusual CPU spikes on servers handling outbound HTTP requests