@fastify/rate-limit vulnerable to rate-limit bypass via IPv6 address rotation
@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.
- Products
- Not specified
- Affected versions
- Not specified
- Fixed versions
- Not specified
- CVEs
- CVE-2026-15144
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 4 Nov 2026, 01:58 UTC · Revision 1
Source evidence
@fastify/rate-limit vulnerable to rate-limit bypass via IPv6 address rotation
core-osv · Original sourcePublished 29 Jul 2026, 16:10 UTC
@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.
osv:CVE-2026-15144
Complete source record
{
"id": "bd42591e4c387839749767f7feb60b538b29210956571d21354d2ac832dd89d8",
"url": "https://osv.dev/vulnerability/CVE-2026-15144",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "@fastify/rate-limit vulnerable to rate-limit bypass via IPv6 address rotation",
"summary": "@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.",
"evidence": "osv:CVE-2026-15144",
"products": [],
"severity": "high",
"structured": {
"id": "CVE-2026-15144",
"aliases": [
"CVE-2026-15144",
"GHSA-grpc-p53c-r64v"
],
"metrics": [
{
"type": "CVSS_V3",
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L"
}
],
"affected": [
{
"ranges": [
{
"repo": "https://github.com/fastify/fastify-rate-limit",
"type": "GIT",
"events": [
{
"introduced": "0"
},
{
"fixed": "92da9644ee157a9abbbaa2925ff86fbd23fe155a"
}
],
"database_specific": {
"extracted_events": [
{
"range": [
{
"introduced": "0"
},
{
"fixed": "11.2.0"
}
],
"source": "AFFECTED_FIELD",
"strategy": "StandardRange"
},
{
"cpe": "cpe:2.3:a:fastify:fastify\\/rate-limit:*:*:*:*:*:node.js:*:*",
"range": [
{
"introduced": "0"
},
{
"fixed": "11.2.0"
}
],
"source": "CPE_RANGE"
}
]
}
}
],
"versions": [
"v11.1.0",
"v11.0.0",
"v10.3.0",
"v10.2.2",
"v10.2.1",
"v10.2.0",
"v10.1.1",
"v10.1.0",
"v10.0.1",
"v10.0.0",
"v9.1.0",
"v9.0.1",
"v9.0.0",
"v8.0.3",
"v8.1.0",
"v8.0.2",
"v8.0.1",
"v8.0.0",
"v7.6.0",
"v7.5.0",
"v7.4.0",
"v7.2.0",
"v7.1.0",
"v7.0.0",
"v6.0.1",
"v6.0.0",
"v5.8.0",
"v5.7.2",
"v5.7.1",
"v5.7.0",
"v5.6.2",
"v5.6.1",
"v5.6.0",
"v5.5.0",
"v5.4.1",
"v5.4.0",
"v5.3.0",
"v5.2.0",
"v5.1.0",
"v5.0.1",
"v5.0.0",
"v4.1.0",
"v4.0.3",
"v4.0.2",
"v4.0.1",
"v4.0.0",
"v3.0.1",
"v3.0.0",
"v2.4.0",
"v2.3.0",
"v2.2.0",
"v2.1.1",
"v2.1.0",
"v2.0.1",
"v2.0.0",
"v1.0.0",
"v0.3.0",
"v0.2.0",
"v0.1.1",
"v0.1.0"
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-15144.json"
}
}
],
"modified": "2026-10-28T02:30:32.559770223Z",
"provider": "osv",
"references": [
"https://cna.openjsf.org/security-advisories.html",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/15xxx/CVE-2026-15144.json",
"https://github.com/fastify/fastify-rate-limit/security/advisories/GHSA-grpc-p53c-r64v",
"https://nvd.nist.gov/vuln/detail/CVE-2026-15144"
],
"provider_metadata": {
"cwe_ids": [
"CWE-307",
"CWE-770"
],
"cna_assigner": "openjs",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/15xxx/CVE-2026-15144.json"
}
},
"related_cves": [
{
"value": "CVE-2026-15144",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": "/severity/0/score"
},
"source_id": "core-osv",
"document_id": 499512,
"published_at": "2026-07-29T16:10:24.56+00:00"
}