CVE-2026-67229 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, and 4.3.0, add_vhost/2 calls rabbit_data_coercion:atomize_keys/1 (the unsafe variant using binary_to_atom) on the vhost metadata map. The 20 MB management body limit fits ~1M+ short keys. Admin-only. An administrator importing a crafted definitions file can crash the node in a single request: a vhosts entry with ~1M unique metadata keys exhausts the atom table during import. Preconditions include administrator tag. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/24/2026
RabbitMQ serves as a robust messaging and streaming broker widely deployed in enterprise environments to facilitate asynchronous communication between distributed systems. A critical vulnerability exists within the management interface of RabbitMQ versions prior to 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0. This flaw is rooted in the handling of virtual host metadata during configuration imports via the add_vhost/2 function. Specifically, the system invokes rabbit_data_coercion:atomize_keys/1, which utilizes the unsafe binary_to_atom Erlang function to process keys within the vhost metadata map. In the Erlang runtime environment, atoms are not garbage collected and their quantity is strictly limited by the virtual machine's atom table size. When an administrator imports a definitions file containing a crafted payload with approximately one million unique metadata keys for a single virtual host entry, each key triggers the creation of a new atom in memory.
The operational impact of this vulnerability is severe, resulting in a denial-of-service condition that crashes the RabbitMQ node. The management UI imposes a body limit of 20 MB, which is sufficient to accommodate the massive number of short keys required to exhaust the available atom space. Once the atom table reaches its maximum capacity, the Erlang runtime cannot allocate new atoms, leading to an immediate crash or halt in service availability for all connected clients and applications relying on that broker node. This issue highlights a significant risk associated with configuration management features where untrusted or improperly validated input can lead to resource exhaustion at the language runtime level rather than just application logic levels.
From a threat modeling perspective, this vulnerability aligns with CWE-787: Out-of-bounds Write in terms of memory allocation limits and more accurately with CWE-400: Uncontrolled Resource Consumption because it leads to system instability through excessive resource usage. In the context of the MITRE ATT&CK framework, this behavior is indicative of T1499: Endpoint Denial of Service, specifically under techniques that involve exhausting resources such as memory or CPU cycles to disrupt service availability. The attack vector requires administrative privileges, classifying it as an insider threat scenario or a compromise of high-privilege accounts rather than an external unauthenticated exploit.
Mitigation strategies primarily involve upgrading the RabbitMQ installation to one of the patched versions listed above, which replace the unsafe binary_to_atom call with safer alternatives that do not permanently consume atom table entries for dynamic data keys. For organizations unable to immediately patch their systems due to operational constraints, strict access control policies must be enforced on the management UI and API endpoints. Administrators should ensure that only trusted personnel have import capabilities and that definitions files are validated against expected schema structures before ingestion. Additionally, monitoring tools should be configured to alert on unusual spikes in memory usage or atom table consumption rates within the Erlang VM metrics provided by RabbitMQ's health checks.