CVE-2026-106122 in amqp-client
Summary
by MITRE • 10/06/2026
The RabbitMQ Java client library allows Java and JVM-based applications to connect to and interact with RabbitMQ nodes. Prior to 5.36.0, ValueReader.readShortstr decodes malformed UTF-8 bytes into replacement characters that can re-encode beyond the AMQP shortstr limit enforced by ValueWriter.writeShortstr. An attacker who can submit an RPC message with a malformed echoed property can cause reply publication in RpcServer.mainloop() or tutorial-style consumers to throw an unchecked exception before acknowledgement. The broker requeues the message, allowing the same message to disable replacement consumers until the queue is purged. This issue is fixed in version 5.36.0.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/06/2026
The RabbitMQ Java client library serves as a critical interface for Java and JVM-based applications seeking to connect with and interact with RabbitMQ messaging nodes. A significant vulnerability exists within this library prior to version 5.36.0, specifically involving the handling of string data types in the AMQP protocol implementation. The core technical flaw resides in the ValueReader.readShortstr method, which is responsible for decoding incoming short strings from the message stream. This function fails to strictly validate UTF-8 byte sequences against the length constraints defined by the AMQP specification before processing them. Consequently, when a malformed UTF-8 sequence containing replacement characters is decoded, it can be re-encoded by ValueWriter.writeShortstr into a string that exceeds the maximum allowed length for an AMQP short string. This discrepancy between decoding and encoding logic creates a boundary condition where invalid data passes through validation checks that rely on pre-decoding lengths rather than post-re-encoding realities.
The operational impact of this vulnerability is severe, primarily manifesting as a denial-of-service condition against consumers within the RabbitMQ infrastructure. An attacker who possesses the ability to submit an RPC message containing these malformed echoed properties can trigger unchecked exceptions in critical server-side components such as RpcServer.mainloop() or tutorial-style consumer handlers. When these exceptions occur before the system sends an acknowledgement for the received message, the broker interprets this lack of acknowledgment as a failure to process the task correctly. As per standard AMQP behavior, unacknowledged messages are automatically requeued and made available for delivery again. This mechanism allows the same maliciously crafted message to be repeatedly delivered to consumers, creating a continuous loop of exception throwing and message requeuing that effectively disables replacement consumers until manual intervention occurs.
This vulnerability represents a classic case of improper input validation leading to resource exhaustion and service disruption. From an industry standards perspective, this flaw aligns with CWE-20 Improper Input Validation, as the application fails to verify that decoded data conforms to expected structural constraints before further processing. Furthermore, the exploitation technique maps directly to MITRE ATT&CK tactic T1498 Network Denial of Service, specifically subtechnique T1498.003 Resource Exhaustion via Looping Constructs or Infinite Recursion, where the attacker leverages a logic error to consume system resources indefinitely by forcing repeated processing of invalid payloads. The persistence of this issue until queue purging highlights the difficulty in recovering from such automated denial-of-service attacks without administrative action.
To mitigate this risk and ensure operational resilience, organizations must upgrade the RabbitMQ Java client library to version 5.36.0 or later immediately upon deployment availability. This updated release contains the necessary corrections to enforce strict length limits during both decoding and encoding phases, preventing malformed UTF-8 sequences from bypassing validation checks. In addition to upgrading dependencies, security teams should implement robust input sanitization at application boundaries where messages are constructed, ensuring that all string properties adhere strictly to AMQP specifications before transmission. Monitoring for high volumes of requeued messages or repeated consumer exceptions can also serve as an early detection mechanism for potential exploitation attempts in environments where immediate patching is not feasible.