RabbitMQ vulnerabilities

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, and 4.2.6 does 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.

RabbitMQ before version 4.2.6 does not enforce the configured stream frame-size limit while assembling frames during authentication and before Tune negotiation. This allows an unauthenticated remote client to declare oversized frame lengths and consume broker memory in rabbit_stream_core.

A vulnerability in RabbitMQ before versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6 allows unauthenticated attackers to read the OAuth 2 client secret via the obsolete GET /api/auth endpoint. This occurs when the management plugin and management.oauth_client_secret are enabled.

A vulnerability in RabbitMQ before version 4.2.6 allows an existing consumer to keep receiving messages after OAuth token expiry or connection.update_secret refresh to reduced scopes. This occurs because existing consumers are not canceled or reauthorized at delivery time after the channel user state changes.

A vulnerability in RabbitMQ topic authorization can allow unauthorized topic writes and binds during metadata-store failures. This occurs because topic-permission lookup errors from Khepri collapse to undefined, which the internal backend treats as allow.

A vulnerability in RabbitMQ before versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6 allows a loopback-restricted user (e.g., guest) to authenticate remotely when traffic is accepted through a trusted PROXY path and the backend listener is loopback-bound. The issue is due to the loopback check using the listener-side socket address instead of the real client source.

RabbitMQ before versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6 allows foreign bindings to amq.rabbitmq.reply-to destinations. The vulnerability is due to missing deletion checks for volatile direct-reply-to queues in Khepri, leaving persistent route entries after unbind.

An XSS vulnerability in the RabbitMQ management UI allows a user with permission to declare queues or exchanges to execute JavaScript in another user's browser. The issue occurs before version 4.2.5 due to improper escaping of the x-internal-purpose argument in an HTML title attribute.

The rabbitmq_federation_management plugin in RabbitMQ before versions 3.13.14, 4.0.19, 4.1.10, and 4.2.5 does not escape the consumer_tag field on the Federation Status page, allowing XSS attacks. A user with permissions to configure federation upstream or policy can inject JavaScript that executes in the browser of an administrator viewing that page.

RabbitMQ before versions 3.13.14, 4.0.19, 4.1.10, and 4.2.5 has a vulnerability in the rabbitmq_management HTTP API that accepts oversized valid JSON bodies on with_decode and direct_request paths. The issue is due to incorrect size checking in read_complete_body, which checks the size before the final chunk but not the final combined size.

A vulnerability in RabbitMQ on Windows prior to versions 4.1.11 and 4.2.6 allows URL-encoded backslashes to be passed to the static file handler before path validation when multiple management extension plugins are enabled. This causes outbound DNS and SMB requests to attacker-controlled UNC paths.