RabbitMQ EUVD-2026-87225

Exploitation requires ALL of: 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 enabled (non-default). These are significant limiting factors - the attacker must already be a highly privileged, authenticated tenant, and the vulnerable Shovel management surface must be explicitly turned on. Affected versions are RabbitMQ 4.2.0 through before 4.2.9 and before 4.3.3. The abuse is not achievable against a default configuration lacking the Shovel plugins or by unauthenticated/low-privilege users. Note the persistence angle: because malicious parameters are stored durably and reparsed on worker start, the DoS can recur after restart without a live attacker.

This is a genuine but low-priority DoS issue - high-CVSS optics tempered by heavy preconditions. The provided CVSS 4.0 vector (5.9, AV:N/AC:L/AT:P/PR:H/UI:N/VC:N/VI:N/VA:H) correctly encodes the reality: network-reachable but requiring high privileges (PR:H) and an attack requirement (AT:P) reflecting the effort to exhaust the atom table plus the non-default plugin/tag prerequisites. Impact is availability-only (VC:N/VI:N/VA:H) - no confidentiality or integrity exposure, consistent with the CWE-400 resource-exhaustion classification and the 'Denial Of Service' tag. No EPSS score, no CISA KEV listing, and no public POC were provided, so there is no evidence of active or automated exploitation; this reads as a targeted-abuse scenario by an already-privileged tenant, not a mass-exploitation threat. The one aggravating factor beyond raw metrics: malicious Shovel parameters are stored durably and reparsed when workers start, so atom pressure can recur after node restart without a live attacker - a persistence characteristic that raises operational severity for multi-tenant brokers. Net: legitimately actionable for exposed multi-tenant RabbitMQ 4.2.x deployments running the Shovel plugins, but not an emergency for the typical single-tenant or plugin-disabled install.

An authenticated tenant holding both the management and policymaker tags on a vhost of a RabbitMQ 4.2.x broker (with rabbitmq_shovel and rabbitmq_shovel_management enabled) repeatedly sets Shovel runtime parameters via the Management HTTP API using novel string values. Each unique value is converted to a permanent, non-garbage-collected Erlang atom, and enough requests exhaust the node-wide atom table and crash the BEAM VM. Because the parameters are stored durably and reparsed when Shovel workers restart, the atom pressure recurs after node restart even with no attacker connected. No public exploit code was identified at time of analysis.