NestJS @nestjs/microservices remote process termination via deeply nested message patterns

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 the service on demand; other transports are not affected because their patterns arrive as strings. This issue is fixed in versions 11.2.4 and 12.0.2.

• The affected package is @nestjs/microservices in Nest:
• < 11.2.4: affected; 11.2.4 is the release identified as fixed for this branch.
• >= 12.0.0, < 12.0.2: affected; 12.0.2 is the release identified as fixed for this branch.
• The affected processing path is the TCP and RabbitMQ transport, specifically ServerTCP#handleMessage and ServerRMQ#handleMessage.
• Other transports are not affected according to the advisory because their patterns arrive as strings.
• Do not infer the status of parallel or later branches outside these ranges without checking them separately.

NestJS @nestjs/microservices processes message patterns in ServerTCP#handleMessage and ServerRMQ#handleMessage. For a client-controlled non-string pattern, the vulnerable code passes the value to JSON.stringify to derive the handler lookup key. Sufficiently deep object nesting causes recursive serialization to throw RangeError: Maximum call stack size exceeded; the resulting rejection from handleMessage is not handled and terminates the Node.js process under its default behavior. Exploitation requires the attacker to deliver a message to the TCP transport or publish to a RabbitMQ queue or exchange consumed by the service. The TCP transport has no authentication by default, while RabbitMQ still requires the ability or permission to publish under the deployment's broker controls. Other transports are outside the described path because their patterns arrive as strings, and the available evidence does not establish one universal safe nesting threshold across runtimes and object shapes.

The issue is network reachable and requires no user interaction. The normalized record characterizes the attack complexity as low and the attack as requiring no privileges; the maintainer advisory states that the TCP transport has no authentication by default, while RabbitMQ requires the ability to publish to the consumed queue or exchange. The advisory includes a public proof of concept and describes a single message causing a crash that can be repeated. The record confirms a public exploit but does not establish exploitation in the wild, a specific campaign, or indicators of compromise.

The technical outcome is remote termination of the microservice process, causing an availability failure rather than data disclosure or data modification. The normalized record describes a network attack with no user interaction and no additional authentication requirement for the TCP transport when default settings remain in place. For RabbitMQ, the attacker must be able to publish to the queue or exchange consumed by the service. The affected scope is limited to microservices using TCP or RabbitMQ and the processes handling those transports; other transports do not use the same pattern serialization path. Realistic organisational consequences include failed requests, workload restarts, and unprocessed messages while the service is down. The available evidence does not establish confidentiality or integrity impact.

The confirmed consequence is loss of microservice availability: one malformed message can stop the process, and the condition is repeatable. The deployment may need supervisor or orchestration recovery, while requests and messages handled by the process can be interrupted. For RabbitMQ consumers, the triggering message does not complete successfully on vulnerable versions. The record does not identify a confidentiality or integrity impact. The duration and breadth of disruption depend on the deployment's health checks, restart policy, and workload distribution.

1. Upgrade @nestjs/microservices to the exact confirmed fixed release for the deployed branch: 11.2.4 for the branch affected below 11.2.4, or 12.0.2 for the branch affected by >= 12.0.0, < 12.0.2.
2. If an upgrade is not immediately possible, restrict network access to the TCP transport and restrict publishing to the RabbitMQ queue or exchange so that only trusted peers can send messages.
3. The advisory lists running Node.js with --unhandled-rejections=warn as a temporary measure to prevent the process crash. It leaves the message unprocessed and is not a substitute for the security fix.
4. After remediation, verify that the intended package version is actually loaded and review the exposure of the relevant TCP ports, queues, and exchanges.

1. Inventory @nestjs/microservices in each NestJS application and compare deployed versions with the affected ranges in affected_summary.
2. Identify applications that enable the TCP or RabbitMQ transport, then check which networks can reach the TCP port and which principals can publish to the relevant RabbitMQ queue or exchange.
3. Review application logs, process supervisors, and orchestration events for RangeError: Maximum call stack size exceeded, unhandled promise rejections, or unexpected process exits occurring during inbound message handling.
4. For RabbitMQ deployments, review consumer or message-failure events near process restarts as an additional precaution, not as a confirmed CVE-specific indicator.
5. Absence of these events does not prove safety; version and transport inventory are the primary checks.