@fastify/rate-limit before 11

CVE-2026-15144 affects @fastify/rate-limit versions prior to 11.2.0. The plugin's default keyGenerator uses the verbatim string from request.ip as the rate-limit bucket key. This creates two bypass vectors: (1) IPv6 prefix rotation — a standard residential or cloud IPv6 allocation gives an attacker a /64 block containing 2^64 unique addresses, each minting a fresh rate-limit bucket; and (2) representation aliasing — the same IPv6 address can be expressed in compressed (::1), expanded (0000:0000:…:0001), mixed-case, or IPv4-mapped (::ffff:10.0.0.1) forms, each treated as a distinct key. The fix in 11.2.0 introduces a normalizeIP() function and a configurable ipv6Subnet option (default /64) that canonicalizes addresses before keying. All applications using @fastify/rate-limit <11.2.0 behind IPv6-capable proxies (Cloudflare, AWS ALB, GCP LB, Vercel, Fly.io, Render, Railway) are in scope.

The vendor's HIGH 7.3 rating overweights the theoretical ceiling. The CVSS vector itself (C:L/I:L/A:L) correctly rates every impact dimension as *Low* — the 7.3 is inflated by the ease-of-reach metrics (network-accessible, no auth, no interaction). In practice, this vulnerability weakens a defense-in-depth control rather than directly achieving compromise. An attacker who bypasses the rate limit still needs to chain it with brute-force, credential stuffing, or volumetric abuse against an endpoint that *also* lacks MFA, account lockout, or CAPTCHA. Most enterprise-grade deployments of Fastify behind WAFs or API gateways already enforce rate limits upstream of the application layer, further reducing real-world exposure. A MEDIUM reassessment better reflects the actual blast radius.

Why this verdict

• Defense-in-depth weakening, not direct compromise: The vulnerability disables one layer (rate limiting) but leaves MFA, account lockout, CAPTCHA, and upstream WAF rate limits intact. An attacker who bypasses the Fastify rate limiter has *permission to try harder* — not permission to succeed.
• IPv6 connectivity is a prerequisite that narrows exposure: Many enterprise API deployments sit behind IPv4-only internal load balancers or CDNs that canonicalize addresses upstream. The attack requires the attacker to have a routable IPv6 prefix *and* for the target to pass raw IPv6 through to Fastify — a conjunction that excludes a significant fraction of deployments.
• Vendor's own CIA ratings are all Low: The CVSS vector explicitly rates confidentiality, integrity, and availability impact as Low. The 7.3 score is inflated by the frictionless attack-reach metrics (AV:N/AC:L/PR:N/UI:N). In a friction-adjusted model, the Low/Low/Low impact ceiling pulls the real-world severity into MEDIUM territory.
• Role multiplier: @fastify/rate-limit is application-tier middleware deployed in Node.js web servers and API services. It is *not* a canonical high-value-role component (not a domain controller, hypervisor, identity provider, backup agent, PKI, or network edge appliance). A small fraction of Fastify apps serve as custom identity providers where rate limiting on login is security-critical, but even in that worst case the blast radius is account-level compromise — not fleet-scale, domain-scale, or supply-chain-scale. No high-value-role floor override applies.
• No exploitation evidence or weaponized tooling specific to this CVE: While the generic IPv6 rotation technique is commodity knowledge, no threat actor has been observed targeting @fastify/rate-limit specifically. The 48-hour-old disclosure has produced no PoC repos or scanner plugins yet.

Why not higher?

The vendor's HIGH (7.3) would be appropriate if bypassing the rate limit *directly* achieved compromise — but it doesn't. The CIA impact is Low/Low/Low by the vendor's own vector. The vulnerability is a prerequisite-weakener that must be chained with brute-force against an endpoint that also lacks MFA, lockout, and CAPTCHA. Enterprise deployments typically have upstream WAF or CDN rate limits that operate independently of the Fastify middleware, further reducing the population where this vulnerability is the sole defense.

Why not lower?

A LOW or IGNORE rating would underweight the 812K weekly download footprint and the fact that the attack is unauthenticated, remotely exploitable, and requires zero user interaction. Some Fastify applications *do* rely on @fastify/rate-limit as their primary brute-force defense on login endpoints — particularly smaller teams that haven't implemented MFA or account lockout. For those deployments, this bypass is operationally significant. The fix is also trivial (npm update), so there's no reason to deprioritize it into backlog-only status.

1. Enforce MFA on all authentication endpoints — MFA renders brute-force attacks ineffective regardless of rate-limit status. If your Fastify login endpoints lack MFA, this is your highest-priority compensating control — deploy it within the 365-day noisgate remediation window, ideally much sooner.
2. Implement account lockout or progressive delays — Lock accounts after N failed attempts (e.g., 5 failures → 15-minute lockout). This operates independently of IP-based rate limiting and stops credential stuffing even if the rate limiter is bypassed.
3. Add CAPTCHA or proof-of-work on sensitive endpoints — reCAPTCHA v3, hCaptcha, or Turnstile on login/OTP/reset endpoints impose per-request cost that IPv6 rotation cannot circumvent.
4. Apply upstream rate limiting at CDN/WAF/API gateway — Cloudflare Rate Limiting, AWS WAF rate-based rules, or NGINX limit_req with IPv6 subnet awareness (/64 bucketing) will throttle traffic before it reaches Fastify. Configure your edge to normalize and subnet-mask IPv6 addresses.
5. Pin a custom keyGenerator until you can upgrade — If you cannot immediately bump to 11.2.0, set a custom keyGenerator that normalizes IPs: keyGenerator: (req) => require('net').isIPv6(req.ip) ? req.ip.replace(/:.*/,'') : req.ip as a rough /16 mask. This is a stopgap — upgrade is the real fix.

Run this on any machine with node and npm installed (no root required). It checks the installed version of @fastify/rate-limit in the current project directory. Example: cd /path/to/your/fastify-app && bash check_cve_2026_15144.sh

#!/usr/bin/env bash
# check_cve_2026_15144.sh
# Checks whether @fastify/rate-limit is vulnerable to CVE-2026-15144
# (IPv6 rate-limit bypass via address rotation / representation aliasing)
# Fixed in: @fastify/rate-limit >= 11.2.0
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

PKG="@fastify/rate-limit"
FIXED="11.2.0"

# Try to find installed version
if command -v npm &>/dev/null; then
  VERSION=$(npm ls "$PKG" --json 2>/dev/null | node -e "
    const j = JSON.parse(require('fs').readFileSync('/dev/stdin','utf8'));
    function find(obj) {
      if (!obj) return null;
      if (obj.dependencies && obj.dependencies['$PKG']) return obj.dependencies['$PKG'].version;
      if (obj.dependencies) for (const k of Object.keys(obj.dependencies)) { const r = find(obj.dependencies[k]); if (r) return r; }
      return null;
    }
    const v = find(j);
    if (v) process.stdout.write(v); else process.exit(1);
  " 2>/dev/null) || true
fi

if [ -z "${VERSION:-}" ]; then
  # Fallback: check package-lock.json or node_modules directly
  if [ -f node_modules/@fastify/rate-limit/package.json ]; then
    VERSION=$(node -e "console.log(require('./node_modules/@fastify/rate-limit/package.json').version)" 2>/dev/null) || true
  fi
fi

if [ -z "${VERSION:-}" ]; then
  echo "UNKNOWN — $PKG not found in this project"
  exit 2
fi

# Compare versions using node's semver-compatible comparison
RESULT=$(node -e "
  const v = '$VERSION'.split('.').map(Number);
  const f = '$FIXED'.split('.').map(Number);
  for (let i = 0; i < 3; i++) {
    if (v[i] < f[i]) { console.log('VULNERABLE'); process.exit(0); }
    if (v[i] > f[i]) { console.log('PATCHED'); process.exit(0); }
  }
  console.log('PATCHED');
" 2>/dev/null)

if [ "$RESULT" = "VULNERABLE" ]; then
  echo "VULNERABLE — $PKG $VERSION is below fixed version $FIXED (CVE-2026-15144)"
  exit 1
elif [ "$RESULT" = "PATCHED" ]; then
  echo "PATCHED — $PKG $VERSION >= $FIXED"
  exit 0
else
  echo "UNKNOWN — could not compare versions"
  exit 2
fi

Sources

1. GitHub Security Advisory GHSA-grpc-p53c-r64v
2. @fastify/rate-limit Releases (v11.2.0)
3. @fastify/rate-limit README — keyGenerator and ipv6Subnet docs
4. freebind — IPv6 address rotation evasion tool
5. OneUptime — How to Handle IPv6 in Rate Limiting Middleware
6. CVE-2026-30827 — express-rate-limit IPv6 bypass (related class)
7. HackTricks — Rate Limit Bypass Techniques