GHSA-hwr6-493r-vm6h: Input Validation
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 same applied to the documented query alias for querystring. This is a complete bypass rather than a weak-schema issue, since false is the strongest JSON Schema assertion and must always fail.
Patches
Request-part schemas are now selected by an explicit presence check rather than truthiness, so a boolean false (or true) schema is compiled and enforced, including through the query alias. Patched in fastify 5.12.2. The fix is also included in the 6.0.0 release.
Workarounds
If upgrading is not immediately possible, express a deny-all request schema with an always-failing object schema instead of the boolean false (for example { "not": {} }), or reject the request in an onRequest hook.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/fastifyto a version that resolves this vulnerability.Fixed in 5.12.2 - Upgrade
Upgrade
fastifyto a version that resolves this vulnerability.Fixed in 5.12.2 - Configuration
Replace a boolean false deny-all schema with an always-failing object schema such as { "not": {} } so the request part is rejected.
Fastify request-part schema body/querystring/query/params/headers schema = {"not":{}}
Event History
Frequently Asked Questions
Which applications are realistically exposed?
Applications are exposed if they use a boolean false schema for a route's body, querystring, query alias, params, or headers to reject all requests. In affected Fastify versions, that request part receives no compiled validator and the handler remains reachable.
What does an attacker need to exploit this behavior?
An unauthenticated remote client can exploit it without special input, provided the target route relies on a false request-part schema as a deny-all control. The client can reach the handler with any input.
How can I identify potentially affected routes?
Review route schemas for body, querystring, query, params, or headers set to the boolean value false, especially where this was intended to make a route unreachable. Those routes should be treated as bypassable unless running a release containing the fix.
Which releases contain the fix?
The issue is patched in Fastify 5.12.2 and is also included in the 6.0.0 release. The fix compiles and enforces boolean false and true schemas, including the query alias.