GHSA-9c5c-9qcx-q35q

| Field | Value | | --- | --- | | Ecosystem | npm | | Package | `@nestjs/platform-fastify` | | Affected versions | `>= 12.0.0, < 12.0.2` and `< 11.2.4` | | Patched versions | `12.0.2` and `11.2.4` (upgrade to `12.0.3` / `11.2.5`) | ### Summary On the Fastify adapter, an HTTP request that uses an **absolute-form request target** (`GET http://host/path HTTP/1.1` instead of `GET /path HTTP/1.1`) reaches the route handler without running the path-scoped Nest middleware bound to that route. Applications that enforce authentication or authorization in middleware execute the protected handler with those checks skipped. ### Impact Any application that - uses `@nestjs/platform-fastify`, and - binds middleware to specific paths via `MiddlewareConsumer.forRoutes(...)` or `.exclude(...)`, and - is reachable by a client that controls the raw request line. Node's HTTP server accepts absolute-form targets, so no special server configuration is needed. Exposure is reduced when a reverse proxy in front of the application rewrites the request target to origin-form, which most do. Where the bypassed middleware performs authentication or authorization, the result is an authentication or authorization bypass. Where it performs logging, rate limiting or body handling, those are silently skipped instead. ### Details Fastify's router (`find-my-way`) resolves an absolute-form target to its path before matching, so the route handler is dispatched normally. Two places on the middleware side matched against the **raw** request target instead: 1. The bundled copy of the `@fastify/middie` engine at `packages/platform-fastify/adapters/middie/fastify-middie.ts`. NestJS carried this fork to apply an earlier path-decoding fix and it did not track the upstream absolute-form fix released in `@fastify/[email protected]`. 2. `FastifyAdapter`'s own re-check in `createMiddlewareFactory()`, which tests the middleware path regexp against `req.originalUrl`. Both normalized and percent-decoded