Summary

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.

Vulnerable Code

src/main/java/com/rabbitmq/client/impl/ValueReader.java lines 83-95:

java private static byte[] readBytes(final DataInputStream in) throws IOException { final long contentLength = unsignedExtend(in.readInt()); if(contentLength < Integer.MAXVALUE) { final byte[] buffer = new byte[(int)contentLength]; // allocates before reading in.readFully(buffer); return buffer; } }

Attack Scenario

A malicious AMQP server sends a LongString field (type tag 'S') with declared length 0x7FFFFFFE (2,147,483,646). The check contentLength < Integer.MAXVALUE passes. new byte[2147483646] attempts ~2GB allocation, causing OutOfMemoryError before readFully() attempts to read data.

The allocation size is attacker-controlled and is NOT validated against the frame size or TruncatedInputStream bounds. Exploitable pre-authentication via connection.start server-properties table.

Impact

Denial of service via JVM OutOfMemoryError. Crashes the entire JVM.

CWE

CWE-789: Memory Allocation with Excessive Size Value

Remediation

Validate contentLength against the frame's remaining bytes or the negotiated max frame size (default 131,072) before allocating.

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: 1. Victim uses JsonRpcClient to connect to a JSON-RPC service via RabbitMQ 2. Attacker (co-tenant on shared broker, or MITM) intercepts the system.describe request 3. Attacker responds with crafted javaReturnType values 4. Victim's client calls Class.forName(attackerInput) with default initialize=true 5. Static initializers of attacker-specified classes execute in victim's JVM

Additionally, the loaded class from getReturnType() is passed to mapper.parse(replyStr, expectedType) at JsonRpcClient.java:168, potentially enabling type-confusion.

Recommended fix: Use Class.forName(javaReturnType, false, classLoader) to prevent static initializer execution, or add an allowlist of permitted return types.

CWE: CWE-470

---

Reply from reporter (2026-06-29): Thanks for the quick turnaround. Fix looks good. Looking forward to the CVE assignment.

Summary

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.

Vulnerable Code

src/main/java/com/rabbitmq/client/impl/ValueReader.java lines 139-155 and 237-249:

java private static Map<String, Object> readTable(DataInputStream in) throws IOException { long tableLength = unsignedExtend(in.readInt()); // ... while(tableIn.available() > 0) { String name = readShortstr(tableIn); Object value = readFieldValue(tableIn); // recursive call } }

static Object readFieldValue(DataInputStream in) throws IOException { switch(in.readUnsignedByte()) { case 'F': value = readTable(in); // mutual recursion case 'A': value = readArray(in); // mutual recursion } }

Attack Scenario

A malicious AMQP server (or MitM) sends a connection.start frame with ~580 levels of nested tables. Each level costs ~7 bytes (4-byte length + 1-byte key length + 1-byte key + 1-byte type tag), totaling ~4060 bytes within the 131,072 byte max frame size. With the default JVM stack (~512KB, ~864 bytes/frame), this triggers StackOverflowError, killing the I/O thread.

Exploitable pre-authentication since connection.start is the very first server frame.

Impact

Denial of service. StackOverflowError kills the client I/O thread.

CWE

CWE-674: Uncontrolled Recursion

Remediation

Add a depth counter to readTable/readArray/readFieldValue and throw MalformedFrameException when exceeding a threshold (e.g., 32).

Summary 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 CVE-2017-15699.

Details Inbound frames enter the client through SocketFrameHandler.readFrame, which returns frames parsed from the peer-controlled input stream (src/main/java/com/rabbitmq/client/impl/SocketFrameHandler.java:197). AMQConnection.MainLoop reads each frame (src/main/java/com/rabbitmq/client/impl/AMQConnection.java:692) and dispatches non-zero-channel frames to the channel while the connection is open (src/main/java/com/rabbitmq/client/impl/AMQConnection.java:748 and src/main/java/com/rabbitmq/client/impl/AMQConnection.java:766). The channel then passes the frame to the current command assembler through AMQChannel.handleFrame and AMQCommand.handleFrame (src/main/java/com/rabbitmq/client/impl/AMQChannel.java:121, src/main/java/com/rabbitmq/client/impl/AMQCommand.java:114). When a content-bearing method is followed by a content header, CommandAssembler.consumeHeaderFrame records the header's declared body size in remainingBodyBytes after only checking it against the configured maximum (src/main/java/com/rabbitmq/client/impl/CommandAssembler.java:126 through src/main/java/com/rabbitmq/client/impl/CommandAssembler.java:139). The body-frame path subtracts the received payload length from that remaining count before validating that the payload fits (src/main/java/com/rabbitmq/client/impl/CommandAssembler.java:145 through src/main/java/com/rabbitmq/client/impl/CommandAssembler.java:149), so a body frame larger than the declared size drives the count negative and reaches the raw UnsupportedOperationException at src/main/java/com/rabbitmq/client/impl/CommandAssembler.java:150 and src/main/java/com/rabbitmq/client/impl/CommandAssembler.java:151. AMQConnection catches the resulting throwable in frame processing and performs connection failure handling and final shutdown (src/main/java/com/rabbitmq/client/impl/AMQConnection.java:695 through src/main/java/com/rabbitmq/client/impl/AMQConnection.java:705).

PoC poc.zip

bash bash ./poc/run.sh

text Exception in thread "main" java.lang.UnsupportedOperationException: %%%%%% FIXME unimplemented

The UnsupportedOperationException: %%%%%% FIXME unimplemented fingerprint is the raw exception thrown at the negative remainingBodyBytes check in CommandAssembler.consumeBodyFrame. This line shows the malformed declared-size/body-size sequence reached the vulnerable assembler path.

Impact The attacker model is a remote AMQP broker peer that the RabbitMQ Java Client application has accepted, including a malicious broker endpoint, a compromised broker, or routing that sends the client to an attacker-controlled peer. The peer needs a non-zero open channel that can receive a content-bearing server-to-client method such as basic.deliver, then sends the method frame, a content header declaring a body below the configured maximum, and a body frame whose payload exceeds that declared size. Under those conditions, the peer can force frame processing to fail with UnsupportedOperationException and close the AMQP connection, producing a client-side denial of service for work depending on that connection; the finding does not indicate memory corruption, data disclosure, or code execution.

Vulnerability Summary

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.

Affected Components

- com.rabbitmq.client.TrustEverythingTrustManager — accepts any certificate - com.rabbitmq.client.ConnectionFactory.useSslProtocol() — uses TrustEverythingTrustManager - Hostname verification disabled by default (enableHostnameVerification() must be called explicitly) - com.rabbitmq.client.ConnectionFactory.getPassword() — returns plaintext with no redaction - Default port 5672 (plaintext) with PLAIN SASL — credentials sent unencrypted

POC (Verified on Java 21, amqp-client 5.25.0)

java // TrustEverythingTrustManager accepts ANY certificate including null TrustEverythingTrustManager tm = new TrustEverythingTrustManager(); tm.checkServerTrusted(null, "RSA"); // No exception — accepts null cert chain tm.getAcceptedIssuers(); // Returns empty array — trusts all CAs

// ConnectionFactory defaults ConnectionFactory factory = new ConnectionFactory(); factory.useSslProtocol(); // Uses TrustEverythingTrustManager internally // enableHostnameVerification() NOT called by default

// Credential exposure factory.setPassword("secretpassword123"); factory.getPassword(); // Returns "secretpassword123" — no redaction

// Default plaintext port factory.getPort(); // 5672 (plaintext, not 5671/TLS)

// PLAIN SASL sends cleartext credentials PlainMechanism pm = new PlainMechanism(); // handleChallenge() sends username+password in cleartext

Attack Scenarios

1. MITM: Attacker presents self-signed cert → TrustEverythingTrustManager accepts it → all RabbitMQ traffic intercepted 2. Credential theft: Default plaintext port (5672) + PLAIN SASL = credentials readable on network 3. DNS rebinding: No hostname verification → attacker DNS record → MITM without cert 4. Logging exposure: getPassword() returns plaintext → credentials in logs/stack traces

Suggested Fix 1. Deprecate TrustEverythingTrustManager — it should never be used in production 2. useSslProtocol() should use the JVM default trust store, not TrustEverything 3. Enable hostname verification by default 4. Redact password in getPassword() or remove the public getter 5. Warn when using PLAIN SASL without TLS

Summary 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.

Root cause The Java client records the AMQP 0-9-1 framemax negotiated during connection tuning, but the socket inbound frame reader continues to validate broker-controlled payload lengths against the much larger maxInboundMessageBodySize limit. A broker peer can therefore send a method frame whose payload is larger than the negotiated framemax, have it allocated and decoded, and complete the connection handshake instead of being rejected as a protocol violation.

Reported by Team Atlanta.

RabbitMQ is a messaging and streaming broker. From 3.7.0 to before 4.1.2 and 4.0.13, This vulnerability is fixed in 4.1.2 and 4.0.13.

RabbitMQ is a messaging and streaming broker. Prior to 3.13.15, 4.0.20, 4.1.11, and 4.2.6, the obsolete GET /api/auth endpoint can disclose the OAuth 2 client secret on RabbitMQ installations configured with management.oauthclientsecret, exposing credentials to unauthenticated callers when the management plugin and that OAuth configuration are enabled. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6.

RabbitMQ is a messaging and streaming broker. Prior to 3.13.14, 4.0.19, 4.1.10, and 4.2.5, the rabbitmqfederationmanagement plugin renders the consumertag field on the Federation Status page without HTML escaping, allowing a user who can configure a federation upstream or policy to execute JavaScript in the browser of a user viewing that page. This issue is fixed in versions 3.13.14, 4.0.19, 4.1.10, and 4.2.5.

RabbitMQ is a messaging and streaming broker. Prior to 4.1.11 and 4.2.6 on Windows, the RabbitMQ management plugin static file handler rabbitmgmtwmstatic can pass URL-encoded backslashes to erlprimloader:readfileinfo before path validation when multiple management extension plugins are enabled, causing outbound DNS and SMB requests to attacker-controlled UNC paths. This issue is fixed in versions 4.1.11 and 4.2.6.

RabbitMQ is a messaging and streaming broker. Prior to 4.2.5, the RabbitMQ management UI renders the x-internal-purpose queue or exchange argument into an HTML title attribute without proper escaping on the Queues and Exchanges pages, allowing a user with permission to declare a queue or exchange to execute JavaScript in another user's browser. This issue is fixed in version 4.2.5.

RabbitMQ is a messaging and streaming broker. Prior to 3.13.15, 4.0.20, 4.1.11, and 4.2.6, AMQP 0-9-1, AMQP 1.0, and Stream Protocol authentication can allow a loopback-restricted user such as guest to connect remotely when traffic is accepted through a trusted PROXY-protocol path and the backend listener is loopback-bound because the loopback check uses the listener-side socket address instead of the real client source. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6.

RabbitMQ is a messaging and streaming broker. Prior to 3.13.15, 4.0.21, 4.1.11, and 4.2.6, RabbitMQ topic authorization can allow restricted topic writes and binds during metadata-store failures because topic-permission lookup errors from Khepri can collapse to undefined, which the internal backend treats as allow. This issue is fixed in versions 3.13.15, 4.0.21, 4.1.11, and 4.2.6.

RabbitMQ is a messaging and streaming broker. Prior to 4.2.6, RabbitMQ AMQP 0-9-1 allows an existing consumer to keep receiving messages after OAuth token expiry or connection.updatesecret refresh to reduced scopes because existing consumers are not canceled or reauthorized at delivery time after the channel user state changes. This issue is fixed in version 4.2.6.

RabbitMQ is a messaging and streaming broker. Prior to 4.2.6, the RabbitMQ stream listener does not enforce the configured stream frame-size limit while assembling frames during authentication and before Tune negotiation, allowing an unauthenticated remote client to declare oversized frame lengths and consume broker memory in rabbitstreamcore. This issue is fixed in version 4.2.6.

RabbitMQ is a messaging and streaming broker. Prior to 3.13.15, 4.0.20, 4.1.11, and 4.2.6, RabbitMQ does not perform authorization checks on passive queue.declare and exchange.declare AMQP 0-9-1 operations, allowing any authenticated user who can connect to a virtual host to enumerate queue and exchange names and read queue message and consumer counts. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6.

RabbitMQ is a messaging and streaming broker. From 4.2.0 to before 4.2.4, RabbitMQ's MQTT plugin allows for topic-level authorization using regular expressions with variable substitution. Administrators can create patterns such as ^{clientid}-sensors$ to restrict user access to topics that include their client ID. However, the clientid is provided by the user in the MQTT CONNECT packet and is inserted into the regex pattern without escaping special regex characters. This flaw enables an authenticated MQTT user to inject regex operators to bypass authorization. This vulnerability is fixed in 4.2.4 and 4.3.0.

RabbitMQ is a messaging and streaming broker. In versions 3.13.7 and prior, RabbitMQ is logging authorization headers in plaintext encoded in base64. When querying RabbitMQ api with HTTP/s with basic authentication it creates logs with all headers in request, including authorization headers which show base64 encoded username:password. This is easy to decode and afterwards could be used to obtain control to the system depending on credentials. This issue has been patched in version 4.0.8.

JMS Client for RabbitMQ 1.x before 1.15.2 and 2.x before 2.2.0 is vulnerable to unsafe deserialization that can result in code execution via crafted StreamMessage data.