CVE-2026-67415 in RabbitMQ
Summary
by MITRE • 09/25/2026
RabbitMQ is a messaging and streaming broker. From 4.2.0 until 4.2.9 and 4.3.3, the Shovel parameter parser converted attacker-controlled runtime parameter values into non-garbage-collected Erlang atoms before bounding them or checking a fixed allowlist. Exploitation requires network access to the Management HTTP API, valid credentials with both the management and policymaker tags, permission to set Shovel runtime parameters on a vhost, and the rabbitmq_shovel and rabbitmq_shovel_management plugins to be enabled. The attacker can exhaust the node-wide atom table and deny service, and malicious parameters are stored durably and reparsed when workers start, so atom pressure can recur after restart without a live attacker connection. This issue is fixed in versions 4.2.9 and 4.3.3.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/25/2026
RabbitMQ serves as a widely deployed messaging and streaming broker that facilitates asynchronous communication between distributed systems. A critical vulnerability was identified within the Shovel plugin, specifically affecting version ranges from 4.2.0 up to but not including 4.2.9, and versions prior to 4.3.3. The core technical flaw resides in the parameter parser for the Shovel runtime configuration. In these affected versions, the parser failed to properly sanitize or bound attacker-controlled input before converting it into Erlang atoms. This design oversight allowed malicious actors to inject arbitrary strings that were directly translated into non-garbage-collected atom identifiers within the Erlang virtual machine environment.
The exploitation of this vulnerability requires specific prerequisites and access conditions. An attacker must possess network-level connectivity to the RabbitMQ Management HTTP API, which exposes administrative endpoints for configuration management. Furthermore, the attacker needs valid authentication credentials that include both the management tag and the policymaker role. Crucially, these credentials must grant permission to set Shovel runtime parameters on a specific virtual host. The rabbitmq_shovel plugin along with its associated management interface must also be enabled within the broker instance. When these conditions are met, an attacker can submit crafted HTTP requests that trigger the flawed parsing logic.
The operational impact of this flaw is severe and centers around resource exhaustion leading to denial of service. In Erlang systems, atoms are stored in a node-wide atom table that has a fixed maximum size limit. Unlike regular heap memory, atoms are not subject to garbage collection once created. By repeatedly submitting parameters with unique or maliciously crafted values, an attacker can rapidly fill the atom table. Once this table reaches its capacity limit, the Erlang runtime throws an exception and terminates processes, effectively crashing the RabbitMQ node and denying service to all connected clients. This results in a complete disruption of messaging capabilities for any application relying on that broker instance.
A particularly dangerous aspect of this vulnerability is its persistence across system restarts. Malicious parameters submitted through the API are stored durably within the RabbitMQ configuration database or message queues associated with the Shovel plugin. Consequently, even if an attacker disconnects after triggering the initial crash, the corrupted configuration remains on disk. When the RabbitMQ node is restarted to recover from the denial of service event, the system attempts to reparse these durable parameters during worker initialization. This causes the atom table to fill up again automatically without any further live interaction from the attacker, creating a persistent and self-replicating denial-of-service condition that requires manual intervention to resolve by cleaning the stored configuration data.
From a classification perspective, this vulnerability aligns with CWE-787 Out-of-bounds Write in terms of resource exhaustion mechanics, though more accurately it maps to CWE-1325 Incorrectly Implemented Security Check for Constraints regarding the failure to validate input against expected bounds before processing. In the context of the MITRE ATT&CK framework, this behavior is consistent with T1498 Network Denial of Service, specifically reflecting techniques that involve exhausting system resources such as memory or process tables rather than overwhelming bandwidth. The persistence mechanism also touches upon aspects of maintaining access through configuration tampering, although the primary intent here is disruption rather than control retention.
Mitigation strategies focus primarily on upgrading to patched versions where this parsing logic has been corrected. Administrators should upgrade RabbitMQ to version 4.2.9 or later, or alternatively to version 4.3.3 and subsequent releases, which implement proper bounds checking and allowlist validation before atom creation. For environments that cannot immediately patch due to operational constraints, it is advisable to restrict access to the Management HTTP API using network firewalls or reverse proxies with strict authentication controls. Additionally, ensuring that only trusted users hold policymaker tags can limit the attack surface by preventing unauthorized entities from modifying Shovel parameters. Regular auditing of configuration changes and monitoring for unusual spikes in atom table usage can also provide early detection indicators before a full denial-of-service event occurs.