@NESTJS/PLATFORM-FASTIFY · GHSA-fvjq-6m4v-mw3m · Package
FIX → 12.4.1 · 11.2.9
The NestJS Fastify adapter can match path-scoped middleware against a different path than the router dispatches to, when a request target places a query string before the path. An attacker can reach a protected route handler without the authentication or authorization middleware running.
first public Nov 12, 2026 · 1 source
Check it with your coding agent
It reads this page and tells you if your code or app is affected.
Applications that run NestJS on the Fastify adapter, enforce auth in path-scoped middleware, and accept requests from clients that control the raw request line. A default 12.x install with current fastify is not affected; 11.2.x installs and apps that pin an older fastify or find-my-way are. A reverse proxy that rewrites targets to origin-form prevents it.
Not affected if auth-in-guards, default-fastify-12, origin-form-proxy
Who cares fastify, nestjs, node, self-hosted
npm ls @nestjs/platform-fastify to see the installed version.MiddlewareConsumer.forRoutes(...) or .exclude(...) for auth checks.npm ls fastify and npm ls find-my-way to see whether an older router is pinned.| Field | Value |
|---|---|
| Ecosystem | npm |
| Package | @nestjs/platform-fastify |
| Affected versions | < 11.2.9 and >= 12.0.0, < 12.4.1 |
| Patched versions | 11.2.9 and 12.4.1 |
| Severity | High |
| CVSS v3.1 | AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N (8.1) |
| CWE | CWE-436 (Interpretation Conflict), CWE-288 (Authentication Bypass Using an Alternate Path or Channel) |
Are you affected?
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
InfraStack checks it against your stack and answers on your report, with the evidence and the fix.
Upgrade to 12.4.1 · 11.2.9
@nestjs/platform-fastify 11.2.9 for the 11.x line@nestjs/platform-fastify 12.4.1 for the 12.x linefastify 5.12.8 or later, per the workaroundsOn the Fastify adapter, a request whose absolute-form request target places a query string between the authority and the path could reach a route handler without running the path-scoped Nest middleware bound to that route. Applications that enforce authentication or authorization in middleware could run the protected handler with those checks skipped. This completes the fix for GHSA-9c5c-9qcx-q35q.
An application is affected if it uses @nestjs/platform-fastify, binds middleware to specific paths with
MiddlewareConsumer.forRoutes(...) or .exclude(...), and is reachable by clients that control the raw request line.
fastify versions resolves such
targets the same way the middleware does. Applications that pin an older fastify or find-my-way are affected.A reverse proxy that rewrites request targets to origin-form before they reach the application prevents the issue.
The adapter and the router derived the path of such a target in different ways, so the middleware was matched against a different path than the one the router dispatched to.
Fixed in 11.2.9 and 12.4.1. The adapter now derives the path the same way current router versions do, and a target it can't resolve unambiguously is answered with 404 on every router version.
fastify 5.12.8 or later.Reported by Salih Caglar Ispirli.