Package Instance

Nest Fastify HEAD Request Middleware Bypass
### Impact

In a NestJS application using `@nestjs/platform-fastify`, GET middleware can be bypassed because Fastify automatically redirects HEAD requests to the corresponding GET handlers (if they exist).

As a result:

- Middleware will be completely skipped.
- The HTTP response won't include a body (since the response is truncated when redirecting a HEAD request to a GET handler).
- The actual handler will still be executed.

### Patches

Fixed in `@nestjs/platform-fastify@11.1.16`

Duplicate Advisory: Nest has a Fastify URL Encoding Middleware Bypass
## Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-r4wm-x892-vjmx. This link is maintained to preserve external references.

## Original Description

A NestJS application using @nestjs/platform-fastify can allow bypass of authentication/authorization middleware when Fastify path-normalization options are enabled.



This issue affects nest.Js: 11.1.13.

Nest has a Fastify URL Encoding Middleware Bypass
_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.

Nest has a Fastify URL Encoding Middleware Bypass (TOCTOU)
A NestJS application is vulnerable if it meets all of the following criteria:

1. Platform: Uses `@nestjs/platform-fastify`.
2. Security Mechanism: Relies on `NestMiddleware` (via `MiddlewareConsumer`) for security checks (authentication, authorization, etc.), or through `app.use()`
3. Routing: Applies middleware to specific routes using string paths or controllers (e.g., `.forRoutes('admin')`).
Example Vulnerable Config:

```ts
// app.module.ts
export class AppModule implements NestModule {
configure(consumer: MiddlewareConsumer) {
consumer
.apply(AuthMiddleware) // Security check
.forRoutes('admin');   // Vulnerable: Path-based restriction
}
}
```

Attack Vector:

- Target Route: `/admin`
- Middleware Path: `admin`
- Attack Request: `GET /%61dmin`
- Result: Middleware is skipped (no match on `%61dmin`), but controller for `/admin` is executed.

Consequences:

- Authentication Bypass: Unauthenticated users can access protected routes.
- Authorization Bypass: Restricted administrative endpoints become accessible to lower-privileged users.
- Input Validation Bypass: Middleware performing sanitization or validation can be skipped.