Threat Intelligence Database

RabbitMQ versions prior to 3.13.15, 4.0.20, 4.1.11, and 4.2.6 do not perform authorization checks on passive queue.declare and exchange.declare AMQP 0-9-1 operations. This allows any authenticated user connected to a virtual host to enumerate queue and exchange names and read queue message and consumer counts. The issue is fixed in the specified versions.

CVE-2026-57220 is a vulnerability in RabbitMQ server prior to version 4.2.6 where the stream listener does not enforce the configured stream frame-size limit during authentication and before Tune negotiation. This allows an unauthenticated remote client to declare oversized frame lengths, leading to excessive memory consumption in the broker's stream core component. The issue is fixed in RabbitMQ version 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, the obsolete GET /api/auth endpoint can disclose the OAuth 2 client secret on RabbitMQ installations configured with management.oauth_client_secret, 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.

CVE-2026-57218 is an authorization vulnerability in RabbitMQ server versions prior to 4.2.6. It allows an existing consumer to continue receiving messages even after the OAuth token expires or its permissions are reduced via connection.update_secret refresh. This occurs because consumers are not canceled or reauthorized at delivery time after the channel user state changes. The issue is fixed in RabbitMQ version 4.2.6.

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

RabbitMQ is a messaging and streaming broker. Prior to 3.13.15, 4.0.20, 4.1.11, and 4.2.6, RabbitMQ allows foreign bindings to amq.rabbitmq.reply-to destinations because volatile direct-reply-to queues can be accepted at bind and route time but are missing from Khepri-backed deletion checks, leaving persistent route entries after unbind. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6.

CVE-2026-57214 is a cross-site scripting (XSS) vulnerability in the RabbitMQ management UI prior to version 4.2.5. The issue arises because the x-internal-purpose queue or exchange argument is rendered into an HTML title attribute without proper escaping on the Queues and Exchanges pages. This allows a user with permission to declare a queue or exchange to execute JavaScript in another user's browser. The vulnerability is fixed in RabbitMQ version 4.2.5.

A cross-site scripting (XSS) vulnerability exists in the rabbitmq_federation_management plugin of rabbitmq-server prior to versions 3.13.14, 4.0.19, 4.1.10, and 4.2.5. The consumer_tag field on the Federation Status page is rendered without proper HTML escaping, allowing a user who can configure federation upstream or policy to execute JavaScript in the browser of a user viewing that page. This vulnerability has a medium severity score of 5.7 and is fixed in the specified versions.

CVE-2026-57212 is a high-severity vulnerability in rabbitmq-server affecting the rabbitmq_management HTTP API. Prior to versions 3.13.14, 4.0.19, 4.1.10, and 4.2.5, the API improperly handles oversized valid JSON bodies on with_decode and direct_request paths due to incomplete size checks. This can lead to allocation of resources without limits or throttling, potentially impacting system stability. The issue is fixed in the specified versions.