CVE-2026-67226 in RabbitMQ
Summary
by MITRE • 09/25/2026
RabbitMQ is a messaging and streaming broker. From 4.0.0 until 4.0.22 and 4.1.14 and 4.2.7, Admin-only atom exhaustion: PUT /api/users tags list. settags/2 maps rabbitdatacoercion:toatom/1 over the user's tags list. The 20 MB management body limit fits ~3-4M short tag strings. An administrator can crash the node in a single request by creating a user (or importing definitions) with ~1M unique tag administrator. This issue is fixed in versions 4.0.22 and 4.1.14 and 4.2.7.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/25/2026
RabbitMQ serves as a robust messaging broker facilitating communication between distributed systems, yet it contains a critical vulnerability within its administrative interface that allows for resource exhaustion attacks. The flaw resides in the handling of user tag assignments via the management HTTP API, specifically when an administrator utilizes the PUT endpoint to update or create users with associated tags. In versions ranging from 4.0.0 through 4.0.22, as well as 4.1.x up to 4.1.14 and 4.2.x up to 4.2.7, the system processes these inputs using a function called rabbitdatacoercion:toatom/1. This internal mechanism converts string values into Erlang atoms for efficient lookup and management within the broker's data structures. While this design choice optimizes performance for typical usage patterns where tag counts are low and distinct, it introduces a severe security risk when dealing with unbounded or high-cardinality inputs from administrative endpoints that lack sufficient validation limits on unique atom creation.
The technical core of the vulnerability lies in how Erlang handles atoms. Unlike standard strings which can be garbage collected if no longer referenced, atoms reside in an internal table within the Erlang Virtual Machine (BEAM) and are never automatically reclaimed by the garbage collector. This means that every unique string converted to an atom consumes memory permanently until the node is restarted. The management UI imposes a body size limit of approximately 20 MB on incoming requests, which might seem like a sufficient safeguard against large payloads. However, because this limit applies to the total byte count rather than the number of distinct entries, an attacker can craft a request containing millions of short, unique tag strings that fit within the 20 MB boundary but result in the creation of roughly one million unique atoms. This discrepancy between payload size and atom count is the key factor enabling the exploit.
An authenticated administrator with access to user management functions can trigger this flaw by creating a new user or importing definitions via the API, assigning them a list containing approximately one million unique tag strings. Upon processing this request, the broker attempts to register each of these tags as distinct atoms in the BEAM atom table. Since there is no cap on the total number of atoms that can be created per node, this operation rapidly exhausts available memory and system resources dedicated to maintaining the atom dictionary. The consequence is a denial of service condition where the RabbitMQ node becomes unresponsive or crashes entirely due to resource exhaustion. This impact affects not only the targeted user account but also degrades performance for all other services relying on that broker instance, potentially causing widespread disruption in production environments dependent on reliable message delivery.
This vulnerability aligns with CWE-787 Out-of-bounds Write and more specifically CWE-400 Uncontrolled Resource Consumption, as it involves the unregulated allocation of system resources leading to service degradation or failure. From a tactical perspective, this attack vector corresponds to ATT&CK technique T1499 Endpoint Denial of Service, where an adversary leverages administrative privileges to disrupt availability rather than compromising confidentiality or integrity directly. The exploitation requires valid administrator credentials and access to the management API, highlighting that while the impact is severe, it relies on a higher level of trust within the system's security model.
Mitigation strategies primarily involve upgrading to patched versions of RabbitMQ, specifically 4.0.22, 4.1.14, or 4.2.7 and later releases where this issue has been resolved by implementing stricter limits on atom creation or changing how tags are stored internally to avoid the unbounded growth of the atom table. For organizations unable to immediately patch their infrastructure, restricting access to the management UI API is critical. Administrators should ensure that only trusted personnel have write access to user definitions and consider implementing additional validation layers at a reverse proxy or gateway level if possible. Furthermore, monitoring for unusual spikes in memory usage associated with the BEAM atom table can help detect potential exploitation attempts before they result in full node crashes. Regular audits of imported definition files are also recommended to ensure that bulk operations do not inadvertently introduce excessive unique identifiers into user profiles.