Advisories for Maven/Com.rabbitmq/Amqp-Client package

The JSON-RPC tools in com.rabbitmq.tools.jsonrpc perform Class.forName(javaReturnType) with initialize=true on class names received from untrusted AMQP messages, without any validation or allowlist. Vulnerable code (ProcedureDescription.java:101-127): When a JsonRpcClient connects, it calls system.describe and receives a service description from the AMQP queue. The response JSON includes javaReturnType fields that are reflectively set via JSONUtil.tryFill(), triggering setJavaReturnType() → computeReturnTypeAsJavaClass() → Class.forName(javaReturnType). Attack scenario: Victim uses JsonRpcClient to connect to a JSON-RPC service …

com.rabbitmq.client.TrustEverythingTrustManager accepts ANY TLS certificate (including null chains) and is used as the default trust manager when calling ConnectionFactory.useSslProtocol() without arguments. Combined with hostname verification being disabled by default, this enables trivial man-in-the-middle attacks.

ValueReader.readTable() and readArray() recursively call readFieldValue() with no depth limit. A malicious AMQP peer can crash the client JVM by sending a deeply nested table structure.

ValueReader.readBytes() allocates a byte array sized by a wire-declared content length without validating it against actual frame data. A malicious AMQP peer triggers OOM by declaring a ~2GB string/bytes field.

RabbitMQ Java Client's inbound AMQP command assembly accepts a content header declaring a small body and then processes a larger body frame by throwing a raw UnsupportedOperationException from CommandAssembler. A broker peer that the client has connected to can use this malformed frame sequence to fail frame processing and tear down the client connection instead of receiving a clean protocol-level malformed-frame error. This was discovered based on an existing vulnerability …

The max body size was enforced to patch CVE-2023-46120, but even though that limit still works, the frame size itself still exceeds the given max size.

Summary maxBodyLebgth was not used when receiving Message objects. Attackers could just send a very large Message causing a memory overflow and triggering an OOM Error. PoC RbbitMQ Use RabbitMQ 3.11.16 as MQ and specify Message Body size 512M (here it only needs to be larger than the Consumer memory) Start RabbitMQ Producer Build a String of length 256M and send it to Consumer package org.springframework.amqp.helloworld; import org.springframework.amqp.core.AmqpTemplate; import org.springframework.context.ApplicationContext; …

Pivotal Spring AMQP, 1.x versions prior to 1.7.10 and 2.x versions prior to 2.0.6, expose a man-in-the-middle vulnerability due to lack of hostname validation. A malicious user that has the ability to intercept traffic would be able to view data in transit.