Authentication Bypass Using an Alternate Path or Channelfastify is an overhead web framework, for Node.js.
Affected versions of this package are vulnerable to Authentication Bypass Using an Alternate Path or Channel via malformed URLs in the fourOhFour router in lib/four-oh-four.js. An attacker can reach an encapsulated not-found handler and bypass its preHandler by sending a malformed request target such as /public/%c0 to a sibling plugin prefix when no route matches the request method. Because the malformed URL is routed through the shared not-found dispatch path, Fastify can invoke the wrong plugin’s 404 handler and return its response without running the protected handler’s authentication hook. This breaks prefix-scoped not-found handling and exposes any data or behavior that the private fallback handler would normally guard.
Workarounds
- Reject malformed request targets before they reach the application, for example at an upstream proxy or gateway, to prevent malformed URLs from reaching encapsulated not-found handlers and bypassing their
preHandler authentication hooks.
- Do not rely on a not-found handler to serve protected data, so a malformed URL cannot be used to obtain private fallback responses from a sibling plugin’s 404 handler.
How to fix Authentication Bypass Using an Alternate Path or Channel? Upgrade fastify to version 5.12.2 or higher.
| |
Improper Validation of Unsafe Equivalence in Inputfastify is an overhead web framework, for Node.js.
Affected versions of this package are vulnerable to Improper Validation of Unsafe Equivalence in Input due to incomplete schema case normalization in lib/validation.js when compiling header schemas. An attacker can bypass schema-enforced header dependencies by sending canonical-cased header names in a request while omitting the dependent header the schema is meant to require. Because Node.js stores request headers in lowercase, Fastify’s shallow normalization missed dependencies and nested subschemas, so assertions such as requiring X-Admin-Token when X-Admin is present never matched the incoming request headers. This lets a remote client reach privileged header-gated routes or actions without supplying the full set of headers the application intended to enforce.
Workarounds
- Inline the header schema instead of referencing it with an external
$ref, so header names can be case-normalized and case-insensitive assertions like required and dependencies still apply.
How to fix Improper Validation of Unsafe Equivalence in Input? Upgrade fastify to version 5.12.2 or higher.
| |
Improper Validation of Specified Type of Inputfastify is an overhead web framework, for Node.js.
Affected versions of this package are vulnerable to Improper Validation of Specified Type of Input via the route schema handling in lib/route.js, lib/schemas.js, and lib/validation.js. An attacker can reach a route handler with arbitrary input by sending a request to an endpoint that uses false as a deny-all schema for body, querystring, params, headers, or the query alias. Because those schemas were treated as absent when evaluated for JavaScript truthiness, Fastify skipped validator compilation and let the request proceed to the handler, allowing unauthenticated access to routes that were intended to reject every request.
Workarounds
- Express a deny-all request schema with an always-failing object schema such as
{ "not": {} } instead of the boolean false, so the route still rejects requests before they reach the handler.
- Reject the request in an
onRequest hook, so unauthenticated clients are blocked before route handling even if a request-part schema was defined with false.
How to fix Improper Validation of Specified Type of Input? Upgrade fastify to version 5.12.2 or higher.
| |
Incorrect Behavior Order: Early Validationfastify is an overhead web framework, for Node.js.
Affected versions of this package are vulnerable to Incorrect Behavior Order: Early Validation through the request validation path in lib/validation.js. An attacker can replace the validated request body, or trigger a validation failure, by sending an $async schema-validated payload that includes attacker-controlled value or error properties. When a route uses an asynchronous request schema, Fastify processes the resolved validator result before the handler runs and can pass the handler a different body than the one that satisfied the schema. This can lead to unauthorized state changes or data disclosure in applications that trust the validated request body for business logic.
Workarounds
- Avoid
$async request schemas.
- Perform the security-sensitive check in an
onRequest or preHandler hook rather than relying on the schema-validated request part.
- Custom async validator compilers should throw or reject on failure instead of returning an
{ error } object.
How to fix Incorrect Behavior Order: Early Validation? Upgrade fastify to version 5.12.2 or higher.
| |
