CVE-2026-67242

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.

The optional rabbitmq_jms_topic_exchange plugin in RabbitMQ accepts a client-controlled rjms_erlang_selector binding expression whose LIKE evaluator expands wildcards into overlapping PCRE fragments executed without match or recursion limits. An authenticated tenant can consume broker scheduler CPU and deny service with pathological selectors.

Federation upstream in RabbitMQ skips vhost authorization, allowing cross-vhost message access. A policymaker on one vhost can read and drain messages from another vhost it has no permission on, and with the default ack-mode the source messages are consumed rather than copied.

Native MQTT and MQTT over WebSocket behind a trusted PROXY Protocol frontend in RabbitMQ can lose the proxy-derived client address before the MQTT authentication path checks loopback_users, causing the frontend-to-broker address to be treated as loopback. An attacker with valid credentials for a loopback-restricted account can bypass the source-address restriction.

Incomplete fix for CVE-2026-44838 in RabbitMQ: escaperegexchar/1 does not escape the - character, allowing an MQTT topic permission bypass. When a topic permission template places {clientid} inside a [...] character class, a low-privileged authenticated MQTT user can broaden topic authorization.

Shovel in RabbitMQ does not format state logged by the crash reporter, potentially leaving unencrypted credentials in a crash dump file. When Shovel worker processes crash, the OTP SASL error handler writes the full process state, including plaintext AMQP passwords and URIs, to the error log.

In RabbitMQ, AMQP 1.0 management exchange.declare skips the alternate-exchange permission check. A user with only configure permission on exchange X can route X's unroutable messages into an alternate exchange they have no write permission on.