CVE Vulnerability Catalog

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.

Vulnerability in RabbitMQ from 3.13.0 until 4.3.3, 4.2.9, 4.1.14, 4.0.23, and 3.13.18, where JWKS fetch ignores HTTP response status code. 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 lacking a keys field, all previously cached signing keys are destroyed, causing persistent authentication denial of service.

Vulnerability in RabbitMQ from 4.1.0 until 4.3.3, 4.2.9, and 4.1.11, allowing low-privilege node denial of service via stream management super-stream binding keys allocation. The handler accepts PUT /api/stream/super-streams/{vhost}/{name} from an authenticated management user with access to 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 can force large transient allocations. In a 768 MB memory-limited container, one HTTP PUT with about 4.5 MB of JSON body killed the container.

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

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

Readwise Reader for Android uses a sanitize-html configuration that permits all attributes on SVG and PATH elements due to a wildcard attribute rule. This configuration fails to remove script-capable attributes such as event handlers (e.g., 'onload', 'onerror'). An attacker could supply a document containing malicious SVG content that survives sanitization and executes script when rendered in the Reader WebView, resulting in client-side cross-site scripting (XSS).