Vulnerabilities

Fastify versions before 5.12.2 misinterpret the object resolved by a successful Ajv async validator as the value-result protocol used by custom validator compilers, which is an input validation flaw (CWE-20). The flaw is triggered when an authenticated request passes its route schema but contains a property named 'value' at the root of the body: Fastify then replaces the entire validated request body with that property's value before the handler executes. An authenticated low-privilege attacker can exploit this to make the handler operate on nested, effectively unvalidated data, achieving unauthorized state changes and data disclosure on routes the schema was supposed to protect. Any Fastify application running a version before 5.12.2 that uses Ajv async validation and accepts request bodies with a root-level 'value' property is affected. There is no known public proof of concept, the flaw is not in CISA KEV, and EPSS puts 30-day exploitation probability at 0.4% (32nd percentile), indicating low observed exploitation risk so far.

Do: Upgrade to fastify 5.12.2 or later. As an interim mitigation, avoid accepting request bodies with a root-level 'value' property on routes using Ajv async validation, and audit such routes for handlers that make authorization or state-change decisions based on the body's structure. Because no exploitation is observed yet, prioritize patching internet-facing Fastify APIs that accept untrusted authenticated input.

@fastify/middie, the middleware engine used to run Express-style middleware inside Fastify, decides whether to run path-scoped middleware by matching the raw request target, while Fastify's router resolves absolute-form request targets to their path before dispatching, so the two layers evaluate different strings (a CWE-436 interpretation conflict). An unauthenticated network attacker can send a request whose request line uses an absolute-form target, which then reaches the route handler while path-scoped middleware such as authentication or authorization is skipped. The attacker gains the ability to bypass path-based access controls in the affected application and reach protected endpoints without credentials. Affected users are operators of Fastify applications running @fastify/middie 9.1.0 through 9.3.3 that rely on middie path-scoped middleware for access control on reachable routes. There is no public proof of concept, the flaw is not in CISA KEV, and EPSS estimates a 0.3% 30-day exploitation probability, so no exploitation is currently known.

Do: Upgrade to @fastify/middie 9.3.4 or later. As an interim mitigation, do not rely on middie path-scoped middleware for authentication or authorization on internet-facing routes; enforce access control in Fastify's own lifecycle hooks (which see the resolved route) or normalize request targets at the proxy layer. Audit your Fastify applications for @fastify/middie in the 9.1.0-9.3.3 range and check whether any front-end proxy forwards absolute-form request targets to the application.

Versions of @fastify/http-proxy before 11.6.2 fail to validate proxied HTTP request paths for backslash-based dot-segments before forwarding them to the configured upstream. Because the plain HTTP request handler skips the destination validation that the WebSocket path performs, and the underlying reply-from library only rejects forward-slash traversal, an unauthenticated network attacker can send requests containing backslash dot-segments that escape the boundary enforced by the prefix and rewritePrefix options. This lets the attacker reach upstream paths that were intended to remain hidden behind the proxy, resulting in disclosure of internal endpoints. Any application using @fastify/http-proxy below 11.6.2 is affected. Exploitation has not been reported publicly: there is no known proof of concept, the issue is not in CISA KEV, and EPSS currently estimates only a 0.6% chance of exploitation in the next 30 days.

Do: Upgrade to @fastify/http-proxy 11.6.2 or later. If you cannot upgrade immediately, review your prefix/rewritePrefix configuration for upstream paths that should stay hidden, and consider rejecting incoming proxied request paths containing backslashes or dot-segments at an upstream control such as a reverse proxy or WAF. Check access logs for unusual requests with backslash sequences in the path targeting your proxy endpoints.

@fastify/busboy is a multipart form-data parser for Node.js. Its multipart part-header parser splits header lines only on the two-byte carriage-return line-feed sequence, so a lone carriage return or line feed embedded in a part header is not treated as a line break and is carried verbatim into the parsed Content-Disposition filename and field name handed to the application. An attacker who uploads a file whose filename or field name contains a bare carriage return or line feed can inject control characters into consumers that trust the parser to return clean values, enabling filesystem filename pollution, log forging, or header injection when the value is forwarded to a carriage-return-sensitive sink. All versions of @fastify/busboy up to and including 3.2.1 are affected. The issue is fixed in version 3.2.2, which rejects any header line that still contains a bare carriage return or line feed. Users should upgrade to 3.2.2, and consumers such as @fastify/multipart should bump their @fastify/busboy dependency to pull in the fix.

fastify is a fast and low overhead web framework for Node.js. Impact: the fix for CVE-2026-3635 added a guard on the forwarded-header reads used to derive the request host, protocol, hostname, ip, and ips values, checking the connecting address. 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, where trustProxy is set to a number, 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 trustProxy set to 1 for a single reverse proxy, 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 class matches the parent CVE-2026-3635, including host injection in generated URLs, HTTPS-enforcement bypass, secure-cookie and CSRF-origin bypass, and host-based routing and cache poisoning. Affected versions are fastify from 5.8.3 up to but not including 5.12.1. Patches: patched in fastify 5.12.1, where the numeric form of trustProxy is disabled at runtime and removed from the TypeScript type union. Workarounds: migrate to an IP, CIDR, or custom-function trustProxy value that validates the connecting address, and ensure the Fastify origin is only reachable through the trusted proxy chain.