RabbitMQ vulnerabilities

RabbitMQ versions from 3.13.0 until 3.13.18, 4.0.23, 4.1.14, 4.2.9, and 4.3.3 contain a Stored XSS vulnerability in the stream-management UI. The TLS peer-certificate DN is rendered without escaping, allowing injection of malicious HTML/JavaScript. This requires a non-default configuration with a stream TLS listener using verifypeer and an attacker-obtainable trusted certificate with a malicious DN.

RabbitMQ versions from 3.13.0 until 3.13.15, 4.0.20, 4.1.11, and 4.2.6 have a vulnerability in the stream protocol where the FrameMax value negotiated during the Tune handshake is stored but not compared with an inbound frame's declared length before buffering. A remote client can cause excessive memory pressure and denial of service by declaring an oversized frame.

RabbitMQ versions 3.13.0 through 3.13.15, 4.0.20, 4.1.11, and 4.2.6 have a vulnerability where list_to_atom/1 is applied to every colon-delimited token in an attacker-controlled auth_mechanism value, permanently consuming Erlang VM atoms and allowing the node to be crashed with a large request. Exploitation requires the Shovel or Federation plugin to be in use and the policymaker tag.

RabbitMQ versions from 4.2.0 until 4.2.8 and 4.3.2: a successful POST /login caused is_authorized/2 to set an auth cookie containing base64-encoded username:password credentials without HttpOnly, Secure, SameSite, or expiration protections. Because base64 is encoding rather than encryption, an attacker with same-origin cross-site scripting, an HTTP-readable network position, or local access to the browser cookie store could recover the actual login credentials; older browsers that treated an absent SameSite attribute as None also sent the cookie cross-site.

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, 4.2.6, and 4.3.0 — when no CA bundle is available, ssl_options/1 falls back to [{verify, verify_none}] with no warning. An attacker in a man-in-the-middle position can forge the JWKS response, leading the broker to accept arbitrary JWTs.

RabbitMQ prior to versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0 — the trust-store plugin installs a verify_fun that overrides {bad_cert, unknown_ca} / {bad_cert, selfsigned_peer} when the presented cert "matches" a whitelisted one. The match key relies solely on issuer name and serial number, which can be easily forged, allowing TLS client authentication bypass.

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, the OAuth2 isinteger(Exp) guard skips token-expiry checks for float exp values. When the IdP emits exp as a JSON float, both the login-time expiry check and the mid-connection disconnect timer are silently skipped, so an already-expired token is accepted and connections never time out.

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.

RabbitMQ versions from 4.2.0 until 4.2.8 and 4.3.2 had set_token_auth/2 inserting a bearer token from the Authorization header or access_token cookie into OAuth bootstrap JavaScript without escaping. This allowed attacker-controlled token content to execute JavaScript in the management UI origin. The endpoint is exposed before authentication only when management.oauth_enabled is true, and exploitation through the cookie path additionally requires the attacker to plant an access_token cookie on the management host.

RabbitMQ versions 4.2.0 to 4.2.8 and 4.3.2 contain a vulnerability in get_auth_mechanism/1, which uses term_to_binary/1 on the strict_auth_mechanism or preferred_auth_mechanism atom when clearing the corresponding cookie. This produces a non-ASCII cookie name that violates RFC 6265 and can prevent the browser from deleting the preference. The issue is not directly exploitable for code execution but affects the persistence of preferences across logout and login cycles.

The Web STOMP WebSocket handler in RabbitMQ enforces neither max_frame_size nor login_timeout before authentication, allowing an unauthenticated client to keep a connection alive with a slow stream of small frames and accumulate unbounded pre-authentication state. The rabbitmq_web_stomp plugin must be enabled.

RabbitMQ versions from 4.0.0 until 4.0.22, 4.1.14, 4.2.7, and 4.3.1 are vulnerable to atom exhaustion. The toatom/1 function is called on the :name URL path segment in global-parameters endpoints, allowing a user with the policymaker tag to send repeated requests and exhaust the atom table, crashing the node.

RabbitMQ versions from 4.0.0 until 4.0.22, 4.1.14, and 4.2.7 are vulnerable to admin-only atom exhaustion. The settags/2 function calls toatom/1 on the user's tags list, and the 20 MB body limit allows approximately 3-4 million short tags. An administrator can crash the node with a single request.

RabbitMQ versions in the 3.13, 4.0, 4.1, 4.2, and 4.3 lines have a vulnerability where fill/2 substitutes ${username} into user_dn_pattern without RFC 4514 DN escaping, allowing a crafted username to alter the LDAP bind DN. Exploitation requires rabbitmq_auth_backend_ldap with a user_dn_pattern containing ${username}, a suitable directory layout, and a valid password. Fixed versions are conflicting across sources.

RabbitMQ versions from 3.13.0 to 3.13.15, 4.0.20, 4.1.11, and 4.2.6 contain a vulnerability allowing bypass of the 'protected' tag via bulk-delete. An administrator can delete protected service accounts using the bulk endpoint, bypassing the safeguard that checks the protected tag.

RabbitMQ versions 3.13.0 through 3.13.15, 4.0.20, 4.1.11, and 4.2.6 are vulnerable to atom table exhaustion via the node field in the management API. The PUT /api/queues/:vhost/:name (and exchanges and bindings endpoints) accepts a node JSON field that is converted to an atom without cluster membership check. Each unique value permanently leaks one atom, and roughly 900K requests crash the VM.

RabbitMQ versions 3.13.0 through 3.13.15, 4.0.22, 4.1.11, 4.2.6, and 4.3.1 are vulnerable to atom exhaustion via OAuth2 JWT tag scope values. The extractscopes/1 function parses scopes of the form .tag: and converts them to atoms. The token signature is verified, but in IdP configurations where scope content is user-influenced, each login with a novel tag value leaks one atom.

RabbitMQ versions 4.0.0 through 4.3.3, 4.2.9, 4.1.14, and 4.0.23 have a vulnerability in AMQP 1.0 where the GET /bindings management endpoint exposes full binding topology to any authenticated AMQP user without resource/management permission checks. Unlike other operations in the same module, GET /bindings does not check permissions and returns the binding list unchanged.

RabbitMQ versions prior to 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.1 allow a monitoring-tagged user to delete or restart any dynamic shovel in any vhost they can see. The shovel management resource delegates authorization to a monitoring check even though DELETE should be restricted to the policymaker role. The issue is fixed in the listed versions.

RabbitMQ prior to versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0 does not validate the Origin header on WebSocket upgrade in the Web-MQTT and Web-STOMP handlers. With ssl_cert_login=true, the browser automatically presents the client certificate, so attacker JavaScript in the victim's browser can authenticate as the victim.

RabbitMQ before versions 4.2.7 and 4.3.1 does not enforce an explicit match limit when compiling LIKE patterns into regular expressions, allowing an authenticated AMQP 1.0 consumer with read and write permissions on a stream queue to cause significant CPU consumption via a crafted LIKE filter. Each delivered message can cause about 100-200 ms of CPU load, amplified across thousands of messages and parallel sessions. The issue is fixed in versions 4.2.7 and 4.3.1.

RabbitMQ prior to versions 4.3.0, 4.2.6, 4.1.11, 4.0.20, and 3.13.15 stores the content-header BodySize (a uint64) without validation against max_message_size. A client can declare body_size = 2^63-1 and stream fragments so the size check never fires, causing the reader process to accumulate unbounded memory. This leads to node memory exhaustion or a memory alarm, degrading all publishers cluster-wide.

RabbitMQ prior to versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0 enables permessage-deflate WebSocket compression (RFC 7692) without a max_frame_size limit and without an output-size limit on decompression. An unauthenticated attacker can send a highly compressed WebSocket frame (a zlib bomb) that inflates to gigabytes in memory, crashing a RabbitMQ node running the Web-MQTT plugin.

RabbitMQ prior to versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0 calls rabbit_data_coercion:atomize_keys/1 (the unsafe binary_to_atom variant) on the vhost metadata map. An administrator importing a crafted definitions file can exhaust the atom table and crash the node in a single request.

RabbitMQ prior to versions 4.2.7 and 4.3.1 coerces the URL :component segment to an atom via rabbit_data_coercion:to_atom/1 in the runtime-parameters lookup path, creating a new atom for any previously unseen value. An authorized policymaker can send roughly one million requests with distinct component values to exhaust the atom table and crash the node.

In RabbitMQ prior to versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.1, the trace consumer constructs the output path without a safe relative path check, even though the read side performs such a check. An administrator can use the name parameter to write a .log-suffixed file to an arbitrary filesystem path writable by the rabbitmq user, e.g. /etc/cron.d/x.log.

RabbitMQ prior to versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0: the AMQP 0-9-1 shovel removes credentials before storing its connection URI, but the AMQP 1.0 shovel stores the raw URI including the password. The stored URI is visible via GET /api/shovels and rabbitmqctl shovel_status.

RabbitMQ prior to versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0: when a binding is created on an x-jms-topic exchange, add_binding/3 reads the rjms_erlang_selector argument and passes it through erl_scan:string/1 and erl_parse:parse_term/1. erl_scan:string/1 interns every atom literal, validate_binding/2 is a no-op with no length cap. An authenticated low-privilege AMQP user can crash the entire broker node in fewer than 100 bind calls.

RabbitMQ prior to versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0: add_binding/3 parses the routing key as an integer weight N and computes ring positions with lists:seq(NextN0, NextN0 + N - 1). validate_binding/2 only checks N >= 1 with no upper bound. A user with write permission on a consistent-hash exchange can create a binding with a huge weight, allocating hundreds of megabytes on every cluster node.

In RabbitMQ prior to versions 4.0.22, 4.1.11, 4.2.6, and 4.3.0, the HTTP handler accept_content/2 calls create_super_stream without the required configure permission check on the exchange and partition queues that is present in the stream-protocol path. A user with the management tag and vhost access but no configure permission can create super-streams via the HTTP API.

RabbitMQ prior to versions 4.1.11, 4.2.6, and 4.3.0: validate_partitions only checks that the requested partition count is at least 1, with no upper bound. A large count such as lists:seq(0, 500000000) allocates roughly 8GB.

In the RabbitMQ management UI (versions prior to 3.13.15, 4.0.20, 4.1.11, and 4.2.6), TLS client certificate details such as Subject and Issuer DN are rendered without HTML escaping. The vulnerability is reachable when a TLS listener is configured with verify_peer and an attacker holds a CA-signed client certificate with an arbitrary Subject CN. When an administrator views that connection in the UI, the injected script executes in the admin's browser session, leading to account takeover.

In RabbitMQ prior to versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.1, the /federation-links/.../restart route uses is_authorized_monitor which accepts the monitoring tag, and DELETE triggers a federation link restart without an elevated permission check. A monitoring-tagged user can restart any federation link.

In RabbitMQ, match_value/3 passes the user-supplied ?name= regular expression to re:run with no match_limit option and executes it once per resource in the result set. With a large result set, a single request can consume many minutes of CPU, and parallel requests saturate the schedulers. The path is reachable through normal API use with the use_regex=true option.

In RabbitMQ, get_chunk_selector/1 calls binary_to_atom on the raw client-supplied <<"chunk_selector">> property from post-auth subscribe and resolve_offset_spec frames, with no whitelist and no existing guard. An authenticated stream client with read access to any stream can crash the broker node.

In RabbitMQ prior to versions 4.1.13, 4.2.7, and 4.3.0, is_authorized/2 uses is_authorized_monitor for all methods, and DELETE resets authentication attempt counters. A monitoring-tagged user can reset these counters via DELETE /api/auth/attempts/:node, erasing evidence of brute-force activity.

In RabbitMQ, the ?LOG_DEBUG macro formats the entire Shovel state map, including the 'uris' field holding decrypted URIs with credentials. With DEBUG logging enabled, autodelete-shovel completion writes the full state map, including amqp://user:password@host/, to the broker log file.

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.