CVE-2026-67418

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 server_mode parser in deps/amqp10_common/src/amqp10_binary_parser.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 4.0.0 until 4.0.24, 4.1.15, 4.2.10, and 4.3.4, deps/amqp10_common/src/amqp10_binary_parser.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/rabbit_amqp_reader.erl clears the pre-authentication max_heap_size 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.

RabbitMQ versions from 3.13.0 until 3.13.18, 4.0.23, 4.1.14, 4.2.9, and 4.3.3 contain a Stored XSS vulnerability in the stream-management UI. The TLS peer-certificate DN is rendered without escaping, allowing injection of malicious HTML/JavaScript. This requires a non-default configuration with a stream TLS listener using verifypeer and an attacker-obtainable trusted certificate with a malicious DN.

RabbitMQ versions from 3.13.0 until 3.13.15, 4.0.20, 4.1.11, and 4.2.6 have a vulnerability in the stream protocol where the FrameMax value negotiated during the Tune handshake is stored but not compared with an inbound frame's declared length before buffering. A remote client can cause excessive memory pressure and denial of service by declaring an oversized frame.

RabbitMQ versions 3.13.0 through 3.13.15, 4.0.20, 4.1.11, and 4.2.6 have a vulnerability where list_to_atom/1 is applied to every colon-delimited token in an attacker-controlled auth_mechanism value, permanently consuming Erlang VM atoms and allowing the node to be crashed with a large request. Exploitation requires the Shovel or Federation plugin to be in use and the policymaker tag.

RabbitMQ versions from 4.2.0 until 4.2.8 and 4.3.2: a successful POST /login caused is_authorized/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.

An issue was discovered in RabbitMQ versions 3.4.x, 3.5.x, and 3.6.x prior to 3.6.9, as well as RabbitMQ for PCF versions 1.5.x, 1.6.x prior to 1.6.18, and 1.7.x prior to 1.7.15, related to storing user credentials in the browser's local storage without expiration. This allows for retrieval through a chained attack.

RabbitMQ 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, ssl_options/1 falls back to [{verify, verify_none}] with no warning. An attacker in a man-in-the-middle position can forge the JWKS response, leading the broker to accept arbitrary JWTs.

RabbitMQ 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 verify_fun that overrides {bad_cert, unknown_ca} / {bad_cert, selfsigned_peer} when the presented cert "matches" a whitelisted one. The match key relies solely on issuer name and serial number, which can be easily forged, allowing TLS client authentication bypass.

In RabbitMQ Management with the OAuth management UI enabled, an AMQP authorization-error reason containing an attacker-controlled queue name is rendered as HTML. A queue name containing a base element can retarget the automatic relative refresh, and via CORS an attacker endpoint can receive the victim's Authorization header.