CVE-2026-30827: Express-rate-limit DOS Vulnerability

CVE-2026-30827 Overview

CVE-2026-30827 is a Denial of Service vulnerability in express-rate-limit, a widely-used rate-limiting middleware for Express.js applications. The vulnerability stems from improper handling of IPv4-mapped IPv6 addresses in the default keyGenerator function. When the middleware applies IPv6 subnet masking (/56 by default) to IPv4-mapped addresses (::ffff:x.x.x.x), all IPv4 clients are incorrectly grouped into a single rate-limit bucket due to the shared zero-bit prefix. This allows a single malicious client to exhaust the rate limit and trigger HTTP 429 responses for all legitimate IPv4 traffic.

Critical Impact

A single attacker can cause denial of service for all IPv4 users of affected Express.js applications by exhausting the shared rate-limit bucket, resulting in legitimate users receiving HTTP 429 (Too Many Requests) responses.

Affected Products

• express-rate-limit versions 8.0.0 to 8.0.1
• express-rate-limit version 8.1.0
• express-rate-limit versions 8.2.0 to 8.2.1

Discovery Timeline

• 2026-03-07 - CVE CVE-2026-30827 published to NVD
• 2026-03-11 - Last updated in NVD database

Technical Details for CVE-2026-30827

Vulnerability Analysis

This vulnerability falls under CWE-770 (Allocation of Resources Without Limits or Throttling) and represents a Resource Exhaustion Denial of Service issue. The flaw exists in how express-rate-limit's default keyGenerator function processes client IP addresses for rate-limiting purposes.

On dual-stack servers, Node.js returns IPv4 addresses in IPv4-mapped IPv6 format (::ffff:x.x.x.x) via request.ip. The middleware's default behavior applies IPv6 subnet masking with a /56 prefix to all addresses where net.isIPv6() returns true, including these mapped addresses.

The critical issue is that the first 80 bits of all IPv4-mapped IPv6 addresses are zero (the ::ffff: prefix). When applying any subnet mask from /32 to /80, the resulting network key collapses to ::/56 for every IPv4 client. This means all IPv4 traffic shares the same rate-limit bucket, allowing a single client to exhaust the limit and block all other IPv4 users.

Root Cause

The root cause is the failure to distinguish between native IPv6 addresses and IPv4-mapped IPv6 addresses when applying subnet masking. The net.isIPv6() function returns true for IPv4-mapped addresses, causing them to receive IPv6-style subnet masking despite representing IPv4 clients. The default /56 mask is designed for IPv6 privacy addresses but is inappropriate for the zero-prefixed IPv4-mapped format.

Attack Vector

The attack vector is network-based and requires no authentication or user interaction. An attacker can exploit this vulnerability by sending a high volume of requests from a single IPv4 address to an Express.js application using a vulnerable version of express-rate-limit with default configuration.

When the attacker's requests exhaust the rate limit for the shared bucket, all subsequent requests from any IPv4 client will receive HTTP 429 (Too Many Requests) responses until the rate-limit window resets. The attack is particularly effective because it requires minimal resources from the attacker while causing widespread denial of service.

The attack flow involves:

1. Attacker identifies a target application using express-rate-limit 8.0.0 through 8.2.1
2. Attacker sends requests at a rate that exhausts the configured limit
3. All IPv4 traffic is blocked due to shared bucket exhaustion
4. Legitimate users receive HTTP 429 errors until the rate window expires

Detection Methods for CVE-2026-30827

Indicators of Compromise

• Sudden spike in HTTP 429 responses affecting multiple distinct IPv4 clients simultaneously
• Rate-limit logs showing all IPv4 traffic attributed to the same network key (::/56)
• User reports of "Too Many Requests" errors from geographically dispersed locations
• Asymmetric traffic patterns where a single source generates disproportionate load followed by widespread 429s

Detection Strategies

• Monitor application logs for anomalous HTTP 429 response patterns across multiple client IPs
• Implement alerting when rate-limit buckets are exhausted affecting more than expected unique clients
• Review express-rate-limit configuration for default keyGenerator usage on dual-stack servers
• Audit package.json and package-lock.json for vulnerable express-rate-limit versions (8.0.0 - 8.2.1)

Monitoring Recommendations

• Configure centralized logging to track rate-limit events with full client IP context
• Implement real-time dashboards showing rate-limit bucket distribution and exhaustion patterns
• Set up alerts for correlation between single-client high-volume requests and multi-client 429 responses
• Deploy application performance monitoring to detect service degradation coinciding with rate-limit events

How to Mitigate CVE-2026-30827

Immediate Actions Required

• Upgrade express-rate-limit to a patched version: 8.0.2, 8.1.1, 8.2.2, or 8.3.0
• If immediate upgrade is not possible, implement a custom keyGenerator function that properly handles IPv4-mapped addresses
• Review and test rate-limiting behavior on dual-stack server deployments
• Monitor for exploitation attempts by tracking rate-limit bucket exhaustion patterns

Patch Information

The express-rate-limit maintainers have released patched versions that correctly identify and handle IPv4-mapped IPv6 addresses. The fix ensures IPv4 clients behind mapped addresses are rate-limited independently rather than collapsed into a single bucket.

Patched versions:

• 8.0.2 for the 8.0.x branch
• 8.1.1 for the 8.1.x branch
• 8.2.2 for the 8.2.x branch
• 8.3.0 and later

The patch commit is available at the GitHub repository. For complete details, refer to the GitHub Security Advisory GHSA-46wh-pxpv-q5gq.

Workarounds

• Implement a custom keyGenerator that extracts the IPv4 address from mapped addresses before applying rate limiting
• Configure a reverse proxy to normalize client IP addresses before they reach the Express application
• Use trustProxy settings carefully and ensure consistent IP address handling across the stack
• Consider implementing additional rate-limiting at the infrastructure level (load balancer, WAF) as defense in depth

# Update to patched version
npm update express-rate-limit

# Or install specific patched version
npm install express-rate-limit@8.3.0

# Verify installed version
npm list express-rate-limit