---
id: "GHSA-fvjq-6m4v-mw3m"
page: "https://infrastack.ai/live/GHSA-fvjq-6m4v-mw3m"
kind: "vulnerability"
aliases: ["GHSA-fvjq-6m4v-mw3m"]
title: "Path-scoped middleware bypass on Fastify via absolute-form request targets with a query before the path"
severity: "high"
cvss: null
epss: null
exploited: false
status: "open"
category: "package"
products: [{"name": "@nestjs/platform-fastify", "fixed": ["12.4.1"], "affected": ">= 12.0.0, < 12.4.1", "ecosystem": "npm"}, {"name": "@nestjs/platform-fastify", "fixed": ["11.2.9"], "affected": "< 11.2.9", "ecosystem": "npm"}]
ecosystems: ["npm"]
tags: ["cwe-288", "cwe-436", "fastify", "nestjs", "node", "package", "self-hosted"]
not_affected_if: ["auth-in-guards", "default-fastify-12", "origin-form-proxy"]
published_at: "2026-11-12T13:53:55+00:00"
first_seen_at: "2026-11-12T13:56:25+00:00"
updated_at: "2026-11-12T13:57:24+00:00"
sources: [{"source": "ghsa-repo", "url": "https://github.com/nestjs/nest/security/advisories/GHSA-fvjq-6m4v-mw3m", "first_seen_at": "2026-11-12T13:56:25+00:00"}]
exploit_sources: []
---

# Path-scoped middleware bypass on Fastify via absolute-form request targets with a query before the path

Link for people: https://infrastack.ai/live/GHSA-fvjq-6m4v-mw3m (this .md is for agents)

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.

_Summary, check and fix written by a model from the sources; labelled as such._

## Affected

- npm:@nestjs/platform-fastify affected >= 12.0.0, < 12.4.1 fixed 12.4.1
- npm:@nestjs/platform-fastify affected < 11.2.9 fixed 11.2.9

## How to check

- Run `npm ls @nestjs/platform-fastify` to see the installed version.
- Check whether the app uses `MiddlewareConsumer.forRoutes(...)` or `.exclude(...)` for auth checks.
- For 12.x, run `npm ls fastify` and `npm ls find-my-way` to see whether an older router is pinned.
- Check whether a reverse proxy forwards absolute-form request targets to the app.

## Fix

- `@nestjs/platform-fastify` `11.2.9` for the 11.x line
- `@nestjs/platform-fastify` `12.4.1` for the 12.x line
- On 12.x, `fastify` `5.12.8` or later, per the workarounds

## Timeline

- 2026-11-12T13:56:25+00:00 ghsa-repo https://github.com/nestjs/nest/security/advisories/GHSA-fvjq-6m4v-mw3m

## Documents

- [advisory] Maintainer's advisory: github.com https://github.com/nestjs/nest/security/advisories/GHSA-fvjq-6m4v-mw3m

## From the sources

| 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) |

### Summary

On 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](https://github.com/nestjs/nest/security/advisories/GHSA-9c5c-9qcx-q35q).

### Impact

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.

- **11.x:** affected with the dependencies 11.2.x installs by default.
- **12.x:** a default install is not affected, because the router bundled with current `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.

### Details

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.

### Patches

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.

### Workarounds

- Forward only origin-form request targets to the application, for example through a reverse proxy.
- On 12.x, use `fastify` 5.12.8 or later.
- Enforce authentication and authorization in guards, which run for the matched route, rather than in middleware.

### Credit

Reported by Salih Caglar Ispirli.

---

_Free to read, with fair use of about 60 pages a minute. For higher limits or API access: sales@infrastack.ai_