CVE-2026-66078: RabbitMQ Protected User Auth Bypass Vulnerability

CVE-2026-66078 Overview

CVE-2026-66078 is a missing authorization flaw [CWE-862] in the RabbitMQ management plugin. The POST /api/users/bulk-delete endpoint fails to enforce the protected user tag safeguard that the single-user delete endpoint applies. An administrator can delete protected-tagged service accounts by submitting their usernames in a bulk-delete request. The flaw affects RabbitMQ versions 3.13.0 through 3.13.14, 4.0.x through 4.0.19, 4.1.x through 4.1.10, and 4.2.x through 4.2.5. Fixed versions are 3.13.15, 4.0.20, 4.1.11, and 4.2.6.

Critical Impact

An authenticated administrator can bypass the protected-user guard and delete service accounts intended to be shielded from deletion, enabling disruption of broker operations that depend on those accounts.

Affected Products

• RabbitMQ Server 3.13.0 through 3.13.14
• RabbitMQ Server 4.0.0 through 4.0.19 and 4.1.0 through 4.1.10
• RabbitMQ Server 4.2.0 through 4.2.5 (rabbitmq_management plugin enabled)

Discovery Timeline

• 2026-09-25 - CVE-2026-66078 published to NVD
• 2026-09-29 - Last updated in NVD database

Technical Details for CVE-2026-66078

Vulnerability Analysis

The RabbitMQ management plugin exposes two HTTP paths for removing users. The single-user path DELETE /api/users/:name is handled by rabbit_mgmt_wm_user:delete_resource/2, which calls is_protected_user/1 and refuses to delete any account carrying the protected tag. The bulk path POST /api/users/bulk-delete iterates the supplied username list and calls rabbit_auth_backend_internal:delete_user/2 directly. That backend function performs no protected-tag check, so the guard enforced on the single-user endpoint is silently skipped.

The protected tag exists to prevent accidental or malicious deletion of service accounts that the broker and connected applications rely on. Removing such accounts can sever queue consumers, publishers, and management automation that authenticate with those credentials.

Root Cause

The root cause is an authorization check that was implemented at the resource handler for the single-user endpoint but was not replicated in the bulk handler. The bulk endpoint trusts the administrator role as sufficient authorization and does not consult rabbit_mgmt_util:is_protected_user/1 before invoking the deletion backend. This is a classic missing authorization pattern tracked under [CWE-862].

Attack Vector

Exploitation requires an authenticated session with the administrator tag and network access to the management HTTP API. The attacker submits a bulk-delete request containing the username of a protected service account. The handler loops over the list and deletes each entry without consulting the protected-tag guard.

The patch adds the missing check to the comprehension in rabbit_mgmt_wm_users_bulk_delete.erl:

       [users], ReqData0, Context,
       fun([Users], _, ReqData) ->
               [rabbit_auth_backend_internal:delete_user(User, ActingUser)
-               || User <- Users],
+               || User <- Users, not rabbit_mgmt_util:is_protected_user(User)],
             {true, ReqData, Context}
       end).

Source: RabbitMQ patch commit e5b890a

Detection Methods for CVE-2026-66078

Indicators of Compromise

• HTTP POST requests to /api/users/bulk-delete where the JSON body users array contains names of accounts tagged protected.
• RabbitMQ internal events of type user.deleted emitted for service accounts not expected to be removed.
• Authentication failures from applications and consumers immediately following a bulk-delete call, indicating credentials were destroyed.

Detection Strategies

• Parse management plugin access logs for the /api/users/bulk-delete path and alert when the request originates from any user other than a short, approved administrator allowlist.
• Correlate user.deleted broker events against an inventory of accounts carrying the protected tag and raise an alert on any match.
• Monitor for a spike in AMQP or STOMP authentication failures from known service account identities after management API write activity.

Monitoring Recommendations

• Forward RabbitMQ management HTTP access logs and internal event stream to a centralized logging platform for continuous review.
• Baseline normal administrative activity against the management API and alert on deviations in request volume or request method mix.
• Track changes to the user list and tag assignments on a scheduled interval to detect unauthorized modifications.

How to Mitigate CVE-2026-66078

Immediate Actions Required

• Upgrade RabbitMQ Server to 3.13.15, 4.0.20, 4.1.11, or 4.2.6 depending on the deployed branch.
• Audit the current set of accounts carrying the administrator tag and remove any that are not operationally required.
• Review broker event history for user.deleted entries referencing protected service accounts since the vulnerable version was installed.

Patch Information

The fix is published in RabbitMQ 3.13.15, 4.0.20, 4.1.11, and 4.2.6. The patch adds not rabbit_mgmt_util:is_protected_user(User) to the comprehension that invokes rabbit_auth_backend_internal:delete_user/2. See the GitHub Security Advisory GHSA-j9m2-hw6x-rqr9 and the RabbitMQ v4.2.6 release notes for details.

Workarounds

• Restrict network access to the management HTTP API using firewall rules or a reverse proxy that allows only operator workstations.
• Use a reverse proxy or web application firewall rule to block POST requests to /api/users/bulk-delete until patching is complete.
• Reduce the number of accounts holding the administrator tag to minimize the pool of principals able to invoke the vulnerable endpoint.

# Example nginx snippet blocking the vulnerable endpoint pre-patch
location = /api/users/bulk-delete {
    return 403;
}