RabbitMQ Server CVE-2026-66078

Requires all of: the rabbitmq_management plugin enabled (the vulnerable POST /api/users/bulk-delete endpoint lives there); the attacker possessing an account with the 'administrator' tag; and at least one user carrying the 'protected' tag to bypass. Exploitation is limited to bypassing the protected-user deletion safeguard - it grants no new access and requires the highest management privilege level, so realistic risk is confined to insider misuse, a compromised admin credential, or accidental bulk deletion of hardened service accounts. Affects versions 3.13.0 up to 3.13.15, and 4.0.x/4.1.x/4.2.x before 4.0.20/4.1.11/4.2.6.

This is a genuinely low-priority finding despite being an authorization-control weakness. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:H/UI:N/VC:N/VI:L/VA:N) scores only 2.1, and my independent assessment agrees: the attacker must already hold the RabbitMQ 'administrator' tag (PR:H), meaning this is a bypass of an internal safeguard by a privileged actor, not a privilege-escalation or external-access flaw. The only impact is integrity-low - an admin can delete users flagged 'protected' via POST /api/users/bulk-delete, which the single-user DELETE endpoint would refuse. There is no confidentiality impact and no direct availability impact in the CVSS sense. No EPSS score, no CISA KEV listing, and no public exploit were provided; exploitation status is 'no public exploit identified at time of analysis.' The signals are internally consistent (network-reachable management API, but high privilege and trivial impact), so there is no conflict to flag - the low CVSS accurately reflects low real-world risk. The 'protected' tag is a defense-in-depth guard against accidental deletion of critical service accounts, and this bug means a compromised or malicious administrator (or an admin acting by mistake) can circumvent it; it is a hardening fix, not an urgent patch.

An attacker who has already obtained an account with the RabbitMQ administrator tag (or a malicious/careless admin) sends POST /api/users/bulk-delete with a JSON body listing protected-tagged service accounts. Because the bulk-delete handler called rabbit_auth_backend_internal:delete_user/2 directly without the is_protected_user check that guards the single-user DELETE endpoint, the protected accounts are silently removed. No public exploit code is identified, but the technique is trivial and confirmed by the vendor's added regression test.