fastify
Ecosystem: npm
Downloads: 71.53 Mln
- 0CriticalAffects 0 versions
- 9HighAffects 10 versions
- 0MediumAffects 0 versions
- 7ModerateAffects 8 versions
- 2LowAffects 2 versions
- Critical0 (0.0%)
- High9 (50.0%)
- Medium0 (0.0%)
- Moderate7 (38.9%)
- Low2 (11.1%)
Monthly breakdown
- Critical
- High
- Medium
- Moderate
- Low
- 1 vulnerabilities
- Critical: 0
- High: 0
- Medium: 0
- Moderate: 0
- Low: 1
- 7 vulnerabilities
- Critical: 0
- High: 4
- Medium: 0
- Moderate: 3
- Low: 0
- 1 vulnerabilities
- Critical: 0
- High: 1
- Medium: 0
- Moderate: 0
- Low: 0
- 2 vulnerabilities
- Critical: 0
- High: 0
- Medium: 0
- Moderate: 2
- Low: 0
- 2 vulnerabilities
- Critical: 0
- High: 1
- Medium: 0
- Moderate: 0
- Low: 1
- 1 vulnerabilities
- Critical: 0
- High: 1
- Medium: 0
- Moderate: 0
- Low: 0
- 1 vulnerabilities
- Critical: 0
- High: 0
- Medium: 0
- Moderate: 1
- Low: 0
- 1 vulnerabilities
- Critical: 0
- High: 1
- Medium: 0
- Moderate: 0
- Low: 0
- 1 vulnerabilities
- Critical: 0
- High: 0
- Medium: 0
- Moderate: 1
- Low: 0
- 1 vulnerabilities
- Critical: 0
- High: 1
- Medium: 0
- Moderate: 0
- Low: 0
Vulnerabilities (18)
Known vulnerabilities affecting fastify, based on data from OSV.
| ID | Severity | Summary | Affected versions | Published | Source |
|---|---|---|---|---|---|
| GHSA-389g-gv7q-r4x8 | Low | fastify is vulnerable to header validation bypass via case-sensitive propertyNames### Impact Fastify lowercases header names in a `headers` schema before compilation, because Node.js stores request header names in lowercase. This normalization does not reach the header names held in a `propertyNames` subschema's `enum` and `const`. A header-name deny-list written in the canonical header case, such as `propertyNames: { not: { enum: ['X-Debug-Override'] } }`, therefore never matches the lowercased request headers, and the forbidden header reaches the handler. Any application that uses a `propertyNames` deny-list or allow-list to constrain request header names does not get th |
| GitHub (opens in a new tab) | |
| GHSA-4mh8-r7rc-xpvc | Moderate | fastify vulnerable to Denial of Service via unhandled exception on HTTP/2 trailer responses### Impact `fastify` crashes with an uncaught `ERR_HTTP2_INVALID_CONNECTION_HEADERS` exception when a route that registers a response trailer via `reply.trailer()` is served over HTTP/2. Fastify unconditionally adds the `Transfer-Encoding: chunked` header when a trailer is set, which is forbidden on HTTP/2, so Node.js throws while serializing the response headers. The exception is not caught and becomes an uncaughtException, terminating the Node.js process. One unauthenticated HTTP/2 request to any route that uses trailers is enough to crash the server, dropping all in-flight requests, and t |
| GitHub (opens in a new tab) | |
| GHSA-667r-xxjv-c9mm | High | fastify vulnerable to request body replacement via an async validation result collision### Impact Fastify runs a route's validator and, for a result shaped like `{ value, error }`, unwraps it: an `error` becomes a validation failure and `value` replaces the request part. This convention is intended for synchronous custom compilers (for example Joi). A JSON Schema `$async` validator, however, resolves with the validated data itself, so Fastify applied the same unwrapping to it. If a request part validated by an `$async` schema contains a `value` property, Fastify replaced the whole request part with that nested value before the handler ran, so a `value` or `error` property in th |
| GitHub (opens in a new tab) | |
| GHSA-9q9j-q6p8-xq58 | High | fastify vulnerable to header validation bypass via incomplete schema case normalization### Impact Fastify lowercases header-schema property names before compiling the schema, because Node.js stores request header names in lowercase. That normalization was incomplete: it lowercased only top-level `properties` keys and the root `required` array, and did not lowercase the JSON Schema Draft 7 `dependencies` keyword (its trigger keys and dependent property names) or names in nested subschemas. As a result, a header schema that uses `dependencies` to require one header when another is present (for example `X-Admin` requiring `X-Admin-Token`) never matches the lowercased request heade |
| GitHub (opens in a new tab) | |
| GHSA-hwr6-493r-vm6h | High | fastify vulnerable to request validation bypass via skipped boolean false schemas### Impact Fastify decided whether to validate a request part by checking its schema for JavaScript truthiness. JSON Schema Draft 7 defines the boolean `false` as a valid schema that rejects every instance, but because `false` is falsy, a route that set `body`, `querystring`, `params`, or `headers` to `false` had that part left uncompiled: no validator was attached and the request reached the handler. An application that used `false` as a deny-all schema to make a route unreachable was therefore fully bypassed, and an unauthenticated remote client could reach the handler with any input. The s |
| GitHub (opens in a new tab) | |
| GHSA-p68q-wchp-6fh7 | High | fastify vulnerable to authentication bypass via malformed URLs reaching encapsulated not-found handlers### Impact Fastify routes a malformed URL under one plugin prefix to the custom not-found handler of a different sibling plugin, invoking the handler registered last and skipping the `preHandler` declared in its `setNotFoundHandler()`. When the request method has no route in the main router, a malformed request target reaches Fastify's internal not-found router before URL decoding and is dispatched through a single shared handler pointer, regardless of prefix and without the normal request lifecycle. An unauthenticated request to a public prefix can therefore reach an authentication-protected |
| GitHub (opens in a new tab) | |
| GHSA-3m5p-2c4r-xxw2 | Moderate | fastify vulnerable to X-Forwarded-* spoofing under trustProxy hop-count## Impact The fix for [CVE-2026-3635](https://www.cve.org/CVERecord?id=CVE-2026-3635) ([GHSA-444r-cwp2-x5xf](https://github.com/fastify/fastify/security/advisories/GHSA-444r-cwp2-x5xf)) added a `proxyFn(socket.remoteAddress, 0)` guard on the `X-Forwarded-*` reads in `request.host`, `request.protocol`, `request.hostname`, `request.ip`, and `request.ips`. That guard closes the IP, CIDR, and custom-function forms of `trustProxy` correctly because those forms compile to predicates that inspect the connecting address. The hop-count form (`trustProxy: <number>`) compiles to a predicate that structu |
| GitHub (opens in a new tab) | |
| GHSA-w2qp-rph6-63g4 | Moderate | fastify vulnerable to schema validation bypass via root primitive coercion mismatch### Impact `fastify` before 5.12.1, when a route uses a root-level primitive body schema (for example an integer with a minimum and maximum) and the default type coercion, validates the coerced value but exposes the original, uncoerced value to the route handler. For example, a JSON body `"10"` is coerced to the number `10` and passes an integer 1 to 10 schema, but `request.body` stays the string `"10"`. An application that trusts the validated type is handed a value that did not satisfy the schema, which can bypass limits the application enforces on that typed value. Object and array body sc |
| GitHub (opens in a new tab) | |
| GHSA-247c-9743-5963 | High | Fastify has a Body Schema Validation Bypass via Leading Space in Content-Type Header### Summary A validation bypass vulnerability exists in Fastify v5.x where request body validation schemas specified via `schema.body.content` can be completely circumvented by prepending a single space character (`\x20`) to the `Content-Type` header. The body is still parsed correctly as JSON (or any other content type), but schema validation is entirely skipped. This is a regression introduced by commit [`f3d2bcb`](https://github.com/fastify/fastify/commit/f3d2bcb3963cd570a582e5d39aab01a9ae692fe4) (fix for [CVE-2025-32442](https://github.com/fastify/fastify/security/advisories/GHSA-mg2h-6x62 |
| GitHub (opens in a new tab) | |
| GHSA-444r-cwp2-x5xf | Moderate | fastify: request.protocol and request.host Spoofable via X-Forwarded-Proto/Host from Untrusted Connections## Summary When `trustProxy` is configured with a restrictive trust function (e.g., a specific IP like `trustProxy: '10.0.0.1'`, a subnet, a hop count, or a custom function), the `request.protocol` and `request.host` getters read `X-Forwarded-Proto` and `X-Forwarded-Host` headers from any connection — including connections from untrusted IPs. This allows an attacker connecting directly to Fastify (bypassing the proxy) to spoof both the protocol and host seen by the application. ## Affected Versions fastify <= 5.8.2 ## Impact Applications using `request.protocol` or `request.host` for secu |
| GitHub (opens in a new tab) |
- GHSA-389g-gv7q-r4x8Lowfastify is vulnerable to header validation bypass via case-sensitive propertyNames
>= 5.12.2, < 5.12.6
### Impact Fastify lowercases header names in a `headers` schema before compilation, because Node.js stores request header names in lowercase. This normalization does not reach the header names held in a `propertyNames` subschema's `enum` and `const`. A header-name deny-list written in the canonical header case, such as `propertyNames: { not: { enum: ['X-Debug-Override'] } }`, therefore never matches the lowercased request headers, and the forbidden header reaches the handler. Any application that uses a `propertyNames` deny-list or allow-list to constrain request header names does not get th
CVE: CVE-2026-107832
- GHSA-4mh8-r7rc-xpvcModeratefastify vulnerable to Denial of Service via unhandled exception on HTTP/2 trailer responses
< 5.12.5
### Impact `fastify` crashes with an uncaught `ERR_HTTP2_INVALID_CONNECTION_HEADERS` exception when a route that registers a response trailer via `reply.trailer()` is served over HTTP/2. Fastify unconditionally adds the `Transfer-Encoding: chunked` header when a trailer is set, which is forbidden on HTTP/2, so Node.js throws while serializing the response headers. The exception is not caught and becomes an uncaughtException, terminating the Node.js process. One unauthenticated HTTP/2 request to any route that uses trailers is enough to crash the server, dropping all in-flight requests, and t
CVE: CVE-2026-92081
- GHSA-667r-xxjv-c9mmHighfastify vulnerable to request body replacement via an async validation result collision
< 5.12.2
### Impact Fastify runs a route's validator and, for a result shaped like `{ value, error }`, unwraps it: an `error` becomes a validation failure and `value` replaces the request part. This convention is intended for synchronous custom compilers (for example Joi). A JSON Schema `$async` validator, however, resolves with the validated data itself, so Fastify applied the same unwrapping to it. If a request part validated by an `$async` schema contains a `value` property, Fastify replaced the whole request part with that nested value before the handler ran, so a `value` or `error` property in th
CVE: CVE-2026-84504
- GHSA-9q9j-q6p8-xq58Highfastify vulnerable to header validation bypass via incomplete schema case normalization
< 5.12.2
### Impact Fastify lowercases header-schema property names before compiling the schema, because Node.js stores request header names in lowercase. That normalization was incomplete: it lowercased only top-level `properties` keys and the root `required` array, and did not lowercase the JSON Schema Draft 7 `dependencies` keyword (its trigger keys and dependent property names) or names in nested subschemas. As a result, a header schema that uses `dependencies` to require one header when another is present (for example `X-Admin` requiring `X-Admin-Token`) never matches the lowercased request heade
CVE: CVE-2026-84428
- GHSA-hwr6-493r-vm6hHighfastify vulnerable to request validation bypass via skipped boolean false schemas
< 5.12.2
### Impact Fastify decided whether to validate a request part by checking its schema for JavaScript truthiness. JSON Schema Draft 7 defines the boolean `false` as a valid schema that rejects every instance, but because `false` is falsy, a route that set `body`, `querystring`, `params`, or `headers` to `false` had that part left uncompiled: no validator was attached and the request reached the handler. An application that used `false` as a deny-all schema to make a route unreachable was therefore fully bypassed, and an unauthenticated remote client could reach the handler with any input. The s
CVE: CVE-2026-84469
- GHSA-p68q-wchp-6fh7Highfastify vulnerable to authentication bypass via malformed URLs reaching encapsulated not-found handlers
>= 4.0.0, < 5.12.2
### Impact Fastify routes a malformed URL under one plugin prefix to the custom not-found handler of a different sibling plugin, invoking the handler registered last and skipping the `preHandler` declared in its `setNotFoundHandler()`. When the request method has no route in the main router, a malformed request target reaches Fastify's internal not-found router before URL decoding and is dispatched through a single shared handler pointer, regardless of prefix and without the normal request lifecycle. An unauthenticated request to a public prefix can therefore reach an authentication-protected
CVE: CVE-2026-76169
- GHSA-3m5p-2c4r-xxw2Moderatefastify vulnerable to X-Forwarded-* spoofing under trustProxy hop-count
>= 5.8.3, < 5.12.1
## Impact The fix for [CVE-2026-3635](https://www.cve.org/CVERecord?id=CVE-2026-3635) ([GHSA-444r-cwp2-x5xf](https://github.com/fastify/fastify/security/advisories/GHSA-444r-cwp2-x5xf)) added a `proxyFn(socket.remoteAddress, 0)` guard on the `X-Forwarded-*` reads in `request.host`, `request.protocol`, `request.hostname`, `request.ip`, and `request.ips`. That guard closes the IP, CIDR, and custom-function forms of `trustProxy` correctly because those forms compile to predicates that inspect the connecting address. The hop-count form (`trustProxy: <number>`) compiles to a predicate that structu
CVE: CVE-2026-16732
- GHSA-w2qp-rph6-63g4Moderatefastify vulnerable to schema validation bypass via root primitive coercion mismatch
< 5.12.1
### Impact `fastify` before 5.12.1, when a route uses a root-level primitive body schema (for example an integer with a minimum and maximum) and the default type coercion, validates the coerced value but exposes the original, uncoerced value to the route handler. For example, a JSON body `"10"` is coerced to the number `10` and passes an integer 1 to 10 schema, but `request.body` stays the string `"10"`. An application that trusts the validated type is handed a value that did not satisfy the schema, which can bypass limits the application enforces on that typed value. Object and array body sc
CVE: CVE-2026-18504
- GHSA-247c-9743-5963HighFastify has a Body Schema Validation Bypass via Leading Space in Content-Type Header
>= 5.3.2, < 5.8.5
### Summary A validation bypass vulnerability exists in Fastify v5.x where request body validation schemas specified via `schema.body.content` can be completely circumvented by prepending a single space character (`\x20`) to the `Content-Type` header. The body is still parsed correctly as JSON (or any other content type), but schema validation is entirely skipped. This is a regression introduced by commit [`f3d2bcb`](https://github.com/fastify/fastify/commit/f3d2bcb3963cd570a582e5d39aab01a9ae692fe4) (fix for [CVE-2025-32442](https://github.com/fastify/fastify/security/advisories/GHSA-mg2h-6x62
CVE: CVE-2025-32442
- GHSA-444r-cwp2-x5xfModeratefastify: request.protocol and request.host Spoofable via X-Forwarded-Proto/Host from Untrusted Connections
< 5.8.3
## Summary When `trustProxy` is configured with a restrictive trust function (e.g., a specific IP like `trustProxy: '10.0.0.1'`, a subnet, a hop count, or a custom function), the `request.protocol` and `request.host` getters read `X-Forwarded-Proto` and `X-Forwarded-Host` headers from any connection — including connections from untrusted IPs. This allows an attacker connecting directly to Fastify (bypassing the proxy) to spoof both the protocol and host seen by the application. ## Affected Versions fastify <= 5.8.2 ## Impact Applications using `request.protocol` or `request.host` for secu
CVE: CVE-2026-3635