CVE-2026-67228 in RabbitMQ
Summary
by MITRE • 09/24/2026
RabbitMQ is a messaging and streaming broker. Prior to versions 4.2.7 and 4.3.1, The runtime-parameters lookup path coerces the URL :component segment to an atom with rabbit_data_coercion:to_atom/1 in lookup_component/1 (deps/rabbit/src/rabbit_runtime_parameters.erl), creating a new atom for any previously unseen value. A safe helper, rabbit_registry:binary_to_type/1, which uses binary_to_existing_atom with a catch, already exists but is not used at this call site. lookup_component/1 calls rabbit_data_coercion:to_atom(Component) on the :component segment of the request URL, converting an attacker-supplied string into a new atom. Because the Erlang atom table is bounded and atoms are never garbage collected, an authorized policymaker issuing roughly one million requests with distinct component values can exhaust the atom table and crash the node, resulting in a denial of service. Preconditions include Exploitation requires policymaker privileges and roughly one million requests.. This issue is fixed in versions 4.2.7 and 4.3.1.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/24/2026
RabbitMQ serves as a critical messaging and streaming broker within modern distributed systems, relying on the Erlang programming language for its core functionality. A significant vulnerability exists in the handling of runtime parameters prior to versions 4.2.7 and 4.3.1. The flaw resides specifically within the lookup_component function located in the rabbit_runtime_parameters module. This component is responsible for processing requests related to RabbitMQ's runtime configuration, which allows administrators or authorized users to modify system behavior dynamically without restarting the broker. The security issue arises from how this function processes the :component segment of the incoming URL request path. Instead of using a safe conversion method that limits atom creation, the code invokes rabbit_data_coercion:to_atom/1 on user-supplied input.
In Erlang, atoms are unique constants where their names serve as their values. A critical characteristic of Erlang is that once an atom is created, it remains in memory for the lifetime of the process and cannot be garbage collected. The system maintains a bounded table of these atoms to optimize lookup performance. When rabbit_data_coercion:to_atom/1 receives a binary string that does not already exist as an atom, it creates a new entry in this global atom table. While this mechanism is efficient for known, finite sets of values such as predefined command names or status codes, it becomes dangerous when applied to arbitrary user input. The vulnerability exploits the fact that lookup_component/1 uses this coercion function on data derived directly from the request URL without validating whether the value corresponds to an existing atom or a safe, limited set of identifiers.
Although RabbitMQ provides a safer alternative in the form of rabbit_registry:binary_to_type/1, which utilizes binary_to_existing_atom with error handling to prevent unbounded growth, this helper was not utilized at the vulnerable call site. Consequently, any authorized user possessing policymaker privileges can trigger the creation of new atoms by sending requests with distinct component values. Because there is no limit on the number of unique strings that can be submitted as part of the URL path, an attacker can systematically generate a vast number of unique atom names. This behavior directly maps to CWE-770: Allocation of Resources Without Limits or Throttling and CWE-1321: Improperly Controlled Internal Entity Creation in Erlang/Elixir applications.
The operational impact of this flaw is severe, leading to a denial of service condition. As the attacker continues to submit requests with unique component values, the Erlang node's atom table gradually fills up. Once the limit defined by the system configuration or hardware constraints is reached, the node can no longer create new atoms. This state causes subsequent operations that require atom creation to fail, effectively crashing the RabbitMQ node and disrupting all messaging services hosted on it. The exploitation requires approximately one million distinct requests with unique component values to exhaust the default atom table limits in many standard configurations. Therefore, preconditions for successful exploitation include having authorized policymaker privileges and the ability to send a high volume of crafted HTTP or AMQP management API requests targeting this specific endpoint.
This vulnerability aligns with ATT&CK technique T1499: Endpoint Denial of Service, specifically under sub-techniques involving resource exhaustion through application layer attacks. It highlights the importance of secure coding practices in functional languages where memory management differs significantly from traditional garbage-collected environments like Java or Python. Developers must ensure that any user-controlled input is validated against a whitelist of allowed values before being processed as an atom, rather than relying on coercion functions that assume finite and known inputs.
Mitigation for this vulnerability involves upgrading RabbitMQ to version 4.2.7 or later, where the lookup_component function has been patched to use safe atom conversion methods or input validation. For organizations unable to immediately upgrade, implementing a Web Application Firewall rule to restrict the length of URL paths or limit the rate of requests from individual clients can provide temporary relief by slowing down the exhaustion process. Additionally, administrators should review access controls for policymaker privileges to ensure that only trusted personnel have permission to modify runtime parameters. Monitoring system logs for errors related to atom table limits and setting up alerts for unusual spikes in API request volume can also aid in early detection of such exploitation attempts.