@fastify/rate-limit before 11.2.0 keys rate-limit buckets by the verbatim client IP string returned from request.ip. Because a single IPv6 client can control a large address range (a /64 holds 2^64 distinct addresses) and the same address has multiple valid textual representations, an IPv6 capable client can defeat the rate-limit boundary by rotating addresses or by rewriting the same address in different forms. Applications that use @fastify/rate-limit to protect endpoints such as authentication, password reset, OTP delivery, or expensive API calls can be bypassed by IPv6 clients behind a proxy that surfaces IPv6 to the origin when trustProxy is enabled. The issue is fixed in @fastify/rate-limit 11.2.0, where the default key generator normalizes IPv6 addresses to their canonical form, collapses IPv4 mapped IPv6 to IPv4, and applies a configurable prefix mask (default /64) via a new ipv6Subnet option.
Weakness
The product does not implement sufficient measures to prevent multiple failed authentication attempts within a short time frame.
Affected Software
| Name | Vendor | Start Version | End Version |
|---|---|---|---|
| Fastify/rate-limit | Fastify | * | 11.2.0 (excluding) |
Potential Mitigations
Common protection mechanisms include:
Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482].
Consider using libraries with authentication capabilities such as OpenSSL or the ESAPI Authenticator. [REF-45]
Related Attack Patterns
- https://cwe.mitre.org/data/definitions/16.html
- https://cwe.mitre.org/data/definitions/49.html
- https://cwe.mitre.org/data/definitions/560.html
- https://cwe.mitre.org/data/definitions/565.html
- https://cwe.mitre.org/data/definitions/600.html
- https://cwe.mitre.org/data/definitions/652.html
- https://cwe.mitre.org/data/definitions/653.html