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.

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.

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, The trust-store plugin installs a verifyfun that overrides {badcert, unknownca} / {badcert, selfsignedpeer} when the presented cert "matches" a whitelisted one. The match key is extractissuerid/1 → publickey:pkixissuerid/2 → {IssuerName, SerialNumber} , both fields are taken verbatim from the presented certificate body and contain no public-key, SKI, fingerprint or signature material. iswhitelisted/1 is a pure ets:member lookup; the stored full DER is used only for list/0 display and is never compared against the presented cert. cacerts is [], so the whitelisted cert is never used as a trust anchor for path validation either. TLS client-authentication bypass: an attacker who knows the issuer DN + serial of any whitelisted certificate can connect with a forged self-signed cert. Preconditions include rabbitmqtruststore plugin enabled and used as the TLS verifyfun Attacker knows or can guess the {Issuer, Serial} of at least one whitelisted cert (non-secret; exposed via CLI/logs/any cert copy). This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0.

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.

Summary A Denial of Service (DoS) vulnerability exists in the AMQP client's connection negotiation logic. The AMQP specification explicitly mandates a strict minimum frame size of 4096 bytes to prevent pathological packet fragmentation. While the library defines a frameMinSize = 4096 constant, the connection negotiation loop fails to enforce this boundary, blindly accepting whatever maximum frame size (FrameMax) the server advertises during the handshake.

If a client connects to a malicious or compromised AMQP broker that advertises an extremely low FrameMax (such as 1 byte), the negotiation succeeds. Consequently, every subsequent message transmission is forced to splinter into thousands or millions of single-byte frames, causing massive CPU overhead, thread contention, and a near-instantaneous application freeze.

---

Vulnerability Details

Mechanism During the connection establishment phase, the client and server negotiate connection parameters—including maximum channel count, heartbeat intervals, and maximum frame sizes. The vulnerability is located where the client accepts the server's tuning parameters:

go // Connection negotiation logic maps server values directly without validation if serverSettings.FrameMax > 0 { // VULNERABILITY: Lacks a floor validation check against frameMinSize (4096) c.config.FrameMax = serverSettings.FrameMax }

Because there is no conditional check asserting that serverSettings.FrameMax >= frameMinSize, a value below the protocol specification floor is successfully registered. When the application later passes data payloads to the frame writer, the chunking algorithm splits the payload using the negotiated FrameMax value as its chunk window divisor.

Impact When FrameMax is set to an absurdly low threshold (e.g., 1 to 10 bytes): A standard 10 KiB message payload requires tens of thousands of individual write operations and frame headers. The system's CPU becomes entirely bound by frame serialization, memory allocation for frame structures, and context switching within the network output loops. This results in an application-layer Denial of Service (DoS) affecting not just the specific AMQP connection, but potentially the entire host system due to CPU resource starvation.

---

Attack Vector An attacker who compromises an upstream AMQP broker, performs a Man-in-the-Middle (MitM) interception, or tricks an application into connecting to an unauthorized external rogue broker can trigger this vulnerability:

1. Rogue Handshake: The client application connects to an AMQP endpoint controlled by the attacker. 2. Malicious Parameter Tuning: During the connection.tune phase, the rogue server returns a FrameMax value of 1. 3. Resource Exhaustion Trigger: The client completes the handshake successfully. As soon as the client attempts to publish a message or process traffic, the internal loop fragments the data into single-byte frames, spiking the host's CPU usage to 100% and disabling the application thread.

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.

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.

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

Vulnerability

In AMQConnection.java (line 435-436), after Connection.Tune negotiation, the frame-max limit is set via:

java frameHandler.setFrameMax( Math.min(this.maxInboundMessageBodySize, frameMax));

When frameMax = 0 (meaning "unlimited" per AMQP spec), Math.min(67108864, 0) = 0. This value is then passed to Utils.framePayloadLimit(0) which returns Integer.MAXVALUE (line 77-79 of Utils.java):

java static int framePayloadLimit(int frameMax) { if (frameMax <= 0) { return Integer.MAXVALUE; } // ... }

This completely defeats the maxInboundMessageBodySize protection (default 64MB) at the frame level.

Attack Scenario

A malicious AMQP server (or MITM) sends Connection.Tune with frameMax=0:

1. Client defaults: requestedFrameMax = 0 (ConnectionFactory.DEFAULTFRAMEMAX, line 82) 2. negotiatedMaxValue(0, 0) = Math.max(0, 0) = 0 (line 673-676) 3. Math.min(maxInboundMessageBodySize, 0) = 0 — 64MB cap defeated 4. framePayloadLimit(0) = Integer.MAXVALUE — no frame size enforcement 5. Attacker sends a single frame with frameSize = 0x1FFFFFFF (~500MB) 6. Frame.readFrom() (line 135) executes new byte[frameSize] — OOM crash

The frame does not need to be a body frame — method frames, header frames, or heartbeat frames with a crafted size field all trigger the allocation before any content-level check fires.

Root Cause

The AMQP spec uses frameMax=0 to mean "unlimited", but Math.min treats it as the integer value zero. The intent of line 435-436 was to take the smaller of the two limits, but when one limit uses 0-means-unlimited semantics, Math.min always selects the zero, disabling the other limit.

Impact

- Default configuration is vulnerable: Both requestedFrameMax (client) and legitimate servers' frameMax in Tune may be 0 - Single-frame OOM: One malicious frame triggers up to ~2GB allocation (Integer.MAXVALUE bytes) - Bypasses existing protection: maxInboundMessageBodySize (introduced to cap allocations at 64MB) is entirely defeated at the frame level - Different from ValueReader OOM: This is a frame-layer allocation in Frame.readFrom(), not a value-layer allocation in ValueReader.readBytes()

Affected Code

- AMQConnection.java:435-436 — Math.min with 0-means-unlimited - Utils.java:77-79 — framePayloadLimit(0) returns Integer.MAXVALUE - Frame.java:135 — new byte[frameSize] allocation site - ConnectionFactory.java:82 — DEFAULTFRAMEMAX = 0

Suggested Fix

java int effectiveFrameMax = (frameMax == 0) ? this.maxInboundMessageBodySize : Math.min(this.maxInboundMessageBodySize, frameMax); frameHandler.setFrameMax(effectiveFrameMax);

This treats frameMax=0 as "use maxInboundMessageBodySize as the cap" instead of "zero".

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. Prior to versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6, parsearrayprimitive/2 for constructor 0x45 (list0) returns an element with byte-width B = 0. The enclosing array32 parser at line 148 reads a 4-byte Count from the wire and loops Count times consuming B bytes each , with B = 0, no input is consumed and the loop builds a list of Count empty elements bounded only by the 32-bit field. The SASL-mechanisms / SASL-init frame is parsed by amqp10framing:decodebin/1 from rabbitamqpreader.erl:412 before authentication completes. The pre-auth incomingmaxframesize (default 8192 bytes) caps the frame, not the Count field, so a 19-byte payload with Count = 0xFFFFFFFF is accepted. No maxheapsize is set on the reader process. An unauthenticated network attacker can crash any RabbitMQ node that has the AMQP 1.0 listener enabled (default port 5672) by sending a single ~19-byte frame. The reader process attempts to build a list of ~4 billion empty elements, exhausting heap memory and terminating the Erlang VM. All tenants and protocols on the node lose service. Preconditions include Network reachability to the AMQP listener (port 5672, enabled by default) No authentication required. 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 versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0, The cowboy WebSocket options at line 117 set compress => true, enabling RFC 7692 permessage-deflate negotiation. The handler does not set maxframesize, so cowboy's default of infinity applies. cowlib's cowws:parsepayload/9 calls zlib:inflate/2 on the compressed payload with no output-size limit. An attacker can negotiate permessage-deflate during the WebSocket upgrade and send a frame containing a zlib bomb (e.g. 50 KB → 5 GB). Decompression occurs in the connection process before websockethandle/2 ever sees the MQTT bytes. An unauthenticated attacker can crash a RabbitMQ node running the Web-MQTT plugin by sending a single highly-compressed WebSocket frame (a few KB on the wire) that inflates to gigabytes in memory. The cowboy WebSocket handler decompresses the entire frame before the MQTT CONNECT packet is processed, so no credentials are required. Preconditions include rabbitmqwebmqtt plugin enabled (not default, but common for browser clients) Network reachability to port 15675/15676 No authentication required. 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. From 4.2.0 until 4.2.8 and 4.3.2, a successful POST /login caused isauthorized/2 to set an auth cookie containing base64-encoded username:password credentials without HttpOnly, Secure, SameSite, or expiration protections. Because base64 is encoding rather than encryption, an attacker with same-origin cross-site scripting, an HTTP-readable network position, or local access to the browser cookie store could recover the actual login credentials; older browsers that treated an absent SameSite attribute as None also sent the cookie cross-site. This issue is fixed in versions 4.2.8 and 4.3.2.

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. From 4.2.0 until 4.3.3 and 4.2.9, OAuth2 Client Secret Exposed via Unauthenticated JavaScript Endpoint (CWE-200). when OAuth2 authentication is enabled for the RabbitMQ Management UI and the configured flow, IDP use a client secret, the oauthclientsecret configuration value is included in the JavaScript served by the unauthenticated endpoint /js/oidc-oauth/bootstrap.js. Any user who can reach the management UI port can retrieve the OAuth2 client secret without Files: deps/rabbitmqmanagement/src/rabbitmgmtwmauth.erl, line 186 deps/rabbitmqmanagement/src/rabbitmgmtoauthbootstrap.erl, lines 35-50 deps/rabbitmqmanagement/src/rabbitmgmtdispatcher.erl, lines 45-49 (route registration) Code Path: 1. The route /js/oidc-oauth/bootstrap.js is registered as a plain Cowboy handler (rabbitmgmtdispatcher.erl:46): Credential exposure for the affected configuration: OAuth2 client secret is accessible without any authentication Token theft: Attacker can complete the authorization code flow using stolen authorization codes Client impersonation: Attacker can make requests. Any RabbitMQ deployment with: This issue is fixed in versions 4.3.3 and 4.2.9.

RabbitMQ is a messaging and streaming broker. Prior to versions 3.13.17, 4.0.22, 4.1.13, and 4.2.6, matchorigin/1 returned the bare reflected Origin and allowed credentials even when the wildcard "" was configured, so the response echoed the attacker's origin together with Access-Control-Allow-Credentials. The affected code is rabbitmgmtcors.erl. When the management plugin is configured with a wildcard CORS origin (corsalloworigins = ""), the handler reflects the request Origin back in Access-Control-Allow-Origin and also sends Access-Control-Allow-Credentials: true. A malicious web page that a signed-in administrator visits can then use that administrator's cached HTTP Basic credentials to issue authenticated, state-changing requests to the management API. Preconditions include The management plugin is configured with the wildcard corsalloworigins = "", which is an explicit operator misconfiguration A target administrator has a cached HTTP Basic-auth session in the browser. This issue is fixed in versions 3.13.17, 4.0.22, 4.1.13, and 4.2.6.

RabbitMQ is a messaging and streaming broker. From 3.13.0 until 3.13.18 and 4.0.23 and 4.1.14 and 4.2.9 and 4.3.3, Stored XSS via TLS peer-certificate DN in stream-management UI (sibling of V-11). lines 102/106/110 render peercertsubject / peercertissuer with raw <%= %> and no fmtstring(). RFC4514 backslash-escaping of </> is HTML-inert and bypassable (<img ... //>). Requires non-default config: a stream TLS listener with verifypeer and an attacker-obtainable trusted cert with a malicious Same as the connection.ejs finding, against operators viewing the stream-connection detail rabbitmqstream + rabbitmqstreammanagement enabled with a TLS listener using verifypeer Attacker can obtain a certificate signed by a CA the listener trusts, with attacker-chosen DN An operator views the. This issue is fixed in versions 3.13.18 and 4.0.23 and 4.1.14 and 4.2.9 and 4.3.3.

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.

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.

RabbitMQ is a messaging and streaming broker. From 4.2.0 until 4.2.8 and 4.3.2, settokenauth/2 inserted a bearer token from the Authorization header or accesstoken cookie into OAuth bootstrap JavaScript without escaping, allowing attacker-controlled token content to execute JavaScript in the management UI origin. The endpoint is exposed before authentication only when management.oauthenabled is true, and exploitation through the cookie path additionally requires the attacker to plant an accesstoken cookie on the management host. This issue is fixed in versions 4.2.8 and 4.3.2.

RabbitMQ is a messaging and streaming broker. Prior to versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6, The management UI uses EJS 1.0 in which <%= ... %> does NOT HTML-escape. connection.ejs:135 renders <%= connection.ssldetails.peercertsubject %> (and peercertissuer) directly into the page. The same pattern appears in streamConnection.ejs:102,106,110. The values come from rabbitssl:peercertsubject/1 which formats the DN as a string without HTML escaping. The verifier corrected the original researcher's claim: this is reachable only when the listener is configured with verifypeer (so the certificate must be signed by a CA in the broker's trust store, not arbitrary self-signed); however, in deployments using mTLS for client authentication, any user who can request a certificate from the organisational CA controls the Subject CN. An attacker who can obtain a TLS client certificate signed by a CA the broker trusts (with verifypeer enabled) can embed JavaScript in the certificate's Subject DN. When any administrator views that connection in the management UI, the script executes in the admin's browser session, allowing full account takeover (create users, export definitions, etc.). The management UI's CSP includes 'unsafe-inline', so inline script execution is not blocked. Preconditions include TLS listener configured with ssloptions.verify = verifypeer Attacker can obtain a CA-signed client certificate with attacker-chosen Subject (e.g. self-service corporate PKI, or rabbitmqtruststore plugin in use) Administrator views the connection detail page. 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.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 versions 4.2.7 and 4.3.1, rabbitpidcodec:decomposefrombinary/1 parses a caller-supplied ETF-encoded binary and calls binarytoatom(Node, utf8) on the node-name field. It is reached from rabbitvolatilequeue:pidfromname/2, which is invoked for any queue name / routing key beginning amq.rabbitmq.reply-to.. The CandidateNodes membership check happens after the atom is created, and the surrounding try/catch cannot reclaim atoms (they are never GC'd). binarytoexistingatom is not used. Any authenticated AMQP client can crash the entire Erlang VM (all vhosts, all connections) with ~1M cheap requests. Preconditions include Authenticated AMQP 0-9-1 connection to any vhost No per-connection rate limit low enough to make ~1M operations infeasible. This issue is fixed in versions 4.2.7 and 4.3.1.

RabbitMQ is a messaging and streaming broker. Prior to versions 4.3.0, 4.2.6, 4.1.11, 4.0.20, and 3.13.15, The content-header BodySize (a uint64) was stored without validation against maxmessagesize. The size check ran only when assembly completed. By declaring bodysize = 2^63-1 and then streaming fragments, a client ensured that checkmsgsize never fired, so the accumulated body size went unbounded. A reader process accumulates memory until the memory alarm fires, degrading all publishers cluster-wide, or until the node runs out of memory. The memory alarm provides only partial mitigation, since it is reactive rather than preventive. AMQP 0-9-1 is the most widely used protocol, and any publisher can trigger this condition. Preconditions include Any authenticated AMQP 0-9-1 client with publish permission can exploit this.. This issue is fixed in versions 4.3.0, 4.2.6, 4.1.11, 4.0.20, and 3.13.15.

RabbitMQ is a messaging and streaming broker. From 4.1.0 until 4.3.3, 4.2.9, and 4.1.11, Stream Management Super-Stream Binding Keys Allocation Allows Low-Privilege Node Denial of Service. rabbitMQ 4.3.1 with rabbitmqstreammanagement enabled accepts PUT /api/stream/super-streams/{vhost}/{name} requests from an authenticated management user that can access the target vhost. When the request body contains the binding-keys field, the handler parses the attacker-controlled comma-separated string and builds the full stream-name list before checking whether the user has permission to configure the resulting streams. A low-privileged management user with vhost access but no configure, write, or read permission can therefore force large transient allocations before the resource permission check. In a 768 MB memory-limited container, one HTTP PUT with about 4.5 MB of JSON body killed the RabbitMQ container with Docker state exited true An authenticated low-privileged management user can kill a memory-limited RabbitMQ node with one HTTP This issue is fixed in versions 4.3.3, 4.2.9, and 4.1.11.

RabbitMQ is a messaging and streaming broker. Prior to 4.3.5, an authenticated user who can bind a queue to a topic exchange and publish to it can use consecutive # segments in a binding key to make both topic matchers revisit the same trie-node and routing-key-suffix states without memoization. The matcher materializes duplicate destinations before deduplication, causing combinatorial CPU work and memory pressure that can disrupt routing for all tenants. This vulnerability is fixed in 4.3.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 versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0, addvhost/2 calls rabbitdatacoercion:atomizekeys/1 (the unsafe variant using binarytoatom) on the vhost metadata map. The 20 MB management body limit fits ~1M+ short keys. Admin-only. An administrator importing a crafted definitions file can crash the node in a single request: a vhosts entry with ~1M unique metadata keys exhausts the atom table during import. Preconditions include administrator tag. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0.