fastify vulnerabilities

In fastify versions 5.12.2 through 5.12.5, the routine that lowercases header names declared in a route schema does not lowercase the enum or const header names nested inside a propertyNames subschema. As a result, a header allow-list or deny-list written with canonical (non-lowercase) casing never matches the incoming lowercased header, so a restricted header passes validation and reaches the route handler. An attacker can therefore bypass a case-sensitive header validation rule and smuggle a forbidden header past the schema, affecting the integrity of request handling. The issue is fixed in fastify 5.12.6.

In fastify before version 5.12.5, when a route registers a response trailer via reply.trailer() and is served over HTTP/2, fastify unconditionally sets the Transfer-Encoding: chunked header, which is forbidden on HTTP/2, causing Node.js to throw while serializing response headers. The exception is not caught and becomes an uncaughtException, so a single unauthenticated HTTP/2 request to any route using trailers crashes the server process and drops all in-flight requests; it can be repeated on every restart. The issue is fixed in fastify 5.12.5.

In fastify versions before 5.12.2, the case-insensitive handling of HTTP header names is implemented by lowercasing names in a route's header schema before compiling it, but the transformation is incomplete: it lowercases the properties keys and the root-level required array, and does not lowercase the trigger and dependent names inside the JSON Schema Draft 7 dependencies keyword. Because Node stores request header names in lowercase, a canonical-case dependency such as requiring an authentication header whenever a privileged-mode header is present never matches, and the presence assertion is silently skipped. An unauthenticated remote client can therefore send the header that activates a privileged branch while omitting the header the dependency was meant to require, bypassing the conditional check.

fastify versions before 5.12.2 treat the object resolved by a successful Ajv async validator as the value result protocol used by custom validator compilers. If a request that passes its route schema contains a property named value at the root, fastify replaces the entire request body with that property's value before the handler runs, so the handler receives a different object than the one that satisfied the schema. An authenticated low-privilege caller can use this to make nested data replace the validated body and trigger an operation the route schema did not authorize, leading to unauthorized state changes and data disclosure.

fastify versions before 5.12.2 decide whether to compile a request schema based on JavaScript truthiness, but JSON Schema Draft 7 defines the boolean false as a valid schema that rejects every instance. When an application assigns false to a route's body, querystring, params, or headers schema to deny all input, fastify treats it as a missing schema, compiles no validator, and runs the route handler on any request. An unauthenticated remote client can therefore reach a handler that a valid deny-all schema was intended to make unreachable, a complete validation bypass that can lead to unauthorized state changes or execution of disabled operations.

fastify versions >= 4.0.0 and before 5.12.2 can route a malformed URL sent under one plugin prefix to the custom not-found handler of a different sibling plugin, and invoke it without the preHandler hook declared for that handler. The internal not-found router for encapsulated handlers dispatches malformed paths through a single shared handler pointer before URL decoding, ignoring the prefix and skipping the selected handler's normal lifecycle. An unauthenticated attacker can therefore reach an authentication-protected private fallback through an unrelated public prefix and read its full response, bypassing the authentication hook and breaking prefix encapsulation.

fastify before version 5.12.1 is affected by a schema validation bypass when a request body schema targets a root primitive value. When the schema validates a top-level primitive such as an integer, Ajv can coerce a JSON string into the expected type during validation, but Fastify does not replace the root request body with the coerced value, so the route handler receives the original unvalidated string. As a result, a request that should have failed validation can reach application logic with a value that does not satisfy the schema, which can undermine integrity and access-control checks that rely on the validated type.

fastify from 5.8.3 up to but not including 5.12.1 has a vulnerability related to insufficient protection of forwarded headers when using the numeric form of trustProxy. The guard added in the fix for CVE-2026-3635 checks the connecting address, but the hop-count form compiles to a predicate that structurally ignores the address, so the guard is always satisfied for any hop count of one or more. Applications configured with a numeric trustProxy value, such as 1, remain vulnerable: an attacker who can reach the Fastify origin directly, bypassing the front-facing proxy, can spoof the forwarded request fields exactly as in the unpatched version. The impact includes host injection in generated URLs, HTTPS-enforcement bypass, secure-cookie and CSRF-origin bypass, and host-based routing and cache poisoning.

A vulnerability in Fastify allows bypassing request body validation by prepending a space to the Content-Type header. This regression was introduced in version 5.3.2 by the fix for CVE-2025-32442.

In Fastify prior to version 5.7.2, a validation bypass vulnerability exists where request body validation schemas specified by Content-Type can be circumvented. By appending a tab character (\t) followed by arbitrary content to the Content-Type header, attackers can bypass body validation while the server still processes the body as the original content type.