GHSA-96h4-vgxj-gvm2

## 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` | `< 11.2.5` | **11.2.5** | The same code is present in the 10.x line and earlier. Those lines are end-of-life and will not receive a patch; upgrade to a supported major. Only `@nestjs/microservices` is affected. No other package needs updating for this issue. ## Details Two independent paths let one peer grow the heap without bound. ### Partial packets are buffered with nothing to reap them The TCP transport frames messages as `<length>#<payload>`. A peer may declare a length, send part of the payload, and then stop. `JsonSocket` keeps the partial payload buffered while it waits for the rest, and nothing ever reclaimed it: there was no socket timeout, no cap on the number of connections, and no tracking of accepted sockets. `maxBufferSize` did not close this. It caps a single connection, defaulting to 128M characters, and is enforced per connection, so the effective ceiling was the number of connections an attacker chose to open. Ten connections that each send 20MB and then go silent: | | rss | heapUsed | |---|---|---| | baseline | 152.3MB | 28.1MB | | after 200MB sent, all stalled | 561.2MB | 229.5MB | The memory was held for as long as the connections stayed open. Closing them released it, so a peer could hold it indefinitely at negligible cost to itself. ### Response backpressure was ignored `JsonSocket#handleSend`