Nest: Unbounded memory growth in the NestJS TCP microservice transport
## Summary
A peer that can open a TCP connection to a NestJS microservice using the built-in TCP
transport can make the server process allocate memory without limit, on either side of the
connection, until the process is killed by the OS or by its container memory limit. No
authentication, no credentials, and no valid message are required.
Applications are affected only if they start a microservice with `Transport.TCP` and the
transport's port is reachable by an untrusted peer.
## Affected versions
| Package | Affected | Patched |
|---|---|---|
| `@nestjs/microservices` | `>= 12.0.0, < 12.0.3` | **12.0.3** |
| `@nestjs/microservices` | `
Nest: Remote process termination via a deeply nested microservice message pattern
Nest is a framework for building scalable Node.js server-side applications. Prior to 11.2.4 and 12.0.2, a single message with a deeply nested object in its pattern can terminate a NestJS microservice using the TCP or RabbitMQ transport. ServerTCP#handleMessage and ServerRMQ#handleMessage pass a client-controlled non-string pattern to JSON.stringify to derive the handler lookup key; sufficiently deep nesting throws RangeError: Maximum call stack size exceeded, and the unhandled promise rejection terminates Node.js under its default behavior. An attacker who can reach the TCP port or publish to the consumed RabbitMQ queue or exchange can crash
Nest: DoS via Recursive handleData in JsonSocket (TCP Transport)
Nest is a framework for building scalable Node.js server-side applications. Prior to 11.1.19, when an attacker sends many small, valid JSON messages in one TCP frame, handleData() recurses once per message; the buffer shrinks each call. maxBufferSize is never reached; call stack overflows instead. A ~47 KB payload is sufficient to trigger RangeError. This vulnerability is fixed in 11.1.19.