CVE-2026-30827
Rate Limiting Bypass in express-rate-limit Causes IPv4 Traffic Collapse
Publication date: 2026-03-07
Last updated on: 2026-03-11
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| express-rate-limit_project | express-rate-limit | From 8.0.0 (inc) to 8.0.2 (exc) |
| express-rate-limit_project | express-rate-limit | From 8.2.0 (inc) to 8.2.2 (exc) |
| express-rate-limit_project | express-rate-limit | 8.1.0 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-770 | The product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-30827 is a vulnerability in the express-rate-limit npm package versions 8.0.0 through 8.2.1. The issue arises because the default keyGenerator function incorrectly handles IPv4-mapped IPv6 addresses on servers that support both IPv4 and IPv6 (dual-stack servers).
Specifically, the keyGenerator applies an IPv6 subnet mask (/56 by default) to all IP addresses identified as IPv6 by Node.js’s net.isIPv6() function. This includes IPv4-mapped IPv6 addresses, which are IPv4 addresses represented in IPv6 format (e.g., ::ffff:x.x.x.x). Because the first 80 bits of these IPv4-mapped IPv6 addresses are zero, applying the /56 subnet mask results in the same network key (::/56) for all IPv4 clients.
As a result, all IPv4 traffic is grouped into a single rate-limit bucket. This means if one IPv4 client exhausts the rate limit, all other IPv4 clients are blocked and receive HTTP 429 (Too Many Requests) errors, effectively causing a denial of service for all IPv4 users.
How can this vulnerability impact me? :
This vulnerability can cause a denial of service (DoS) condition for all IPv4 clients accessing an Express server using the vulnerable express-rate-limit versions. Because all IPv4 clients share the same rate-limit bucket, if one client exceeds the allowed number of requests, all other IPv4 clients will be blocked and receive HTTP 429 errors.
This means legitimate users may be unable to access services, leading to service disruption and degraded availability.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by observing if multiple IPv4 clients are being rate limited together, resulting in HTTP 429 errors for all IPv4 users when only one client exhausts the limit. On dual-stack servers, the request.ip value for IPv4 clients will appear as IPv4-mapped IPv6 addresses (e.g., ::ffff:x.x.x.x).
To detect this, you can check the IP addresses logged by your Express server to see if IPv4 clients are represented as IPv4-mapped IPv6 addresses. Additionally, monitoring for excessive HTTP 429 responses affecting all IPv4 clients simultaneously can indicate the issue.
There are no specific commands provided in the resources, but you can use network monitoring or logging tools to inspect request IPs and rate limiting behavior. For example, you might use commands like:
- Check server logs for request IPs in the format ::ffff:x.x.x.x
- Use tools like tcpdump or Wireshark to capture traffic and verify IP address formats
- Monitor HTTP 429 response rates to identify if many IPv4 clients are being blocked simultaneously
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation step is to upgrade the express-rate-limit package to a fixed version. The vulnerability is patched in versions 8.0.2, 8.1.1, 8.2.2, and 8.3.0.
If upgrading immediately is not possible, consider implementing a custom keyGenerator function that correctly handles IPv4-mapped IPv6 addresses by extracting the IPv4 address in dotted-decimal notation instead of applying an IPv6 subnet mask.
This prevents all IPv4 clients from being collapsed into a single rate-limit bucket and avoids denial of service caused by one client exhausting the limit.