CVE-2025-27209: Node.js v24 DoS Vulnerability

CVE-2025-27209 Overview

A HashDoS (Hash Collision Denial of Service) vulnerability exists in Node.js v24.x due to changes in the V8 JavaScript engine's string hashing implementation. The V8 release used in Node.js v24.0.0 has switched to using rapidhash for computing string hashes, which re-introduces a hash collision vulnerability. An attacker who can control the strings being hashed can generate many hash collisions, even without knowing the hash seed, leading to severe performance degradation.

Critical Impact

Attackers can cause denial of service by forcing hash table operations to degrade from O(1) to O(n) complexity through controlled hash collisions, potentially rendering Node.js applications unresponsive.

Affected Products

• Node.js v24.x
• Applications using V8 engine with rapidhash string hashing
• Node.js servers processing user-controlled string input

Discovery Timeline

• 2025-07-18 - CVE-2025-27209 published to NVD
• 2025-11-04 - Last updated in NVD database

Technical Details for CVE-2025-27209

Vulnerability Analysis

This vulnerability is classified under CWE-407 (Inefficient Algorithmic Complexity), which describes a condition where an algorithm's worst-case computational complexity can be triggered by an attacker through crafted input. In the context of hash tables, this attack pattern is commonly known as HashDoS.

Hash tables are fundamental data structures used extensively in JavaScript engines for object property lookups, Map/Set operations, and internal runtime operations. When hash collisions occur, items that hash to the same bucket must be searched linearly, degrading performance from constant time O(1) to linear time O(n). The rapidhash implementation introduced in V8 for Node.js v24.x contains a weakness that allows attackers to predict and generate colliding strings without requiring knowledge of the hash seed.

Root Cause

The root cause lies in the rapidhash algorithm's implementation for string hashing in the V8 JavaScript engine. Traditional hash-flooding mitigations rely on randomized hash seeds to make collision generation computationally infeasible without knowing the seed. However, the rapidhash implementation used in Node.js v24.x contains properties that allow an attacker to construct colliding strings independently of the hash seed value. This effectively bypasses the standard HashDoS protections that have been in place since the original HashDoS attacks were discovered in 2011.

Attack Vector

The attack is network-accessible and requires no authentication or user interaction. An attacker can exploit this vulnerability by sending specially crafted requests containing strings designed to collide in the hash table. Common attack scenarios include:

• Submitting JSON payloads with carefully chosen property names
• Sending URL parameters or form data with colliding key names
• Providing input to any application logic that stores user-controlled strings in hash-based data structures

The attacker crafts multiple strings that, when hashed by the rapidhash algorithm, produce identical hash values. When these strings are used as keys in objects, Maps, or Sets, they force worst-case behavior in hash table operations. This can cause CPU exhaustion as the application spends excessive time resolving collisions, effectively denying service to legitimate users.

Detection Methods for CVE-2025-27209

Indicators of Compromise

• Abnormally high CPU utilization on Node.js processes without corresponding increase in legitimate traffic
• Significant increase in response latency for HTTP endpoints that process user-controlled string data
• Memory patterns showing hash table buckets with unusually long collision chains
• Requests containing large numbers of keys with similar patterns or unusual character sequences

Detection Strategies

• Monitor Node.js application response times for sudden degradation patterns that may indicate hash collision attacks
• Implement request rate limiting on endpoints that accept user-controlled string keys in JSON bodies or query parameters
• Deploy application performance monitoring (APM) tools to detect anomalous CPU spikes during request processing
• Analyze incoming request payloads for patterns consistent with known hash collision generation techniques

Monitoring Recommendations

• Configure alerting for sustained CPU utilization above baseline thresholds on Node.js application servers
• Implement logging for requests with unusually large numbers of unique keys or parameters
• Monitor garbage collection metrics as hash collision attacks may also impact memory behavior
• Track request processing times at the application layer to identify endpoints under attack

How to Mitigate CVE-2025-27209

Immediate Actions Required

• Evaluate whether your applications are running on Node.js v24.x and prioritize upgrading to patched versions
• Implement input validation to limit the number of keys accepted in JSON objects and query parameters
• Deploy rate limiting and request size restrictions at the load balancer or reverse proxy level
• Consider temporarily downgrading to a Node.js version not affected by this vulnerability if patching is not immediately available

Patch Information

Security patches addressing this vulnerability are detailed in the Node.js July 2025 Security Releases blog post. Organizations should review this advisory and apply the recommended updates for Node.js v24.x deployments. Additional discussion and technical context is available on the OpenWall OSS Security mailing list.

Workarounds

• Limit the maximum number of object keys or Map/Set entries accepted from user input
• Implement request payload size limits to reduce the impact of collision attacks
• Use alternative data structures that are not susceptible to hash collision attacks for processing untrusted input
• Deploy Web Application Firewall (WAF) rules to detect and block potential HashDoS attack patterns

# Example: Configure nginx to limit request body size and rate
# Add to nginx.conf or server block

# Limit request body size to 1MB
client_max_body_size 1m;

# Rate limiting zone definition
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;

# Apply rate limiting to API endpoints
location /api/ {
    limit_req zone=api_limit burst=20 nodelay;
    proxy_pass http://nodejs_backend;
}