GHSA-r4wm-x892-vjmx Nest has a Fastify URL Encoding Middleware Bypass

• npm @nestjs/platform-fastify: < 11.1.14 → fixed in 11.1.14

Impact _What kind of vulnerability is it? Who is impacted?_ A NestJS application using `@nestjs/platform-fastify` can allow bypass of any middleware when Fastify path-normalization options (e.g., `ignoreTrailingSlash`, `ignoreDuplicateSlashes`, `useSemicolonDelimiter`) are enabled. In affected route-scoped middleware setups, variant paths may skip middleware checks while still reaching the protected handler. The bug is a path canonicalization mismatch between middleware matching and route matching in Nest’s Fastify adapter. Nest passes Fastify routerOptions (such as `ignoreTrailingSlash`, `ignoreDuplicateSlashes`, `useSemicolonDelimiter`) to the Fastify router in packages/platform-fastify/adapters/fastify-adapter.ts:253. But middleware execution is decided by a separate regex check over `req.originalUrl` in packages/platform-fastify/adapters/fastify-adapter.ts:706 and packages/platform-fastify/adapters/fastify-adapter.ts:713. If that regex does not match, Nest does `next()` and skips the middleware (packages/platform-fastify/adapters/fastify-adapter.ts:714), while Fastify may still normalize the same path and route it to the protected handler. So the vulnerability exists because security checks (middleware) and request dispatch(router) use different URL interpretations. This is a fail-open design issue (inconsistent normalization), not just a bad app config: non-default router options make the mismatch reachable. Patches Fixed in `@nestjs/[email protected]` References Credit goes to Fluidattacks (Cristian Vargas) https://fluidattacks.com/advisories/neton