Vulnerabilidades de Rabbitmq

RabbitMQ is a messaging and streaming broker. From 3.13.0 until 3.13.19, 4.0.24, 4.1.15, 4.2.10, and 4.3.5, the MQTT 5 parser in deps/rabbitmq_mqtt/src/rabbit_mqtt_packet.erl accepts Request-Problem-Information on PUBLISH packets even though the property 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 separately authenticated matching subscriber. When the subscriber path serializes the outbound PUBLISH, serialise_prop/2 has no matching clause, and the uncontained function_clause exception closes the victim MQTT or Web MQTT connection. The publisher connection and broker remain available, and queued replay, retained-message persistence, and broker-wide denial of service were not established. This 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.

amqp091-go is a Go AMQP 0.9.1 client. From 1.13.0 until 1.14.0, the frame-size mitigation from the prior allocation advisory can be bypassed before connection.tune completes because Connection.maxFrameSize uses zero for both the not-yet-negotiated and negotiated-unlimited states. A malicious or compromised AMQP peer can send a short body-frame header with a large declared payload length, causing ReadFrame and the body-frame parser to allocate attacker-selected memory before the payload is received or the frame's protocol state is rejected. The condition is reachable through public Open even when Config.FrameSize is set to the protocol minimum and can cause severe memory pressure, out-of-memory termination, or loss of the client process before authentication completes. This issue is fixed in version 1.14.0.

The RabbitMQ Java client library allows Java and JVM-based applications to connect to and interact with RabbitMQ nodes. Prior to 5.35.0, ConnectionFactoryConfigurator.load() includes the raw uri value in wrapped exceptions when AMQP URI parsing fails. Because the URI may contain a plaintext username and password, startup logs, application performance monitoring systems, CI logs, and copied stack traces can disclose broker credentials to users who should not have access to them. This issue is fixed in version 5.35.0.

RabbitMQ is a messaging and streaming broker. From 3.13.0 until 3.13.19, 4.0.24, 4.1.15, 4.2.10, and 4.3.5, RabbitMQ Management rendered an AMQP authorization-error reason containing an attacker-controlled queue name as HTML when the OAuth management UI was enabled. Exploitation requires an attacker with queue configure permission, a management administrator who can see but cannot read that queue, and the administrator clicking Get Message(s). A queue name containing a base element can then retarget the automatic relative refresh because the Content Security Policy omits base-uri and connect-src, and an attacker endpoint that permits the management origin through CORS can receive the victim's Authorization header. This 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 3.13.0 until 4.3.3, 4.2.9, 4.1.14, 4.0.23, and 3.13.18, JWKS Fetch Ignores HTTP Response Status Code - Signing Key Destruction Causes Authentication DoS (CWE-252). the JWKS key fetching mechanism in uaajwt.erl does not validate the HTTP response status code when downloading signing keys from the OAuth2 provider's JWKS endpoint. Non-200 responses (including 4xx and 5xx errors) are processed identically to successful responses. When the JWKS endpoint returns an error response with a valid-JSON body that lacks a keys field, all previously cached signing keys are destroyed, causing a persistent authentication denial of Files: deps/rabbitmqauthbackendoauth2/src/uaajwt.erl, lines 50-63 deps/rabbitmqauthbackendoauth2/src/uaajwks.erl, lines 5-7 deps/rabbitmqauthbackendoauth2/src/rabbitoauth2provider.erl, lines 98-107 Bug 1: HTTP status code ignored (uaajwt.erl:50-63): The Erlang httpc module returns {ok, {{HttpVersion, StatusCode, ReasonPhrase}, Headers, Body}}. The pattern {ok, {, , JwksBody}} matches ANY successful HTTP transaction Persistent authentication DoS: Once keys are destroyed, ALL OAuth2/JWT authentication fails for all users until a new successful JWKS refresh occurs Amplification: A single attacker can deny access to all legitimate OAuth2 users across the entire RabbitMQ. This issue is fixed in versions 4.3.3, 4.2.9, 4.1.14, 4.0.23, and 3.13.18.

RabbitMQ is a messaging and streaming broker. From 4.1.0 until 4.3.3, 4.2.9, and 4.1.11, Stream Management Super-Stream Binding Keys Allocation Allows Low-Privilege Node Denial of Service. rabbitMQ 4.3.1 with rabbitmqstreammanagement enabled accepts PUT /api/stream/super-streams/{vhost}/{name} requests from an authenticated management user that can access the target vhost. When the request body contains the binding-keys field, the handler parses the attacker-controlled comma-separated string and builds the full stream-name list before checking whether the user has permission to configure the resulting streams. A low-privileged management user with vhost access but no configure, write, or read permission can therefore force large transient allocations before the resource permission check. In a 768 MB memory-limited container, one HTTP PUT with about 4.5 MB of JSON body killed the RabbitMQ container with Docker state exited true An authenticated low-privileged management user can kill a memory-limited RabbitMQ node with one HTTP This issue is fixed in versions 4.3.3, 4.2.9, and 4.1.11.

RabbitMQ is a messaging and streaming broker. From 3.13.0 until 3.13.15 and 4.0.20 and 4.1.11 and 4.2.6, Atom table exhaustion via management API node field. pUT /api/queues/:vhost/:name (and the exchanges and bindings endpoints) accepts a node JSON field. The value goes through rabbitnodes:make → listtoatom with no cluster membership check first. Each unique value permanently leaks one atom. A March 2026 refactoring (ea61ce2563) introduced safe helpers in rabbitmgmtnodes.erl (parsenodename, safeatom, and requirenodename, using binarytoexistingatom) and fixed several callers (QQ replica ops, wmauthattempts, wmnodememoryets, getsortreverse, and rabbitfederationmgmt), but getnode/1 in rabbitmgmtutil.erl:880-885, the primary vector used by directrequest/6, was not Roughly 900K requests crash the VM via systemlimit, and all tenants lose Any user with the management tag and one vhost, the lowest privilege This issue is fixed in versions 3.13.15 and 4.0.20 and 4.1.11 and 4.2.6.

RabbitMQ is a messaging and streaming broker. From 3.7.0 to before 4.1.2 and 4.0.13, This vulnerability is fixed in 4.1.2 and 4.0.13.