Fastify vulnerabilities

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.