GHSA-M8VH-JMQ9-5RJG
Vulnerability from github – Published: 2026-09-29 23:54 – Updated: 2026-09-29 23:54| Field | Value |
|---|---|
| Ecosystem | npm |
| Package | @nestjs/microservices |
| Affected versions | >= 12.0.0, < 12.0.2 and < 11.2.4 |
| Patched versions | 12.0.2 and 11.2.4 (upgrade to 12.0.3 / 11.2.5) |
Summary
A single message whose pattern is a deeply nested object terminates a NestJS microservice that uses the TCP or
RabbitMQ transport. The server serialized the client-supplied pattern with JSON.stringify to derive the handler
lookup key; on deeply nested input this throws RangeError: Maximum call stack size exceeded. The exception escaped
the asynchronous message handler as an unhandled promise rejection, which terminates the Node.js process under the
default --unhandled-rejections=throw.
Impact
Denial of service, one message per crash, repeatable. The attacker needs to be able to reach the transport: connect to the TCP transport's port, or publish to the queue or exchange the service consumes from. The TCP transport performs no authentication by default, so on a reachable port this requires nothing else.
Only the TCP and RabbitMQ transports are affected. The other transports take the pattern as a string from the broker topic or channel and never serialize a client-supplied object to build it.
Details
In ServerTCP#handleMessage and ServerRMQ#handleMessage the pattern was stringified without a guard:
const pattern = isString(packet.pattern)
? packet.pattern
: JSON.stringify(packet.pattern);
JSON.parse accepts nesting depths that JSON.stringify cannot re-serialize, because JSON.stringify recurses
natively, so an attacker can craft a payload that parses successfully on arrival and then throws when the pattern is
converted back to a string. Neither transport attached a rejection handler to the promise returned by
handleMessage, so the RangeError propagated out as an unhandled rejection.
Proof of concept
Against a NestJS microservice on the TCP transport (default port 3001). The nested JSON is built as text rather than
with JSON.stringify, which is what makes the payload serializable by the attacker but not by the victim:
const { connect } = require('node:net');
const DEPTH = 100_000;
const pattern = '{"nested":'.repeat(DEPTH) + '{}' + '}'.repeat(DEPTH);
const payload = `{"pattern":${pattern},"data":null,"id":"1"}`;
const socket = connect(3001, '127.0.0.1', () => {
// Nest's TCP framing is <byteLength>#<json>
socket.write(`${Buffer.byteLength(payload)}#${payload}`);
});
The service exits with RangeError: Maximum call stack size exceeded. The equivalent payload published to the
consumed queue crashes a RabbitMQ-transport service.
Patches
Fixed in 12.0.2 and 11.2.4.
- Incoming patterns are converted through a guarded
Server#getPatternAsString, which falls back to a sentinel value that matches no handler. Such a message now receives the ordinary "no message handler" response (TCP) or is negatively acknowledged (RabbitMQ) instead of crashing the process. - Rejections escaping
handleMessagein both transports are routed tohandleErrorrather than left unhandled.
Workarounds
If you cannot upgrade, restrict network access to the transport so that only trusted peers can reach it. Running the
process with --unhandled-rejections=warn prevents the crash but leaves the message unprocessed and is not a
substitute for the fix.
Credit
Reported by ZeroVuln Labs.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@nestjs/microservices"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "11.2.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@nestjs/microservices"
},
"ranges": [
{
"events": [
{
"introduced": "12.0.0"
},
{
"fixed": "12.0.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-102281"
],
"database_specific": {
"cwe_ids": [
"CWE-248",
"CWE-674"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-29T23:54:44Z",
"nvd_published_at": "2026-09-28T22:17:32Z",
"severity": "HIGH"
},
"details": "| Field | Value |\n| --- | --- |\n| Ecosystem | npm |\n| Package | `@nestjs/microservices` |\n| Affected versions | `\u003e= 12.0.0, \u003c 12.0.2` and `\u003c 11.2.4` |\n| Patched versions | `12.0.2` and `11.2.4` (upgrade to `12.0.3` / `11.2.5`) |\n\n### Summary\n\nA single message whose `pattern` is a deeply nested object terminates a NestJS microservice that uses the TCP or\nRabbitMQ transport. The server serialized the client-supplied pattern with `JSON.stringify` to derive the handler\nlookup key; on deeply nested input this throws `RangeError: Maximum call stack size exceeded`. The exception escaped\nthe asynchronous message handler as an unhandled promise rejection, which terminates the Node.js process under the\ndefault `--unhandled-rejections=throw`.\n\n### Impact\n\nDenial of service, one message per crash, repeatable. The attacker needs to be able to reach the transport: connect\nto the TCP transport\u0027s port, or publish to the queue or exchange the service consumes from. The TCP transport\nperforms no authentication by default, so on a reachable port this requires nothing else.\n\nOnly the **TCP** and **RabbitMQ** transports are affected. The other transports take the pattern as a string from the\nbroker topic or channel and never serialize a client-supplied object to build it.\n\n### Details\n\nIn `ServerTCP#handleMessage` and `ServerRMQ#handleMessage` the pattern was stringified without a guard:\n\n```ts\nconst pattern = isString(packet.pattern)\n ? packet.pattern\n : JSON.stringify(packet.pattern);\n```\n\n`JSON.parse` accepts nesting depths that `JSON.stringify` cannot re-serialize, because `JSON.stringify` recurses\nnatively, so an attacker can craft a payload that parses successfully on arrival and then throws when the pattern is\nconverted back to a string. Neither transport attached a rejection handler to the promise returned by\n`handleMessage`, so the `RangeError` propagated out as an unhandled rejection.\n\n### Proof of concept\n\nAgainst a NestJS microservice on the TCP transport (default port 3001). The nested JSON is built as text rather than\nwith `JSON.stringify`, which is what makes the payload serializable by the attacker but not by the victim:\n\n```js\nconst { connect } = require(\u0027node:net\u0027);\n\nconst DEPTH = 100_000;\nconst pattern = \u0027{\"nested\":\u0027.repeat(DEPTH) + \u0027{}\u0027 + \u0027}\u0027.repeat(DEPTH);\nconst payload = `{\"pattern\":${pattern},\"data\":null,\"id\":\"1\"}`;\n\nconst socket = connect(3001, \u0027127.0.0.1\u0027, () =\u003e {\n // Nest\u0027s TCP framing is \u003cbyteLength\u003e#\u003cjson\u003e\n socket.write(`${Buffer.byteLength(payload)}#${payload}`);\n});\n```\n\nThe service exits with `RangeError: Maximum call stack size exceeded`. The equivalent payload published to the\nconsumed queue crashes a RabbitMQ-transport service.\n\n### Patches\n\nFixed in **12.0.2** and **11.2.4**.\n\n- Incoming patterns are converted through a guarded `Server#getPatternAsString`, which falls back to a sentinel value\n that matches no handler. Such a message now receives the ordinary \"no message handler\" response (TCP) or is\n negatively acknowledged (RabbitMQ) instead of crashing the process.\n- Rejections escaping `handleMessage` in both transports are routed to `handleError` rather than left unhandled.\n\n### Workarounds\n\nIf you cannot upgrade, restrict network access to the transport so that only trusted peers can reach it. Running the\nprocess with `--unhandled-rejections=warn` prevents the crash but leaves the message unprocessed and is not a\nsubstitute for the fix.\n\n### Credit\n\nReported by ZeroVuln Labs.",
"id": "GHSA-m8vh-jmq9-5rjg",
"modified": "2026-09-29T23:54:44Z",
"published": "2026-09-29T23:54:44Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nestjs/nest/security/advisories/GHSA-m8vh-jmq9-5rjg"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-102281"
},
{
"type": "WEB",
"url": "https://github.com/nestjs/nest/pull/17737"
},
{
"type": "WEB",
"url": "https://github.com/nestjs/nest/commit/aa97b5144d8dff1ce700aac521eb86449a679d6f"
},
{
"type": "WEB",
"url": "https://github.com/nestjs/nest/commit/e9dcd4c7ac64361fbfe79461da85f5b3fc3e02da"
},
{
"type": "PACKAGE",
"url": "https://github.com/nestjs/nest"
},
{
"type": "WEB",
"url": "https://github.com/nestjs/nest/releases/tag/v11.2.4"
},
{
"type": "WEB",
"url": "https://github.com/nestjs/nest/releases/tag/v12.0.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Nest: Remote process termination via a deeply nested microservice message pattern"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.