CVE-2026-67414

The MQTT 5 parser in RabbitMQ accepts the Request-Problem-Information property on PUBLISH packets even though it 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 matching subscriber, leading to a function_clause exception that closes the victim's MQTT or Web MQTT connection. The issue is fixed in versions 3.13.19, 4.0.24, 4.1.15, 4.2.10, and 4.3.5.

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