Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
17 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact Fastify lowercases header names in a headers schema before compilation, because Node.js stores request header names in lowercase. This normalization does not reach the header names held in a propertyNames subschema's enum and const. A header-name deny-list written in the canonical header case, such as propertyNames: { not: { enum: ['X-Debug-Override'] } }, therefore never matches the lowercased request headers, and the forbidden header reaches the handler. Any application that uses a propertyNames deny-list or allow-list to constrain request header names does not get the constraint it expects. The same rule written in lowercase works, and the not: { required: [...] } form is unaffected, so this is a gap in the built-in normalization rather than a wrong schema. This is an incomplete fix of CVE-2026-84428 (GHSA-9q9j-q6p8-xq58), whose normalization covered header names used as property keys but not those used as values inside propertyNames. Patches Users should upgrade to fastify…
Recommended action: Upgrade to 5.12.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact fastify crashes with an uncaught ERRHTTP2INVALIDCONNECTIONHEADERS exception when a route that registers a response trailer via reply.trailer() is served over HTTP/2. Fastify unconditionally adds the Transfer-Encoding: chunked header when a trailer is set, which is forbidden on HTTP/2, so Node.js throws while serializing the response headers. The exception is not caught and becomes an uncaughtException, terminating the Node.js process. One unauthenticated HTTP/2 request to any route that uses trailers is enough to crash the server, dropping all in-flight requests, and the request can be repeated to keep the process down. Applications are affected only when HTTP/2 is enabled (http2: true) and at least one route registers a trailer. HTTP/1.x responses are not affected. Patches Upgrade to fastify 5.12.5 or later. Workarounds Avoid registering response trailers with reply.trailer() on routes served over HTTP/2 until upgrading.
Recommended action: Upgrade to 5.12.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Fastify runs a route's validator and, for a result shaped like { value, error }, unwraps it: an error becomes a validation failure and value replaces the request part. This convention is intended for synchronous custom compilers (for example Joi). A JSON Schema $async validator, however, resolves with the validated data itself, so Fastify applied the same unwrapping to it. If a request part validated by an $async schema contains a value property, Fastify replaced the whole request part with that nested value before the handler ran, so a value or error property in the payload was attacker-controlled. An application that dispatches operations from the validated request body could then act on data that never satisfied the route schema, leading to unauthorized state changes or disclosure. Reaching the vulnerable path requires the route to use an $async request schema. Patches Fastify no longer treats an asynchronous validation result as a { value, error } wrapper: an async…
Recommended action: Upgrade to 5.12.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Fastify routes a malformed URL under one plugin prefix to the custom not-found handler of a different sibling plugin, invoking the handler registered last and skipping the preHandler declared in its setNotFoundHandler(). When the request method has no route in the main router, a malformed request target reaches Fastify's internal not-found router before URL decoding and is dispatched through a single shared handler pointer, regardless of prefix and without the normal request lifecycle. An unauthenticated request to a public prefix can therefore reach an authentication-protected not-found handler registered under a different prefix and receive its full response, breaking prefix encapsulation and bypassing the authentication hook. Applications whose private or tenant fallbacks return protected data from a not-found handler are affected. Patches Patched in fastify 5.12.2. Malformed URLs are now routed through the configured onBadUrl and onMaxParamLength handlers so they fail…
Recommended action: Upgrade to 5.12.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 5.12.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Fastify lowercases header-schema property names before compiling the schema, because Node.js stores request header names in lowercase. That normalization was incomplete: it lowercased only top-level properties keys and the root required array, and did not lowercase the JSON Schema Draft 7 dependencies keyword (its trigger keys and dependent property names) or names in nested subschemas. As a result, a header schema that uses dependencies to require one header when another is present (for example X-Admin requiring X-Admin-Token) never matches the lowercased request headers, so the dependency assertion is silently skipped. An unauthenticated remote client can send the header that activates a privileged path while omitting the header the dependency was meant to require, bypassing a schema-enforced security control. The header schema is idiomatic, valid JSON Schema Draft 7, and no custom validator, malformed request, or misconfiguration is required. Patches Header-schema names are…
Recommended action: Upgrade to 5.12.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The fix for CVE-2026-3635 (GHSA-444r-cwp2-x5xf) added a proxyFn(socket.remoteAddress, 0) guard on the X-Forwarded- reads in request.host, request.protocol, request.hostname, request.ip, and request.ips. 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 (trustProxy: <number) compiles to a predicate that structurally ignores the address argument, so the guard reduces to 0 < tp, always true for any tp = 1. Applications configured with trustProxy: <number (documented as "behind N reverse proxies", trustProxy: 1 being the canonical single-proxy setting) remain vulnerable. An attacker who can reach the Fastify origin directly, bypassing the front-facing proxy, can spoof the request fields exactly as in the unpatched version. Impact class matches the parent CVE-2026-3635: host injection in generated URLs, HTTPS-enforcement bypass, secure-cookie /…
Recommended action: Upgrade to 5.12.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact fastify before 5.12.1, when a route uses a root-level primitive body schema (for example an integer with a minimum and maximum) and the default type coercion, validates the coerced value but exposes the original, uncoerced value to the route handler. For example, a JSON body "10" is coerced to the number 10 and passes an integer 1 to 10 schema, but request.body stays the string "10". An application that trusts the validated type is handed a value that did not satisfy the schema, which can bypass limits the application enforces on that typed value. Object and array body schemas are not affected, they coerce their members in place. Patches Upgrade to fastify 5.12.1. Workarounds Until you can upgrade, avoid relying on the validated type of a root primitive body. Wrap the value in an object schema (object properties are coerced in place), for example accept { "value": 10 } and read request.body.value, or re-check the type in the handler.
Recommended action: Upgrade to 5.12.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact In applications that specify different validation strategies for different content types, it's possible to bypass the validation by providing a _slightly altered_ content type such as with different casing or altered whitespacing before `;`. Users using the the following pattern are affected: ```js fastify.post('/', { handler(request, reply) { reply.code(200).send(request.body) }, schema: { body: { content: { 'application/json': { schema: { type: 'object', properties: { 'foo': { type: 'string', } }, required: ['foo'] } }, } } } }) ``` User using the following pattern are not affected: ```js fastify.post('/', { handler(request, reply) { reply.code(200).send(request.body) }, schema: { body: { type: 'object', properties: { 'foo': { type: 'string', } }, required: ['foo'] } } }) ``` Patches This was patched in v5.3.1, but unfortunately it did not cover all problems. This has been fully patched in v5.3.2. Version v4.9.0 was also affected by this issue. This has been…
Recommended action: Upgrade to 5.3.2 or 4.29.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When trustProxy is configured with a restrictive trust function (e.g., a specific IP like trustProxy: '10.0.0.1', a subnet, a hop count, or a custom function), the request.protocol and request.host getters read X-Forwarded-Proto and X-Forwarded-Host headers from any connection — including connections from untrusted IPs. This allows an attacker connecting directly to Fastify (bypassing the proxy) to spoof both the protocol and host seen by the application. Affected Versions fastify <= 5.8.2 Impact Applications using request.protocol or request.host for security decisions (HTTPS enforcement, secure cookie flags, CSRF origin checks, URL construction, host-based routing) are affected when trustProxy is configured with a restrictive trust function. When trustProxy: true (trust everything), both host and protocol trust all forwarded headers — this is expected behavior. The vulnerability only manifests with restrictive trust configurations.
Recommended action: Upgrade to 5.8.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Fastify incorrectly accepts malformed Content-Type headers containing trailing characters after the subtype token, in violation of RFC 9110 §8.3.1. For example, a request sent with Content-Type: application/json garbage passes validation and is processed normally, rather than being rejected with 415 Unsupported Media Type. When regex-based content-type parsers are in use (a documented Fastify feature), the malformed value is matched against registered parsers using the full string including the trailing garbage. This means a request with an invalid content-type may be routed to and processed by a parser it should never have reached. Impact An attacker can send requests with RFC-invalid Content-Type headers that bypass validity checks, reach content-type parser matching, and be processed by the server. Requests that should be rejected at the validation stage are instead handled as if the content-type were valid. Workarounds Deploy a WAF rule to protect against this Fix The…
Recommended action: Upgrade to 5.8.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A Denial of Service vulnerability in Fastify’s Web Streams response handling can allow a remote client to exhaust server memory. Applications that return a ReadableStream (or Response with a Web Stream body) via reply.send() are impacted. A slow or non-reading client can trigger unbounded buffering when backpressure is ignored, leading to process crashes or severe degradation. Patches The issue is fixed in Fastify 5.7.3. Users should upgrade to 5.7.3 or later. Workarounds Avoid sending Web Streams from Fastify responses (e.g., ReadableStream or Response bodies). Use Node.js streams (stream.Readable) or buffered payloads instead until the project can upgrade. References - https://hackerone.com/reports/3524779
Recommended action: Upgrade to 5.7.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A validation bypass vulnerability exists in Fastify where request body validation schemas specified by Content-Type can be completely 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. For example, a request with Content-Type: application/json\ta will bypass JSON schema validation but still be parsed as JSON. This vulnerability affects all Fastify users who rely on Content-Type-based body validation schemas to enforce data integrity or security constraints. The concrete impact depends on the handler implementation and the level of trust placed in the validated request body, but at the library level, this allows complete bypass of body validation for any handler using Content-Type-discriminated schemas. This issue is a regression or missed edge case from the fix for a previously reported vulnerability. Patches This…
Recommended action: Upgrade to 5.7.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The attacker can use the incorrect Content-Type to bypass the Pre-Flight checking of fetch. fetch() requests with Content-Type’s essence as "application/x-www-form-urlencoded", "multipart/form-data", or "text/plain", could potentially be used to invoke routes that only accepts application/json content type, thus bypassing any CORS protection, and therefore they could lead to a Cross-Site Request Forgery attack. Patches For 4.x users, please update to at least 4.10.2 For 3.x users, please update to at least 3.29.4 Workarounds Implement Cross-Site Request Forgery protection using @fastify/csrf. References Check out the HackerOne report: https://hackerone.com/reports/1763832. For more information Fastify security policy
Recommended action: Upgrade to 4.10.2 or 3.29.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact An attacker can send an invalid Content-Type header that can cause the application to crash, leading to a possible Denial of Service attack. Only the v4.x line is affected. (This was updated: upon a close inspection, v3.x is not affected after all). Patches Yes, update to v4.8.0. Workarounds You can reject the malicious content types before the body parser enters in action. References See the HackerOne report #1715536 For more information Fastify security policy
Recommended action: Upgrade to 4.8.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A denial of service vulnerability exists in Fastify v2.14.1 and v3.0.0-rc.4 that allows a malicious user to trigger resource exhaustion (when the allErrors option is used) with specially crafted schemas.
Recommended action: Upgrade to 2.15.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Affected versions of fastify are vulnerable to a denial of service when processing a request with Content-Type set to application/json and a very large payload. Recommendation Update to version 0.38.0 or later.
Recommended action: Upgrade to 0.38.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.