Impact What kind of vulnerability is it? Who is impacted?

SseStream.transform() interpolates message.type and message.id directly into Server-Sent Events text protocol output without sanitizing newline characters (\r, \n). Since the SSE protocol treats both \r and \n as field delimiters and \n\n as event boundaries, an attacker who can influence these fields through upstream data sources can inject arbitrary SSE events, spoof event types, and corrupt reconnection state. Spring Framework's own security patch (6e97587) validates these same fields (id, event) for the same reason.

Actual impact:

- Event spoofing: Attacker forges SSE events with arbitrary event: types, causing client-side EventSource.addEventListener() callbacks to fire for wrong event types. - Data injection: Attacker injects arbitrary data: payloads, potentially triggering XSS if the client renders SSE data as HTML without sanitization. - Reconnection corruption: Attacker injects id: fields, corrupting the Last-Event-ID header on reconnection, causing the client to miss or replay events. - Attack precondition: Requires the developer to map user-influenced data to the type or id fields of SSE messages. Direct HTTP request input does not reach these fields without developer code bridging the gap. - Patches Has the problem been patched? What versions should users upgrade to?

Patched in @nestjs/core@11.1.18

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/platform-fastify@11.1.14

References

Credit goes to Fluidattacks (Cristian Vargas) https://fluidattacks.com/advisories/neton

Impact Attacker sends many small, valid JSON messages in one TCP frame → handleData() recurses once per message; buffer shrinks each call → maxBufferSize is never reached; call stack overflows instead → A ~47 KB payload is sufficient to trigger RangeError

Patches

Fixed in @nestjs/microservices@11.1.19

References

Discovered by https://github.com/hwpark6804-gif

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

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.

Patches

Patched in @nestjs/platform-fastify@11.1.11

Resources

Credit goes to Hacktron AI for reporting this issue.