CVE-2026-67220 in RabbitMQ
Summary
by MITRE • 09/24/2026
RabbitMQ is a messaging and streaming broker. Prior to versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, 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 then erl_parse:parse_term/1. erl_scan:string/1 interns every atom literal it tokenizes. validate_binding/2 is a no-op (-> ok.), there is no length cap, and the surrounding try/catch cannot reclaim atoms. The Java JMS client compiles selectors client-side, but the server does not enforce this , a raw AMQP client can send arbitrary selector strings. An authenticated low-privilege AMQP user confined to one vhost can crash the entire broker node (cross-tenant DoS) in <100 bind calls. Preconditions include rabbitmq_jms_topic_exchange plugin enabled (bundled; required for any JMS deployment) Authenticated AMQP user with read on an x-jms-topic exchange + write on a queue (or configure to declare both). This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, 4.3.0.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/24/2026
The vulnerability identified involves a critical resource exhaustion flaw within the RabbitMQ messaging broker, specifically affecting versions prior to 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0 when utilizing the x-jms-topic exchange type. This component is part of the rabbitmq_jms_topic_exchange plugin, which is bundled with RabbitMQ and essential for Java Message Service deployments. The core technical flaw resides in the add_binding/3 function, which processes binding arguments including the rjms_erlang_selector parameter. When a new binding is created on an x-jms-topic exchange, this selector string is passed directly to erl_scan:string/1 followed by erl_parse:parse_term/1 for evaluation. The Erlang runtime system's atom table has a fixed maximum size, and every unique atom literal tokenized by erl_scan/string causes the creation of a new entry in this global atom table that persists for the lifetime of the node. Crucially, there is no length cap on the selector string provided by the client, nor does the validate_binding/2 function perform any sanitization or validation beyond returning an ok status. Furthermore, the surrounding try/catch block cannot reclaim these atoms once they are allocated, leading to a permanent increase in memory consumption for each unique atom generated.
This architectural oversight allows an authenticated low-privilege AMQP user confined to a single virtual host to execute a cross-tenant denial of service attack against the entire broker node. While Java JMS clients typically compile selectors client-side and send pre-evaluated expressions, raw AMQP clients can bypass this safeguard by sending arbitrary selector strings directly. By rapidly creating bindings with unique or varied selector strings containing distinct atom literals, an attacker can exhaust the Erlang VM's atom table limit in fewer than one hundred bind calls. Once the maximum number of atoms is reached, the RabbitMQ node becomes unresponsive and effectively crashes, disrupting service for all other tenants sharing that broker instance. This represents a severe availability risk as it enables a single compromised or malicious low-privilege account to impact the stability of the entire messaging infrastructure without requiring elevated privileges or cross-vhost access.
From a classification perspective, this vulnerability aligns with CWE-787 Out-of-bounds Write in terms of resource exhaustion mechanics and is more accurately categorized under CWE-400 Uncontrolled Resource Consumption due to the unbounded allocation of atoms leading to system failure. In the context of the MITRE ATT&CK framework, this behavior corresponds to T1499 Endpoint Denial of Service, specifically illustrating how application-layer flaws can be leveraged for resource exhaustion attacks that degrade service availability across multiple tenants in a shared environment. The lack of input validation and length constraints on server-side parsing functions is a common pattern in such vulnerabilities, highlighting the importance of strict parameter sanitization even when client libraries are expected to handle complex logic.
Mitigation strategies primarily involve upgrading RabbitMQ to one of the fixed versions: 3.13.15, 4.0.20, 4.1.11, 4.2.6, or 4.3.0, where these bounds and validation checks have been implemented to prevent uncontrolled atom allocation. For environments unable to upgrade immediately, administrators should enforce strict network-level access controls to ensure that only trusted applications can create bindings on x-jms-topic exchanges. Additionally, implementing rate limiting on binding creation operations at the proxy or load balancer level can help mitigate rapid-fire attacks designed to exhaust resources before patches are applied. It is also advisable to review AMQP client configurations and restrict direct raw protocol access where possible, ensuring that selector logic remains handled by trusted JMS clients rather than exposed to arbitrary input via standard AMQP binding commands.