RabbitMQ EUVD-2026-87149

Requires an authenticated account carrying the RabbitMQ 'management' tag (the lowest management privilege) with access to at least one vhost, and the management plugin/HTTP API must be reachable by the attacker. The specific vector is the 'node' JSON field accepted by PUT /api/queues/:vhost/:name and the equivalent exchanges and bindings endpoints, routed through get_node/1 in rabbit_mgmt_util.erl which calls list_to_atom without a prior cluster-membership check. Exploitation is limited by needing valid management credentials (PR:L, not anonymous) and by requiring sustained abuse - on the order of 900,000 unique requests - to drive the atom table to system_limit, rather than a single request; impact is a node-wide VM crash affecting all tenants. Fixed configurations are versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6.

This is a legitimate but moderate-severity availability issue. The supplied CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:H, base 6.0) is internally consistent with the description: network-reachable management API, low complexity, an attack requirement (AT:P) reflecting the need to accumulate roughly 900K requests to exhaust the atom table, low-privilege authentication (any user holding the 'management' tag plus one vhost), and pure availability impact (VA:H) with no confidentiality or integrity loss. No EPSS score, no CISA KEV listing, and no public exploit are present in the input, so exploitation is not confirmed in the wild. The realistic priority is tempered by three factors: exploitation requires valid management-API credentials (PR:L, not an anonymous internet attacker), it requires sustained abuse (~900K crafted requests) rather than a single packet, and the impact is a recoverable crash rather than data compromise. One data caveat: the fix commit diff provided (7f643114) modifies rabbit_auth_backend_oauth2.erl safe_to_atom for token tag scopes via to_existing_atom, which is NOT the get_node/1 vector in rabbit_mgmt_util.erl that the description names as the primary attack path - the commit appears to bundle multiple atom-hardening changes, but the specific get_node fix is not visible in the supplied evidence and should be verified against the release. Overall: a real, patch-worthy DoS for multi-tenant RabbitMQ operators, but not an emergency drop-everything issue.

A low-privilege tenant who holds only the RabbitMQ 'management' tag and access to a single vhost scripts repeated PUT /api/queues/:vhost/:name (or exchanges/bindings) requests, each supplying a unique unused value in the JSON 'node' field. Because get_node/1 converts the value with list_to_atom before any cluster-membership check, every distinct value permanently leaks one atom; after roughly 900K such requests the Erlang atom table hits system_limit and the VM crashes, taking down messaging for all tenants on the node. No public exploit code is identified at time of analysis, and the attack requires sustained request volume rather than a single trigger.