RabbitMQ vulnerabilities

In RabbitMQ, the stream open handler calls only check_vhost_access, omitting the node/vhost/user connection-limit checks that rabbit_reader performs for AMQP. An authenticated tenant can fully bypass operator-configured per-user and per-vhost connection caps by connecting via port 5552 instead of 5672.

In RabbitMQ prior to versions 4.2.7 and 4.3.1, rabbit_pid_codec:decompose_from_binary/1 parses a caller-supplied ETF-encoded binary and calls binary_to_atom(Node, utf8) on the node-name field. It is reached from rabbit_volatile_queue:pid_from_name/2, which is invoked for any queue name or routing key beginning with amq.rabbitmq.reply-to.. The CandidateNodes membership check happens after the atom is created, and the surrounding try/catch cannot reclaim atoms (they are never GC'd). Any authenticated AMQP client can crash the entire Erlang VM (all vhosts, all connections) with ~1M cheap requests.

In RabbitMQ prior to versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6, parse_array_primitive/2 for constructor 0x45 (list0) returns an element with byte-width B = 0. The enclosing array32 parser reads a 4-byte Count from the wire and loops Count times consuming B bytes each; with B = 0, no input is consumed and the loop builds a list of Count empty elements bounded only by the 32-bit field. The SASL-mechanisms / SASL-init frame is parsed by amqp10_framing:decode_bin/1 from rabbit_amqp_reader.erl:412 before authentication completes. The pre-auth incoming_max_frame_size (default 8192 bytes) caps the frame, not the Count field, so a 19-byte payload with Count = 0xFFFFFFFF is accepted. No max_heap_size is set on the reader process. An unauthenticated network attacker can crash any RabbitMQ node that has the AMQP 1.0 listener enabled (default port 5672) by sending a single ~19-byte frame.

In RabbitMQ prior to versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0, the /api/queues/quorum/:vhost/:queue/status handler reads the vhost from the path without checking user access, using is_authorized/2 instead of is_authorized_vhost/2. A management-tagged user can read Raft status for quorum queues in inaccessible vhosts.

In RabbitMQ prior to versions 3.13.17, 4.0.22, 4.1.13, and 4.2.6, match_origin/1 returned the bare reflected Origin and allowed credentials even when the wildcard "*" was configured, so the response echoed the attacker's origin together with Access-Control-Allow-Credentials. The affected code is rabbit_mgmt_cors.erl. When the management plugin is configured with a wildcard CORS origin (cors_allow_origins = "*"), the handler reflects the request Origin back in Access-Control-Allow-Origin and also sends Access-Control-Allow-Credentials: true. A malicious web page that a signed-in administrator visits can then use that administrator's cached HTTP Basic credentials to issue authenticated, state-changing requests to the management API.

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.