CVE-2026-15144: Fastify Rate-Limit Auth Bypass Vulnerability

CVE-2026-15144 Overview

CVE-2026-15144 is a rate-limit bypass in @fastify/rate-limit versions before 11.2.0. The library keys rate-limit buckets by the verbatim client IP string returned from request.ip. IPv6 clients control large address ranges, since a single /64 holds 2^64 distinct addresses. The same address also has multiple valid textual representations. An attacker can rotate source addresses within their /64 or rewrite the same address in different textual forms to defeat the rate-limit boundary. Endpoints protected by this middleware, including authentication, password reset, one-time password (OTP) delivery, and expensive API calls, become vulnerable to brute-force and abuse when trustProxy surfaces IPv6 to the origin. This weakness maps to [CWE-307] Improper Restriction of Excessive Authentication Attempts.

Critical Impact
IPv6 clients can bypass rate limiting on sensitive endpoints, enabling brute-force attacks against authentication, OTP, and password reset flows.

Affected Products

@fastify/rate-limit versions prior to 11.2.0
Fastify applications with trustProxy enabled and IPv6 client reachability
Endpoints relying on default key generation for rate limiting

Discovery Timeline

2026-07-29 - CVE-2026-15144 published to NVD
2026-07-29 - Last updated in NVD database

Technical Details for CVE-2026-15144

Vulnerability Analysis

The @fastify/rate-limit plugin enforces request quotas by grouping requests into buckets keyed on a client identifier. Prior to version 11.2.0, the default key generator used the raw string value of request.ip without normalization. This design assumes each client maps to exactly one stable IP string, which holds for IPv4 but breaks for IPv6.

IPv6 introduces two problems the library did not address. First, an attacker with a routed /64 or larger controls billions of distinct source addresses that all belong to a single client. Second, the same IPv6 address can be expressed in multiple textual forms, such as 2001:db8::1, 2001:0db8:0000:0000:0000:0000:0000:0001, and IPv4-mapped variants like ::ffff:192.0.2.1. Each variant produces a different bucket key.

When trustProxy is enabled and a front-end proxy passes the original IPv6 client address to the origin, an attacker rotates addresses or rewrites the same address to obtain a fresh quota per request. Rate limits on authentication, OTP delivery, and expensive queries no longer constrain the attacker.

Root Cause

The root cause is missing input normalization in the default key generator. The plugin trusted request.ip as a canonical client identifier without collapsing textual variants, mapping IPv4-in-IPv6 forms, or aggregating addresses within an IPv6 prefix.

Attack Vector

The attack is network-based and requires no authentication or user interaction. An IPv6-capable client sends requests to a protected endpoint, varying the source address within a controlled /64 or rewriting the same address in different textual representations. Each request receives a fresh bucket, bypassing the configured limit. See the GitHub Fastify Advisory GHSA-grpc-p53c-r64v for advisory details.

Detection Methods for CVE-2026-15144

Indicators of Compromise

Bursts of requests to authentication, /login, /reset, or OTP endpoints from many distinct IPv6 addresses sharing a common /64 prefix
Repeated requests from the same underlying IPv6 address expressed in varied textual forms, including IPv4-mapped ::ffff: notation
Rate-limit counters that never trip despite request volumes exceeding configured thresholds

Detection Strategies

Aggregate access-log analysis by IPv6 /64 prefix rather than by full address to reveal distributed abuse
Alert on high cardinality of unique IPv6 addresses hitting sensitive endpoints within short windows
Compare authentication failure rates before and after normalizing client IPs to canonical form

Monitoring Recommendations

Instrument the rate-limit middleware to log both the raw request.ip and the derived bucket key for anomaly review
Forward web application logs to a centralized analytics platform and pivot on /64 prefix, endpoint, and response code
Track @fastify/rate-limit package version across deployments to confirm upgrade coverage

How to Mitigate CVE-2026-15144

Immediate Actions Required

Upgrade @fastify/rate-limit to version 11.2.0 or later on all Fastify services
Audit applications that enable trustProxy and expose IPv6 to the origin for prior abuse
Review authentication, password reset, and OTP endpoints for signs of brute-force activity

Patch Information

The issue is fixed in @fastify/rate-limit 11.2.0. The default key generator now normalizes IPv6 addresses to their canonical form, collapses IPv4-mapped IPv6 addresses to IPv4, and applies a configurable prefix mask via a new ipv6Subnet option that defaults to /64. Refer to the OpenJSF Security Advisories and the GitHub Fastify Advisory GHSA-grpc-p53c-r64v for full remediation guidance.

Workarounds

Supply a custom keyGenerator that canonicalizes IPv6 addresses and applies a /64 prefix mask before the bucket lookup
Add an upstream reverse proxy or WAF layer that enforces rate limits per IPv6 /64 prefix
Require authentication or CAPTCHA on sensitive endpoints so rate limiting is not the sole control against abuse

bash

# Upgrade @fastify/rate-limit to the patched release
npm install @fastify/rate-limit@^11.2.0

# Verify the installed version
npm ls @fastify/rate-limit