How severe is GHSA-46wh-pxpv-q5gq?

GHSA-46wh-pxpv-q5gq has a CVSS score of 7.5/10, rated HIGH. Immediate patching is strongly recommended.

Which packages are affected by GHSA-46wh-pxpv-q5gq?

GHSA-46wh-pxpv-q5gq affects the following packages: express-rate-limit (npm), express-rate-limit (npm), express-rate-limit (npm). Ecosystems affected: npm.

How do I fix GHSA-46wh-pxpv-q5gq?

Update express-rate-limit to 8.2.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-46wh-pxpv-q5gq is resolved across your whole dependency graph.

How do I detect GHSA-46wh-pxpv-q5gq in my npm dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for express-rate-limit. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

How do I mitigate GHSA-46wh-pxpv-q5gq if there is no patch (or I can't update yet)?

If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

How does O3 Security protect against GHSA-46wh-pxpv-q5gq?

O3 pinpoints whether GHSA-46wh-pxpv-q5gq is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Is GHSA-46wh-pxpv-q5gq actively exploited in the wild?

No public exploit code has been indexed for GHSA-46wh-pxpv-q5gq yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

What is the EPSS score for GHSA-46wh-pxpv-q5gq?

GHSA-46wh-pxpv-q5gq has an EPSS (Exploit Prediction Scoring System) score of 0.5%, placing it in the 36th percentile of all CVEs. EPSS is maintained by FIRST.org and estimates the probability that a vulnerability will be exploited in the wild within the next 30 days. This score indicates relatively lower exploitation probability, though the CVSS severity should still guide your patching priority.

What type of vulnerability is GHSA-46wh-pxpv-q5gq?

GHSA-46wh-pxpv-q5gq is classified as CWE-770 (CWE-770). This weakness type describe the underlying flaw category, which helps determine the potential impact and the right class of mitigation.

When was GHSA-46wh-pxpv-q5gq published, and has it been updated?

GHSA-46wh-pxpv-q5gq was published on March 6, 2026 and was last updated on March 16, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

📦 npm

GHSA-46wh-pxpv-q5gq

HIGH

express-rate-limit: IPv4-mapped IPv6 addresses bypass per-client rate limiting on servers with dual-stack network

Also known asCVE-2026-30827

Published

Mar 6, 2026

Updated

Mar 16, 2026

Affected

3 pkgs

Patched

3 / 3

Exploits

None indexed

EPSS Exploitation Probability

via FIRST.org ↗

0.5%probability of exploitation in next 30 days

Lower Risk36th percentile+0.43%

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

Blast Radius

3 pkgs affected

📦express-rate-limit📦express-rate-limit📦express-rate-limit

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects npm packages — download data is not available via public APIs for these ecosystems.

Description

Summary

The default keyGenerator in express-rate-limit applies IPv6 subnet masking (/56 by default) to all addresses that net.isIPv6() returns true for. This includes IPv4-mapped IPv6 addresses (::ffff:x.x.x.x), which Node.js returns as request.ip on dual-stack servers.

Because the first 80 bits of all IPv4-mapped addresses are zero, a /56 (or any /32 to /80) subnet mask produces the same network key (::/56) for every IPv4 client. This collapses all IPv4 traffic into a single rate-limit bucket: one client exhausting the limit causes HTTP 429 for all other IPv4 clients.

Details

Root Cause

In source/ip-key-generator.ts:

export function ipKeyGenerator(ip: string, ipv6Subnet: number | false = 56) {
  if (ipv6Subnet && isIPv6(ip)) {
    return `${new Address6(`${ip}/${ipv6Subnet}`).startAddress().correctForm()}/${ipv6Subnet}`
  }
  return ip
}

net.isIPv6('::ffff:192.168.1.1') returns true, so IPv4-mapped addresses enter the subnet masking path. With a /56 prefix, the start address for any ::ffff:x.x.x.x is ::, producing the key ::/56.

Proof of Concept

const { isIPv6 } = require('net');
const { Address6 } = require('ip-address');

function ipKeyGenerator(ip, ipv6Subnet = 56) {
  if (ipv6Subnet && isIPv6(ip)) {
    return `${new Address6(`${ip}/${ipv6Subnet}`).startAddress().correctForm()}/${ipv6Subnet}`;
  }
  return ip;
}

console.log(ipKeyGenerator('::ffff:192.168.1.1', 56)); // ::/56
console.log(ipKeyGenerator('::ffff:10.0.0.1', 56));    // ::/56
console.log(ipKeyGenerator('::ffff:8.8.8.8', 56));     // ::/56
// ALL produce '::/56' — same bucket

End-to-End Validation

On a dual-stack Express server (app.listen(port, '::')), tested with Express 5.2.1:

request.ip for IPv4 clients is ::ffff:127.0.0.1
Rate limit key resolves to ::/56
After limit requests from any IPv4 client, all other IPv4 clients receive 429

When This Occurs

Node.js dual-stack servers (default on Linux when listening on ::)
Any environment where request.ip contains IPv4-mapped IPv6 addresses
Only affects the default keyGenerator (custom key generators are not affected)

Impact

Denial of Service: A single client can block all IPv4 traffic by exhausting the shared rate limit
Affects default configuration: No special options needed to trigger this

Affected Versions

All versions of express-rate-limit between v8.0.0 and v8.2.1.

Fix

This issue was fixed in commit 14e53888cdfd1b9798faf5b634c4206409e27fc4. This fix has been included in release v8.3.0, and backported to all affected minor versions in the form of releases v8.2.2, v8.1.1, and v8.0.2.

Affected Packages

3 total 3 fixed

Ecosystem	Package	Vulnerable range	Fix
📦npm	`express-rate-limit`	≥ 8.2.0&&< 8.2.2	8.2.2
📦npm	`express-rate-limit`	≥ 8.1.0&&< 8.1.1	8.1.1
📦npm	`express-rate-limit`	≥ 8.0.0&&< 8.0.2	8.0.2

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for express-rate-limit. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update express-rate-limit to 8.2.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-46wh-pxpv-q5gq is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-46wh-pxpv-q5gq is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-46wh-pxpv-q5gq. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

## Summary The default `keyGenerator` in express-rate-limit applies IPv6 subnet masking (`/56` by default) to all addresses that `net.isIPv6()` returns true for. This includes IPv4-mapped IPv6 addresses (`::ffff:x.x.x.x`), which Node.js returns as `request.ip` on dual-stack servers. Because the first 80 bits of all IPv4-mapped addresses are zero, a `/56` (or any `/32` to `/80`) subnet mask produces the same network key (`::/56`) for **every** IPv4 client. This collapses all IPv4 traffic into a single rate-limit bucket: one client exhausting the limit causes HTTP 429 for all other IPv4 client

O3 Security · Impact-Aware SCA

Is GHSA-46wh-pxpv-q5gq in your dependencies?

O3 detects GHSA-46wh-pxpv-q5gq across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works