Summary
@fastify/rate-limit before 11.2.0 keys buckets using the raw client IP string, allowing IPv6 clients to evade limits by rotating addresses or rewriting the same address in different textual forms.
When applications rely on this rate limiting to protect sensitive endpoints, IPv6-capable clients behind trusted proxies can bypass throttling controls and perform high-volume or automated actions.
@fastify/rate-limit before 11.2.0 keys buckets using the raw client IP string, allowing IPv6 clients to evade limits by rotating addresses or rewriting the same address in different textual forms.
When applications rely on this rate limiting to protect sensitive endpoints, IPv6-capable clients behind trusted proxies can bypass throttling controls and perform high-volume or automated actions.
Affected context
This vulnerability occurs in Node.js applications using the @fastify/rate-limit plugin with versions before 11.2.0, particularly when:
- trustProxy is enabled and the origin sees IPv6 addresses
- The default keying behavior depends on request.ip verbatim string values
- Rate limiting is used as a primary control for authentication, password reset, OTP delivery, or expensive API endpoints
It becomes relevant in environments where a single IPv6 client can influence many addresses within a /64 range or re-encode the same IPv6 address in multiple equivalent textual forms.
This vulnerability occurs in Node.js applications using the @fastify/rate-limit plugin with versions before 11.2.0, particularly when:
- trustProxy is enabled and the origin sees IPv6 addresses
- The default keying behavior depends on request.ip verbatim string values
- Rate limiting is used as a primary control for authentication, password reset, OTP delivery, or expensive API endpoints
It becomes relevant in environments where a single IPv6 client can influence many addresses within a /64 range or re-encode the same IPv6 address in multiple equivalent textual forms.
Exploit preconditions
- Attack surface: HTTP endpoints protected by @fastify/rate-limit (e.g., login, password reset, OTP, billing or compute-heavy APIs)
- Required access: Ability to send requests as an IPv6-capable client, often behind a proxy that forwards the IPv6 address when trustProxy is enabled
- Trigger point: The plugin's rate-limit key generator uses the raw request.ip string, treating each distinct textual representation as a separate bucket
- Why exploitation is possible: IPv6 addresses can be rotated within a large subnet (such as /64) and encoded in different syntactically valid forms. The plugin does not normalize or subnet-mask these addresses, allowing one logical client to appear as many distinct IP identities and evade per-IP throttling.
- Attack surface: HTTP endpoints protected by @fastify/rate-limit (e.g., login, password reset, OTP, billing or compute-heavy APIs)
- Required access: Ability to send requests as an IPv6-capable client, often behind a proxy that forwards the IPv6 address when trustProxy is enabled
- Trigger point: The plugin's rate-limit key generator uses the raw request.ip string, treating each distinct textual representation as a separate bucket
- Why exploitation is possible: IPv6 addresses can be rotated within a large subnet (such as /64) and encoded in different syntactically valid forms. The plugin does not normalize or subnet-mask these addresses, allowing one logical client to appear as many distinct IP identities and evade per-IP throttling.
Why this happens
The underlying bug class is an insufficient enforcement of rate limiting due to naive identity keying based on raw IP strings.
The plugin trusts request.ip as a unique identifier without normalizing IPv6 representations, collapsing IPv4-mapped IPv6, or grouping addresses by subnet, which enables clients to bypass limits by changing addresses or textual forms.
This maps to CWE-307: Improper Restriction of Excessive Authentication Attempts, where rate limits used to protect sensitive operations can be circumvented, and CWE-770: Allocation of Resources Without Limits or Throttling, reflecting the ineffective resource control when the throttling keys are easily evaded.
The underlying bug class is an insufficient enforcement of rate limiting due to naive identity keying based on raw IP strings.
The plugin trusts request.ip as a unique identifier without normalizing IPv6 representations, collapsing IPv4-mapped IPv6, or grouping addresses by subnet, which enables clients to bypass limits by changing addresses or textual forms.
This maps to CWE-307: Improper Restriction of Excessive Authentication Attempts, where rate limits used to protect sensitive operations can be circumvented, and CWE-770: Allocation of Resources Without Limits or Throttling, reflecting the ineffective resource control when the throttling keys are easily evaded.
Potential impact
- Attackers may perform unlimited authentication attempts, increasing the effectiveness of credential stuffing or brute-force attacks.
- Clients could repeatedly request password reset or OTP delivery, enabling account lockout, notification flooding, or abuse of SMS/email channels.
- Automated scripts can hit expensive API endpoints at high volume, potentially leading to increased compute costs or degraded service performance.
- Abuse of business logic flows that rely on per-IP throttling as a primary safeguard can occur, impacting fraud prevention or quota enforcement.
- Attackers may perform unlimited authentication attempts, increasing the effectiveness of credential stuffing or brute-force attacks.
- Clients could repeatedly request password reset or OTP delivery, enabling account lockout, notification flooding, or abuse of SMS/email channels.
- Automated scripts can hit expensive API endpoints at high volume, potentially leading to increased compute costs or degraded service performance.
- Abuse of business logic flows that rely on per-IP throttling as a primary safeguard can occur, impacting fraud prevention or quota enforcement.
General mitigation guidance
Effective mitigation focuses on making rate-limiting identities robust and resistant to trivial evasion rather than tied to raw IP strings.
Common patterns include:
- Normalizing IPv6 addresses to a canonical textual form before using them as keys, and collapsing IPv4-mapped IPv6 addresses to consistent IPv4 representations.
- Applying subnet-based grouping (e.g., masking to a /64) so that a single client's controllable address space maps to a shared rate-limit bucket.
- Combining multiple attributes (such as IP+user account, IP+client fingerprint, or IP+API key) for rate-limit identities rather than relying solely on IP.
- Treating rate limiting as a defense-in-depth control and pairing it with other safeguards like lockout thresholds, captcha/step-up verification, and anomaly detection.
- Designing resource controls around least privilege, ensuring sensitive operations do not depend solely on per-IP throttling for protection.
Effective mitigation focuses on making rate-limiting identities robust and resistant to trivial evasion rather than tied to raw IP strings.
Common patterns include:
- Normalizing IPv6 addresses to a canonical textual form before using them as keys, and collapsing IPv4-mapped IPv6 addresses to consistent IPv4 representations.
- Applying subnet-based grouping (e.g., masking to a /64) so that a single client's controllable address space maps to a shared rate-limit bucket.
- Combining multiple attributes (such as IP+user account, IP+client fingerprint, or IP+API key) for rate-limit identities rather than relying solely on IP.
- Treating rate limiting as a defense-in-depth control and pairing it with other safeguards like lockout thresholds, captcha/step-up verification, and anomaly detection.
- Designing resource controls around least privilege, ensuring sensitive operations do not depend solely on per-IP throttling for protection.
How teams detect issues like this
Detection efforts generally look for signs that rate limiting can be trivially bypassed and for code patterns that rely naively on IP-address identity.
Useful strategies include:
- Static analysis or code review to identify rate-limit key generators that use raw request.ip or equivalent without normalization or subnet masking.
- Reviewing configuration where trustProxy is enabled and the application receives IPv6 addresses, verifying how those addresses are transformed into rate-limit keys.
- Log analysis to detect patterns where a single client behavior (user agent, session, or account) appears associated with many related IPv6 addresses, but all requests stay below per-IP limits.
- Policy-based checks in CI/CD pipelines requiring rate-limiting middleware to use canonical IP handling and, where appropriate, subnet grouping or multi-factor identities.
- Use of automated security review tools that flag fragile rate-limit implementations, especially around authentication and other critical endpoints.
Detection efforts generally look for signs that rate limiting can be trivially bypassed and for code patterns that rely naively on IP-address identity.
Useful strategies include:
- Static analysis or code review to identify rate-limit key generators that use raw request.ip or equivalent without normalization or subnet masking.
- Reviewing configuration where trustProxy is enabled and the application receives IPv6 addresses, verifying how those addresses are transformed into rate-limit keys.
- Log analysis to detect patterns where a single client behavior (user agent, session, or account) appears associated with many related IPv6 addresses, but all requests stay below per-IP limits.
- Policy-based checks in CI/CD pipelines requiring rate-limiting middleware to use canonical IP handling and, where appropriate, subnet grouping or multi-factor identities.
- Use of automated security review tools that flag fragile rate-limit implementations, especially around authentication and other critical endpoints.
Sources
| Source | Link |
|---|---|
| cna. | cna.openjsf.org/ |
| github. | github.com/ |
