CVE-2026-67220

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 versions from 4.2.0 until 4.2.8 and 4.3.2 had set_token_auth/2 inserting a bearer token from the Authorization header or access_token cookie into OAuth bootstrap JavaScript without escaping. This allowed attacker-controlled token content to execute JavaScript in the management UI origin. The endpoint is exposed before authentication only when management.oauth_enabled is true, and exploitation through the cookie path additionally requires the attacker to plant an access_token cookie on the management host.

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.

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

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.

RabbitMQ versions from 3.13.0 to 3.13.19, 4.0.24, 4.1.15, 4.2.10, and 4.3.5 contain a vulnerability where OAuth credential refresh retains revoked runtime tags. When an existing AMQP connection refreshes from an OAuth token granting the impersonator tag to a valid same-username token that no longer grants it, the connection's runtime tags are unchanged. Thus, the connection (including newly opened channels) can continue publishing with a foreign AMQP userid after the privilege should have been revoked.

Vulnerability in RabbitMQ before 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 states without memoization. This causes duplicate destinations to be materialized before deduplication, leading to combinatorial CPU and memory pressure, disrupting routing for all tenants.

The Shovel parameter parser in RabbitMQ converts attacker-controlled runtime parameter values into non-garbage-collected Erlang atoms before bounding them or checking a fixed allowlist. An attacker can exhaust the node-wide atom table and deny service, and malicious parameters are stored durably and reparsed when workers start.