GHSA-CQGH-8P3P-MX4M
Vulnerability from github – Published: 2026-10-07 20:42 – Updated: 2026-10-07 20:42Summary
com.rabbitmq.tools.json.JSONReader.read() never returns when its input ends inside a quoted string or a // line comment. Both scanners walk the input with StringCharacterIterator.next() but only compare against a delimiter, so once the iterator reaches CharacterIterator.DONE () they loop forever. The string scanner (string(), line 210, while (c != sep)) also appends to a StringBuilder every iteration, so it fills the heap and throws OutOfMemoryError, taking down the JVM. The comment scanner (skipWhiteSpace(), lines 89-92, while (c != '\n')) pins a thread at 100% CPU with no allocation.
This is reachable with a single message. JsonRpcServer and JsonRpcClient fall back to DefaultJsonRpcMapper whenever no mapper is passed (JsonRpcServer.java:84 and :114, JsonRpcClient.java:186), and that mapper hands the raw message body straight to JSONReader.read() (DefaultJsonRpcMapper.java:42 for the server request, :52 for the client reply). A caller that can publish to the RPC request queue hangs the server; a malicious or MITM'd JSON-RPC service does the same to a client.
Proof of concept
Against amqp-client 5.36.0 from Maven Central:
import com.rabbitmq.tools.jsonrpc.DefaultJsonRpcMapper;
public class Poc {
public static void main(String[] args) {
DefaultJsonRpcMapper mapper = new DefaultJsonRpcMapper();
mapper.parse("{\"method\":\"x", String.class); // unterminated string
// mapper.parse("//", String.class); // unterminated // comment
System.out.println("unreachable");
}
}
java -Xmx64m -cp amqp-client-5.36.0.jar:. Poc throws OutOfMemoryError: Java heap space in about 0.1s and never prints. Swapping in the // line spins at 100% CPU and never returns. A well-formed body such as {"method":"x"} returns immediately.
Impact
Availability. One small, unauthenticated message stops a JSON-RPC endpoint: the unterminated string exhausts the heap, the unterminated comment pins a thread forever. Neither is recoverable per request - JsonRpcServer.doCall only catches ClassCastException, and an OutOfMemoryError affects the whole process.
Scope and fix
Only applications using the JSON-RPC-over-AMQP tooling (com.rabbitmq.tools.jsonrpc) with the default DefaultJsonRpcMapper are affected. DefaultJsonRpcMapper and JSONReader are deprecated in favour of JacksonJsonRpcMapper, but both still ship and remain the default when no mapper is supplied. The fix is to stop both loops at CharacterIterator.DONE.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 5.36.0"
},
"package": {
"ecosystem": "Maven",
"name": "com.rabbitmq:amqp-client"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.36.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-106121"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-07T20:42:33Z",
"nvd_published_at": "2026-10-06T19:17:43Z",
"severity": "MODERATE"
},
"details": "## Summary\n\n`com.rabbitmq.tools.json.JSONReader.read()` never returns when its input ends inside a quoted string or a `//` line comment. Both scanners walk the input with `StringCharacterIterator.next()` but only compare against a delimiter, so once the iterator reaches `CharacterIterator.DONE` (`\uffff`) they loop forever. The string scanner (`string()`, line 210, `while (c != sep)`) also appends `\uffff` to a `StringBuilder` every iteration, so it fills the heap and throws `OutOfMemoryError`, taking down the JVM. The comment scanner (`skipWhiteSpace()`, lines 89-92, `while (c != \u0027\\n\u0027)`) pins a thread at 100% CPU with no allocation.\n\nThis is reachable with a single message. `JsonRpcServer` and `JsonRpcClient` fall back to `DefaultJsonRpcMapper` whenever no mapper is passed (`JsonRpcServer.java:84` and `:114`, `JsonRpcClient.java:186`), and that mapper hands the raw message body straight to `JSONReader.read()` (`DefaultJsonRpcMapper.java:42` for the server request, `:52` for the client reply). A caller that can publish to the RPC request queue hangs the server; a malicious or MITM\u0027d JSON-RPC service does the same to a client.\n\n## Proof of concept\n\nAgainst `amqp-client` 5.36.0 from Maven Central:\n\n```java\nimport com.rabbitmq.tools.jsonrpc.DefaultJsonRpcMapper;\n\npublic class Poc {\n public static void main(String[] args) {\n DefaultJsonRpcMapper mapper = new DefaultJsonRpcMapper();\n mapper.parse(\"{\\\"method\\\":\\\"x\", String.class); // unterminated string\n // mapper.parse(\"//\", String.class); // unterminated // comment\n System.out.println(\"unreachable\");\n }\n}\n```\n\n`java -Xmx64m -cp amqp-client-5.36.0.jar:. Poc` throws `OutOfMemoryError: Java heap space` in about 0.1s and never prints. Swapping in the `//` line spins at 100% CPU and never returns. A well-formed body such as `{\"method\":\"x\"}` returns immediately.\n\n## Impact\n\nAvailability. One small, unauthenticated message stops a JSON-RPC endpoint: the unterminated string exhausts the heap, the unterminated comment pins a thread forever. Neither is recoverable per request - `JsonRpcServer.doCall` only catches `ClassCastException`, and an `OutOfMemoryError` affects the whole process.\n\n## Scope and fix\n\nOnly applications using the JSON-RPC-over-AMQP tooling (`com.rabbitmq.tools.jsonrpc`) with the default `DefaultJsonRpcMapper` are affected. `DefaultJsonRpcMapper` and `JSONReader` are deprecated in favour of `JacksonJsonRpcMapper`, but both still ship and remain the default when no mapper is supplied. The fix is to stop both loops at `CharacterIterator.DONE`.",
"id": "GHSA-cqgh-8p3p-mx4m",
"modified": "2026-10-07T20:42:33Z",
"published": "2026-10-07T20:42:33Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/rabbitmq/rabbitmq-java-client/security/advisories/GHSA-cqgh-8p3p-mx4m"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-106121"
},
{
"type": "WEB",
"url": "https://github.com/rabbitmq/rabbitmq-java-client/pull/2100"
},
{
"type": "WEB",
"url": "https://github.com/rabbitmq/rabbitmq-java-client/commit/25fad817291feff3195c32620117d295598f8b41"
},
{
"type": "PACKAGE",
"url": "https://github.com/rabbitmq/rabbitmq-java-client"
},
{
"type": "WEB",
"url": "https://github.com/rabbitmq/rabbitmq-java-client/releases/tag/v5.37.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "RabbitMQ: JSONReader in the default JSON-RPC mapper never terminates on truncated input, causing DoS"
}
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.