CVE-2026-67415: 
RabbitMQ vulnerability analysis and mitigation

CVE-2026-67415 is a Denial of Service vulnerability in RabbitMQ's Shovel parameter parser, dubbed "Shovel Management Atom Exhaustion Allows Persistent Broker-Wide Denial of Service." The flaw affects RabbitMQ versions 4.2.0 through 4.2.8 and 4.3.0 through 4.3.2, and was disclosed on July 23, 2026 by researcher Trung Nguyen (@everping) of CyStack. It carries a CVSS v4.0 base score of 5.9 (Medium) (GitHub Advisory). Patches were released in versions 4.2.9 and 4.3.3 (v4.2.9 Release, v4.3.3 Release).

The root cause is Uncontrolled Resource Consumption (CWE-400): the Shovel parameter parser converts attacker-controlled runtime parameter values into Erlang atoms using rabbit_data_coercion:to_atom/1 (and equivalent functions) before validating or bounding them against an allowlist. Erlang atoms are global to the VM and are never garbage-collected, so each unique value permanently consumes an entry in the node-wide atom table (default limit: 5,000,000). The vulnerable code paths exist in deps/rabbitmq_shovel/src/rabbit_shovel_parameters.erl (for src-protocol and dest-protocol fields) and deps/rabbitmq_shovel/src/rabbit_amqp10_shovel.erl (for AMQP 1.0 dest-properties map keys), the latter being especially dangerous as a single HTTP request can contain thousands of unique keys. Additionally, rabbit_shovel_worker.erl reparses stored Shovel parameters on worker startup, meaning malicious parameters persisted in durable storage recreate atom pressure after a broker restart without any live attacker connection (GitHub Advisory).

Successful exploitation results in complete unavailability of the RabbitMQ broker node — all vhosts on the node become unreachable, not just the attacker's vhost, because the Erlang atom table is a global VM resource. In lab testing, the broker crashed within approximately 64 seconds under a high-volume attack. The persistent variant is particularly severe: if sufficient malicious Shovel parameters are stored before cleanup, the broker can crash during startup after a restart, requiring offline operator intervention to remove poisoned runtime parameters from the metadata database — a plain process restart may repeat the crash. There is no confidentiality or integrity impact beyond the availability disruption (GitHub Advisory).

A standalone Python proof-of-concept script (poc_shovel_atom_exhaustion.py) is publicly available in the GitHub Security Advisory, with both safe (low-count) and destructive modes (GitHub Advisory). Exploitation is not automated (NVD SSVC: automatable=no) and requires authenticated access with specific privileges, making opportunistic mass exploitation unlikely. The EPSS score is 0.00353, indicating a low probability of exploitation in the wild, and there is no evidence of in-the-wild exploitation or CISA KEV catalog listing at this time. The vulnerability is detected by Nessus plugin 350752.

1. Reconnaissance: Identify RabbitMQ instances running versions 4.2.0–4.2.8 or 4.3.0–4.3.2 with the Management HTTP API exposed (default port 15672) and the rabbitmq_shovel and rabbitmq_shovel_management plugins enabled.
2. Authenticate: Obtain or use valid credentials for a user account with both management and policymaker tags and permission to set Shovel runtime parameters on at least one vhost. Send an HTTP Basic Auth request to the Management API to confirm access.
3. Craft malicious payload: Construct a JSON Shovel runtime parameter payload with a dest-properties field containing a map with thousands of unique arbitrary keys (e.g., 20,000 unique keys per request). Each key will be passed to rabbit_data_coercion:to_atom/1 in rabbit_amqp10_shovel.erl without validation.
4. Submit the parameter: Send a PUT request to /api/parameters/shovel/{vhost}/{shovel_name} with the crafted JSON payload. Each unique key in dest-properties permanently consumes an entry in the Erlang VM atom table.
5. Repeat with concurrent workers: Send multiple requests with different unique key sets using concurrent workers (e.g., 4 workers, 110+ requests) to rapidly exhaust the atom table. In lab testing, atoms grew from ~2.9M to 4.9M in ~60 seconds before the broker crashed at the 5M limit.
6. Observe broker crash: Monitor the broker; when the atom table is exhausted, the broker emits no more index entries in atom_tab (max=5000000) and becomes unreachable. rabbitmq-diagnostics -q ping will fail.
7. (Persistent variant) Ensure parameters are stored durably: Do not delete the malicious Shovel parameters. On broker restart, rabbit_shovel_worker.erl will reparse stored parameters and recreate atom pressure, potentially crashing the broker again during startup without any further attacker action (GitHub Advisory).

• Network: Unusual volume of PUT requests to /api/parameters/shovel/{vhost}/{name} from a single source IP on the Management HTTP API port (default 15672); requests containing large JSON payloads with many unique keys in dest-properties.
• Logs: RabbitMQ broker log (rabbit.log) containing no more index entries in atom_tab (max=5000000) immediately before broker unavailability; repeated Shovel parameter creation events from a single user account in management audit logs.
• Process/Runtime: Rapidly increasing Erlang atom count observable via rabbitmq-diagnostics -q runtime_info or the Management API /api/nodes endpoint (mem_atom metric); rabbitmq-diagnostics -q ping returning failure.
• Persistence: Presence of Shovel runtime parameters with unusually large dest-properties maps in the broker's durable metadata store; broker crashing during startup with atom table exhaustion errors after a restart, indicating stored malicious parameters (GitHub Advisory).

Upgrade RabbitMQ to version 4.2.9 (for the 4.2.x series) or 4.3.3 (for the 4.3.x series), which fix the vulnerability by replacing unconstrained atom creation with allowlist validation and keeping keys as binaries where possible (v4.2.9 Release, v4.3.3 Release). If immediate upgrade is not possible, apply the following mitigations: (1) disable the rabbitmq_shovel and rabbitmq_shovel_management plugins if not operationally required; (2) restrict access to the Management HTTP API to trusted administrators only, using network-level controls; (3) audit and restrict which users hold the management and policymaker tags and have Shovel parameter-setting permissions on any vhost. If malicious parameters have already been stored, they must be removed offline (e.g., by disabling Shovel, deleting the parameters, or resetting the metadata database) before restarting the broker (GitHub Advisory).

The vulnerability was responsibly disclosed by Trung Nguyen (@everping) of CyStack and published as a GitHub Security Advisory by RabbitMQ maintainer michaelklishin (GitHub Advisory). The advisory notes that the security boundary issue — where a per-vhost delegated privilege can exhaust a global Erlang VM resource — may warrant a higher severity rating (up to Critical) in deployments that delegate policymaker to tenant or application administrators. No significant broader media coverage or notable social media reactions have been identified beyond standard vulnerability database aggregation.