CVE-2026-106121: RabbitMQ Java Client DOS Vulnerability

CVE-2026-106121 Overview

CVE-2026-106121 affects the RabbitMQ Java client library, which allows Java and JVM-based applications to connect to and interact with RabbitMQ nodes. Versions prior to 5.37.0 contain a flaw in com.rabbitmq.tools.json.JSONReader.read() where the string and whitespace scanners fail to stop at CharacterIterator.DONE. The DefaultJsonRpcMapper passes JSON-RPC message bodies to this parser for JsonRpcServer and client replies. A truncated quoted string drives the parser to append replacement end markers until heap exhaustion, and a line comment without a terminating newline consumes CPU indefinitely. The issue is classified under [CWE-835] (Loop with Unreachable Exit Condition) and is fixed in version 5.37.0.

Critical Impact
Authenticated attackers can submit malformed JSON-RPC payloads that trigger heap exhaustion or an infinite CPU loop, resulting in denial of service against JsonRpcServer instances.

Affected Products

RabbitMQ Java Client library versions prior to 5.37.0
Applications using com.rabbitmq.tools.jsonrpc.JsonRpcServer with DefaultJsonRpcMapper
JVM-based clients invoking the deprecated com.rabbitmq.tools.json.JSONReader

Discovery Timeline

2026-10-06 - CVE-2026-106121 published to the National Vulnerability Database (NVD)
2026-10-06 - Last updated in NVD database

Technical Details for CVE-2026-106121

Vulnerability Analysis

The RabbitMQ Java client ships a deprecated JSON parser in com.rabbitmq.tools.json.JSONReader. The read() method advances through input using a CharacterIterator, but two scanner branches never check for the sentinel value CharacterIterator.DONE. The string scanner continues past end-of-input, repeatedly appending replacement end markers until the JVM heap is exhausted. The line comment scanner loops until it finds a newline character; if input ends mid-comment, the loop never terminates and the processing thread spins indefinitely.

Because DefaultJsonRpcMapper routes incoming JSON-RPC bodies through this parser, any component built on JsonRpcServer is reachable through normal messaging. A single malformed body is sufficient to consume a server thread or exhaust server memory.

Root Cause

The root cause is a missing terminator check in two tokenizer loops. The scanners compare the current character against expected delimiters without also comparing against CharacterIterator.DONE. The server-side wrapper additionally caught only ClassCastException, so other parser-raised runtime exceptions propagated and were not translated into a safe 400 Bad Request response.

Attack Vector

Exploitation requires network access to a RabbitMQ queue consumed by a JsonRpcServer and the privilege to publish messages onto that queue. An attacker publishes a JSON-RPC request body containing either a quoted string with no closing quote or a // line comment with no trailing newline. The consuming thread either loops on CPU indefinitely or allocates memory until an OutOfMemoryError degrades the JVM.

java

// Patch excerpt: src/main/java/com/rabbitmq/tools/json/JSONReader.java
                next();
            }
            else if (c == '/' && next() == '/') {
-               while (c != '\n') {
+               while (c != '\n' && c != CharacterIterator.DONE) {
                    next();
                }
            }
// Source: https://github.com/rabbitmq/rabbitmq-java-client/commit/25fad817291feff3195c32620117d295598f8b41

java

// Patch excerpt: src/main/java/com/rabbitmq/tools/jsonrpc/JsonRpcServer.java
                    }
                }
            }
-       } catch (ClassCastException cce) {
-           // Bogus request!
+       } catch (RuntimeException e) {
+           // Bogus request! Note this also covers a request body that the mapper
+           // cannot parse at all: such a request must not take the server down.
+           LOGGER.debug("Error while processing JSON RPC request", e);
            response = errorResponse(null, 400, "Bad Request", null);
        }
// Source: https://github.com/rabbitmq/rabbitmq-java-client/commit/25fad817291feff3195c32620117d295598f8b41

Detection Methods for CVE-2026-106121

Indicators of Compromise

Sustained 100% CPU utilization on a single JVM thread processing RabbitMQ consumer traffic without a corresponding workload change.
Repeated java.lang.OutOfMemoryError: Java heap space events in logs tied to classes under com.rabbitmq.tools.jsonrpc or com.rabbitmq.tools.json.
Thread dumps showing threads blocked inside JSONReader.read() or its helper scanners.

Detection Strategies

Inventory JVM applications depending on com.rabbitmq:amqp-client and flag any version earlier than 5.37.0.
Enable debug logging on JsonRpcServer; the patched code emits a debug entry when the mapper rejects a request, which can be alerted on if volumes spike.
Correlate RabbitMQ broker publish events with downstream JVM heap and CPU anomalies to identify poisoned message bodies.

Monitoring Recommendations

Track JVM metrics (heap used, GC pause time, per-thread CPU) for services consuming JSON-RPC queues and alert on sudden sustained growth.
Monitor queue depth on JSON-RPC request queues; a stuck consumer thread will cause unacknowledged messages to accumulate.
Capture periodic thread dumps on long-running RabbitMQ consumers to detect threads pinned in parser loops.

How to Mitigate CVE-2026-106121

Immediate Actions Required

Upgrade the RabbitMQ Java client dependency to version 5.37.0 or later across all producers, consumers, and JSON-RPC servers.
Restrict publish permissions on queues bound to JsonRpcServer instances to trusted producers only.
Replace use of the deprecated com.rabbitmq.tools.json.JSONReader and DefaultJsonRpcMapper with a maintained JSON library such as Jackson where feasible.

Patch Information

The fix is published in GitHub Release v5.37.0 and tracked in GitHub Pull Request #2100. The commit hardens the deprecated JSON reader so its scanners terminate on CharacterIterator.DONE, and widens the JsonRpcServer exception handler from ClassCastException to RuntimeException so parser failures return 400 Bad Request instead of taking the server down. See the full advisory at GitHub Security Advisory GHSA-cqgh-8p3p-mx4m.

Workarounds

Configure a custom JsonRpcMapper backed by a hardened JSON parser (for example, Jackson) to replace DefaultJsonRpcMapper.
Enforce strict input size and content validation on upstream components that publish into JSON-RPC request queues.
Apply per-consumer thread timeouts and memory limits so a single malformed message cannot exhaust the JVM.

bash

# Maven dependency upgrade
# pom.xml
# <dependency>
#   <groupId>com.rabbitmq</groupId>
#   <artifactId>amqp-client</artifactId>
#   <version>5.37.0</version>
# </dependency>

mvn versions:set-property -Dproperty=amqp-client.version -DnewVersion=5.37.0
mvn dependency:tree | grep amqp-client