Fastify 5.12.2 and 5.12.5: Five Bypass and Crash Bugs, Each With a Trigger

On 4 September 2026 Fastify released 5.12.2 and published four High rated advisories: an authentication bypass through malformed URLs and three ways around request schema validation. On 16 September it released 5.12.5 and disclosed a fifth issue, a process crash when response trailers are used over HTTP/2. The GitHub Advisory Database added all five on 30 September.

Fastify leans on JSON Schema for request validation, and teams often treat a route's schema as part of its security boundary. These advisories show where that assumption broke. The good news is that each one needs a recognizable pattern in your code, so you can check exposure quickly.

What's affected

Malformed URLs reach the wrong not-found handler (CVE-2026-76169). When the request method had no route in the main router, a malformed request target was sent through a single shared not-found handler, regardless of prefix and without the normal request lifecycle. A request under a public prefix could hit an authentication-protected not-found handler registered under another prefix, skipping the preHandler declared in setNotFoundHandler(). The advisory is explicit that a global onRequest auth hook does not help, because the malformed-URL path skips it. Affected from Fastify 4.0.0; the advisory lists 5.12.2 as the fix and no 4.x release.

Boolean false schemas ignored (CVE-2026-84469). JSON Schema treats false as "reject everything". Fastify checked schemas for JavaScript truthiness, so a route with body: false or querystring: false got no validator at all, and any input reached the handler.

Header dependencies skipped (CVE-2026-84428). Fastify lowercases header schema names because Node.js lowercases incoming header names. It only did this for top-level properties and required. A schema saying "X-Admin requires X-Admin-Token" through dependencies never matched, so a client could send X-Admin alone.

$async results unwrapped (CVE-2026-84504). Fastify unwraps validator results shaped as value-plus-error objects, a convention meant for synchronous custom compilers. An $async JSON Schema validator resolves with the data itself, so a payload containing a value property replaced the whole request part with attacker-chosen content before the handler ran.

HTTP/2 trailers crash (CVE-2026-92081). Setting a trailer made Fastify add Transfer-Encoding: chunked, which HTTP/2 forbids. Node.js threw, nothing caught it, and the process exited. One unauthenticated request was enough.

Fastify 5.12.1, released in August, had already fixed two related issues that reached the GitHub Advisory Database on 2 September: X-Forwarded-* spoofing with numeric trustProxy (CVE-2026-16732) and a root primitive body coercion mismatch (CVE-2026-18504).

How to check if you're exposed

Check the version, including copies pulled in by frameworks built on Fastify:

npm ls fastify --all

Then grep for each trigger:

# CVE-2026-76169: prefixed not-found handlers
grep -rn "setNotFoundHandler" src/

# CVE-2026-84469: deny-all boolean schemas
grep -rnE "(body|querystring|query|params|headers):\s*false" src/

# CVE-2026-84428: header schemas with dependencies
grep -rnE "dependencies|dependentRequired|dependentSchemas" src/ | grep -iv package

# CVE-2026-84504: async schemas
grep -rn "\$async" src/

# CVE-2026-92081: HTTP/2 plus trailers
grep -rnE "http2:\s*true" src/
grep -rn "reply.trailer\|\.trailer(" src/

For CVE-2026-76169, open each setNotFoundHandler hit and ask whether its response includes anything a logged-out user shouldn't see, such as tenant data, a dashboard shell or an internal error page. A plain 404 body is not interesting. A "smart" fallback that renders an authenticated SPA shell or looks up records is.

What to do now

1. Upgrade to Fastify 5.12.5 or later. That covers all five. If you're on Fastify 4, plan the migration; the advisories list no 4.x fix for the not-found bypass.
2. Don't serve protected data from not-found handlers. Return a plain 404 and keep authenticated logic in real routes.
3. Replace boolean false schemas with an explicit always-failing schema, which the advisory suggests writing as not with an empty schema, or block the route in an onRequest hook.
4. Write header schema names in lowercase everywhere, and inline header schemas rather than referencing them with a shared $ref. The fix doesn't reach shared references and now emits an FSTSEC002 startup warning for them.
5. Enforce authorization in hooks, not only in schemas. Schema validation shapes input. It shouldn't be the only thing deciding who may act.
6. Reject malformed request targets at the proxy in front of Fastify, as the advisory suggests for the not-found bypass.

Why it matters

All five bugs share a theme: a security decision that depended on a framework detail working exactly as the developer assumed. Truthiness versus presence. Case-sensitive keys in a case-insensitive protocol. A result convention meant for one kind of validator applied to another. None of these would show up in a typical functional test, because the happy path works.

They also show why reachability matters for frameworks. Every Fastify app pulls in the vulnerable code, but only apps using those specific patterns can be reached. A grep pass is enough to separate "upgrade this week with the rest" from "upgrade today and check the logs".

Try it yourself

Write a pull request check that runs the grep block above and posts the hits as a comment. Run it once on your main branch to get a baseline, then keep it on so new setNotFoundHandler or boolean-false schema patterns get a second look in review.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• GHSA-p68q-wchp-6fh7: auth bypass via malformed URLs and not-found handlers
• GHSA-hwr6-493r-vm6h: boolean false schemas skipped
• GHSA-9q9j-q6p8-xq58: header schema case normalization
• GHSA-667r-xxjv-c9mm: async validation result collision
• GHSA-4mh8-r7rc-xpvc: HTTP/2 trailer crash
• GHSA-3m5p-2c4r-xxw2: X-Forwarded spoofing with numeric trustProxy
• fastify on npm