Last updated 30 September 2026

RabbitMQ is a messaging and streaming broker. Prior to versions 4.1.13, 4.2.7, and 4.3.0, isauthorized/2 uses isauthorizedmonitor for all methods. DELETE resets rabbitcoremetrics:resetauthattemptmetrics(). Impact is cosmetic (counters only, no log erasure), but inconsistent with rabbitmgmtwmreset.erl which requires admin for the analogous operation. A monitoring-tagged user can reset the per-node authentication-attempt counters via DELETE /api/auth/attempts/:node, erasing evidence of brute-force activity. The sibling endpoint wmreset requires administrator. Preconditions include Management plugin enabled monitoring tag. This issue is fixed in versions 4.1.13, 4.2.7, and 4.3.0.

RabbitMQ is a messaging and streaming broker. Prior to versions 4.2.7 and 4.3.1, patterntoregex maps % -> .? and -> ., then compiles ^...$ with only [unicode]; re:run is called with only [{capture, none}] - no explicit matchlimit. A pattern like %%...%X becomes ^.?..?.....?.X$ with overlapping lazy quantifiers. The whole-expression cap is ?MAXEXPRESSIONLENGTH=4096 chars / ?MAXTOKENS=200; a LIKE string literal is one token, so ~2000 % pairs fit. SQL filters are accepted unconditionally at rabbitamqpsession.erl:3264 (no feature flag). Evaluated per-message at rabbitstreamqueue.erl:1439. OTP's default 10M matchlimit caps each match at ~100-200 ms (not seconds), and the re NIF yields to the scheduler. An authenticated AMQP 1.0 consumer with read+write on a stream queue can cause ~100-200 ms of CPU per delivered message via a crafted LIKE filter, multiplied across thousands of messages and parallel sessions - a substantial backtracking-driven CPU amplification. Preconditions include AMQP 1.0 with stream queues in use Attacker can attach a receiver with a filter (read permission) and publish messages with long property values (write permission). This issue is fixed in versions 4.2.7 and 4.3.1.

RabbitMQ is a messaging and streaming broker. Prior to versions 4.2.7 and 4.3.1, The stream open handler calls only checkvhostaccess; it omits the node/vhost/user connection-limit checks that rabbitreader performs for AMQP. A developer %% FIXME comment at the cited line explicitly acknowledges the gap. No compensating enforcement exists in connection tracking or elsewhere in rabbitmqstream. An authenticated tenant can fully bypass operator-configured per-user and per-vhost connection caps by connecting via port 5552 instead of 5672. Preconditions include rabbitmqstream plugin enabled Authenticated stream-protocol credentials Operator relies on per-user/per-vhost connection limits for tenant isolation. This issue is fixed in versions 4.2.7 and 4.3.1.

RabbitMQ is a messaging and streaming broker. Prior to versions 4.2.7 and 4.3.1, The runtime-parameters lookup path coerces the URL :component segment to an atom with rabbitdatacoercion:toatom/1 in lookupcomponent/1 (deps/rabbit/src/rabbitruntimeparameters.erl), creating a new atom for any previously unseen value. A safe helper, rabbitregistry:binarytotype/1, which uses binarytoexistingatom with a catch, already exists but is not used at this call site. lookupcomponent/1 calls rabbitdatacoercion:toatom(Component) on the :component segment of the request URL, converting an attacker-supplied string into a new atom. Because the Erlang atom table is bounded and atoms are never garbage collected, an authorized policymaker issuing roughly one million requests with distinct component values can exhaust the atom table and crash the node, resulting in a denial of service. Preconditions include Exploitation requires policymaker privileges and roughly one million requests.. This issue is fixed in versions 4.2.7 and 4.3.1.

It was discovered that RabbitMQ Server incorrectly handled CORS wildcard origin configuration. An attacker could possibly use this issue to cause a cross-site request forgery attack. This issue only affected Ubuntu 18.04 LTS, Ubuntu 20.04 LTS, Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, and Ubuntu 26.04 LTS. (CVE-2026-66070)

It was discovered that RabbitMQ Server incorrectly handled TLS peer-certificate DNs in the management UI. An attacker could possibly use this issue to cause a cross-site scripting attack. (CVE-2026-66077)

It was discovered that RabbitMQ Server incorrectly handled AMQP 1.0 arrays with zero-width element constructors. An attacker could possibly use this issue to cause a denial of service. This issue only affected Ubuntu 20.04 LTS, Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, and Ubuntu 26.04 LTS. (CVE-2026-66079)

It was discovered that RabbitMQ Server trust-store plugin incorrectly validated client certificates. An attacker could possibly use this issue to bypass TLS client authentication. This issue only affected Ubuntu 18.04 LTS, Ubuntu 20.04 LTS, Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, and Ubuntu 26.04 LTS. (CVE-2026-67231)

It was discovered that RabbitMQ Server incorrectly handled WebSocket frame sizes. An attacker could possibly use this issue to cause a denial of service. This issue only affected Ubuntu 20.04 LTS, Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, and Ubuntu 26.04 LTS. (CVE-2026-67232)

It was discovered that RabbitMQ Server incorrectly handled content-header body sizes. An attacker could possibly use this issue to cause a denial of service. (CVE-2026-67235)

It was discovered that RabbitMQ Server incorrectly stored credentials in an insecure cookie. An attacker could possibly use this issue to expose sensitive information. This issue only affected Ubuntu 20.04 LTS, Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, and Ubuntu 26.04 LTS. (CVE-2026-67236)

It was discovered that RabbitMQ Server incorrectly handled OAuth bearer tokens in bootstrap JavaScript. An attacker could possibly use this issue to cause a cross-site scripting attack. This issue only affected Ubuntu 24.04 LTS and Ubuntu 26.04 LTS. (CVE-2026-67237)

It was discovered that RabbitMQ Server incorrectly handled ETF-encoded PID node names. An attacker could possibly use this issue to cause a denial of service. This issue only affected Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, and Ubuntu 26.04 LTS. (CVE-2026-67238)

It was discovered that RabbitMQ Server incorrectly handled TLS peer-certificate DNs in the stream management UI. An attacker could possibly use this issue to cause a cross-site scripting attack. This issue only affected Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, and Ubuntu 26.04 LTS. (CVE-2026-67239)

It was discovered that RabbitMQ Server incorrectly handled OAuth2 SSL options when no CA certificates were available. An attacker could possibly use this issue to bypass TLS verification. This issue only affected Ubuntu 26.04 LTS. (CVE-2026-67404)

It was discovered that RabbitMQ Server incorrectly validated HTTP response status codes when fetching JWKS keys. An attacker could possibly use this issue to cause a denial of service. This issue only affected Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, and Ubuntu 26.04 LTS. (CVE-2026-67409)

RabbitMQ is a messaging and streaming broker. Prior to 3.13.15, 4.0.20, 4.1.11, and 4.2.6, RabbitMQ allows foreign bindings to amq.rabbitmq.reply-to destinations because volatile direct-reply-to queues can be accepted at bind and route time but are missing from Khepri-backed deletion checks, leaving persistent route entries after unbind. 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.0.0 until 4.0.24, 4.1.15, 4.2.10, and 4.3.4, deps/amqp10common/src/amqp10binaryparser.erl materializes each element of AMQP 1.0 arrays whose shared constructor has zero width, while limiting only the number of elements in each array and not the aggregate arrays in a frame. After completing SASL authentication, a low-privilege client can send an ordinary frame containing many individually permitted arrays, causing a small frame to expand into a very large reader-process heap before later frame validation or authorization. Because deps/rabbit/src/rabbitamqpreader.erl clears the pre-authentication maxheapsize guard after login, repeated or concurrent frames can trigger the node-wide memory alarm, block publishers, or exhaust broker memory. This issue is fixed in versions 4.0.24, 4.1.15, 4.2.10, and 4.3.4.

Summary A flaw in the recvContent function allows a malicious AMQP server to trigger an Out-of-Memory (OOM) error, forcing the host operating system or container runtime to immediately terminate the client process.

Vulnerability Details When receiving message content payloads, the client processes the expected size from the content header framework. The recvContent function attempts to optimize performance by pre-allocating memory for the message body based on the ch.header.Size field, which is a 64-bit unsigned integer (uint64).

go // channel.go:495-496 if cap(ch.body) == 0 { ch.body = make([]byte, 0, ch.header.Size) // unbounded }

The underlying library fails to validate or cap this requested size against any upper boundary—such as the maximum frame size negotiated during connection establishment (FrameMax). If a server specifies an extreme body size (e.g., 2^62 bytes), the Go runtime attempts to allocate an exabyte-scale slice capacity. This immediately exhausts available system memory, causing the operating system's OOM killer to terminate the application.

Attack Vector / Exploitation Scenario

- Message Delivery Phase: A malicious or compromised AMQP broker sends a standard basic.deliver frame containing a content header with an intentionally inflated body-size variable. - Authentication Requirement: No special privileges or authentication bypasses are required; the crash occurs seamlessly during normal message consumption.

Impact

- Availability: High. Exploded memory consumption results in an instant process termination, destroying application state and availability for all threads sharing the environment.

RabbitMQ amqp091-go is a Go AMQP 0.9.1 client. Prior to 1.13.0, Channel.dispatch in channel.go, confirms.confirm in confirms.go, and Connection.dispatch0 in connection.go synchronously send publisher confirmations, flow-control events, consumer cancellations, returned messages, including NotifyConfirm events and connection block notifications, to application-provided channels. If a listener channel is unbuffered, full, or not drained promptly, the sole reader goroutine blocks and stops processing frames, acknowledgments, deliveries, and heartbeats. Broker-driven event bursts can therefore cause connection stalls, missed heartbeats, deadlocks, and disconnection. This issue is fixed in version 1.13.0.

RabbitMQ is a messaging and streaming broker. From 4.0.0 until 4.0.24, 4.1.15, 4.2.10, and 4.3.4, the optimized AMQP 1.0 servermode parser in deps/amqp10common/src/amqp10binaryparser.erl matches the textual prefixes of symbolic data, sequence, and value body descriptors without verifying their encoded symbol lengths. An authenticated AMQP 1.0 publisher with write permission can submit a well-formed unknown descriptor that begins with a registered body descriptor, and RabbitMQ misclassifies and stores the bytes as a standard body section. Strict AMQP 1.0 consumers can terminate while decoding the stored entry. For bodies misclassified as data, AMQP 0-9-1 or other cross-protocol conversion performs full body decoding and can terminate the consumer protocol process, with acknowledgement-required delivery permitting repeated failures. Sequence and value classifications are normally transported as opaque encoded payloads on that conversion path. The broker remains alive, and the issue does not bypass routing or authorization. This issue is fixed in versions 4.0.24, 4.1.15, 4.2.10, and 4.3.4.

RabbitMQ is a messaging and streaming broker. From 3.13.0 until 3.13.19, 4.0.24, 4.1.15, 4.2.10, and 4.3.5, the MQTT 5 parser in deps/rabbitmqmqtt/src/rabbitmqttpacket.erl accepts Request-Problem-Information on PUBLISH packets even though the property is valid only for CONNECT. An authenticated publisher with topic write permission can cause the broker to store and route that inapplicable property to a separately authenticated matching subscriber. When the subscriber path serializes the outbound PUBLISH, serialiseprop/2 has no matching clause, and the uncontained functionclause exception closes the victim MQTT or Web MQTT connection. The publisher connection and broker remain available, and queued replay, retained-message persistence, and broker-wide denial of service were not established. This issue is fixed in versions 3.13.19, 4.0.24, 4.1.15, 4.2.10, and 4.3.5.

rabbitmq-c is a C-language AMQP client library for RabbitMQ. Prior to 0.16.0, a malicious AMQP server can send an undersized connection.tune.framemax value during amqplogin(), and rabbitmq-c accepts the value in amqplogininner() in librabbitmq/amqpsocket.c. amqptuneconnection() in librabbitmq/amqpconnection.c uses framemax to reallocate the outbound buffer without enforcing AMQPFRAMEMINSIZE. Immediate serialization of connection.tune-ok through amqpframetobytes() writes beyond the undersized heap allocation, causing memory corruption and likely denial of service. An on-path attacker can also trigger the flaw against plaintext AMQP traffic. Code execution is theoretically possible but was not demonstrated. This issue is fixed in version 0.16.0.

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 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 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 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 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.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.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 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 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.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 3.13.0 until 4.3.3, 4.2.9, 4.1.14, 4.0.23, and 3.13.18, JWKS Fetch Ignores HTTP Response Status Code - Signing Key Destruction Causes Authentication DoS (CWE-252). the JWKS key fetching mechanism in uaajwt.erl does not validate the HTTP response status code when downloading signing keys from the OAuth2 provider's JWKS endpoint. Non-200 responses (including 4xx and 5xx errors) are processed identically to successful responses. When the JWKS endpoint returns an error response with a valid-JSON body that lacks a keys field, all previously cached signing keys are destroyed, causing a persistent authentication denial of Files: deps/rabbitmqauthbackendoauth2/src/uaajwt.erl, lines 50-63 deps/rabbitmqauthbackendoauth2/src/uaajwks.erl, lines 5-7 deps/rabbitmqauthbackendoauth2/src/rabbitoauth2provider.erl, lines 98-107 Bug 1: HTTP status code ignored (uaajwt.erl:50-63): The Erlang httpc module returns {ok, {{HttpVersion, StatusCode, ReasonPhrase}, Headers, Body}}. The pattern {ok, {, , JwksBody}} matches ANY successful HTTP transaction Persistent authentication DoS: Once keys are destroyed, ALL OAuth2/JWT authentication fails for all users until a new successful JWKS refresh occurs Amplification: A single attacker can deny access to all legitimate OAuth2 users across the entire RabbitMQ. This issue is fixed in versions 4.3.3, 4.2.9, 4.1.14, 4.0.23, and 3.13.18.

RabbitMQ is a messaging and streaming broker. Prior to versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0, When no CA bundle is available, ssloptions/1 falls back to [{verify, verifynone}] with no warning. An attacker in a man-in-the-middle position can forge the JWKS response, which leads the broker to accept arbitrary JWTs. Preconditions include The OAuth2 plugin must be in use with no cacertfile configured and the OS CA bundle empty or unreadable (for example, in a minimal container), and the attacker must hold a network man-in-the-middle position.. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0.

RabbitMQ is a messaging and streaming broker. Prior to versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0, isauthorized/2 calls rabbitmgmtutil:isauthorized/2, which checks only the management tag, instead of isauthorizedvhost/2. The /api/queues/quorum/:vhost/:queue/status handler reads the vhost from the path without checking that the user can access it. Any management-tagged user can therefore read Raft status, including leader, members, term, and commit index, for quorum queues in inaccessible vhosts, exposing cross-tenant queue names and cluster topology. The management plugin must be enabled and the attacker must have a management tag. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0.

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

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