CVE-2026-66069: RabbitMQ Auth Bypass Vulnerability

CVE-2026-66069 Overview

CVE-2026-66069 is a missing authorization vulnerability [CWE-862] in RabbitMQ, an open-source messaging and streaming broker. The flaw resides in the Management plugin's is_authorized/2 function, which incorrectly uses is_authorized_monitor for all HTTP methods, including DELETE. As a result, a user assigned only the monitoring tag can invoke DELETE /api/auth/attempts/:node and reset the per-node authentication-attempt counters via rabbit_core_metrics:reset_auth_attempt_metrics(). The sibling endpoint handled by rabbit_mgmt_wm_reset.erl correctly requires administrator privileges. The issue affects RabbitMQ versions prior to 4.1.13, 4.2.7, and 4.3.0.

Critical Impact
A monitoring-tagged user can erase evidence of brute-force authentication activity by clearing per-node auth-attempt counters over the Management API.

Affected Products

RabbitMQ versions prior to 4.1.13
RabbitMQ versions prior to 4.2.7 in the 4.2.x branch
RabbitMQ versions prior to 4.3.0 in the 4.3.x branch

Discovery Timeline

2026-09-23 - CVE CVE-2026-66069 published to NVD
2026-09-23 - Last updated in NVD database

Technical Details for CVE-2026-66069

Vulnerability Analysis

RabbitMQ's Management plugin exposes an HTTP API for administrative and monitoring operations. Access control for these endpoints is enforced by is_authorized/2 in the request handler modules. For the authentication-attempts resource, the handler applies is_authorized_monitor uniformly across all HTTP methods.

Because DELETE is not distinguished from read operations, a caller possessing only the monitoring tag satisfies the authorization check for a destructive action. A DELETE request against /api/auth/attempts/:node invokes rabbit_core_metrics:reset_auth_attempt_metrics(), zeroing the per-node counters that track successful and failed authentication attempts.

The impact is limited to counter state. Log records and audit trails are not deleted. However, monitoring dashboards and alerting rules that depend on these counters can be silenced, obscuring brute-force or credential-stuffing activity. The equivalent reset in rabbit_mgmt_wm_reset.erl correctly enforces an administrator check, confirming the inconsistency is the root defect.

Root Cause

The root cause is a missing authorization check [CWE-862] for state-mutating methods in the auth-attempts endpoint. The handler applies a monitor-level authorization predicate to DELETE, whereas destructive operations require an administrator predicate consistent with rabbit_mgmt_wm_reset.erl.

Attack Vector

Exploitation requires the Management plugin to be enabled and the attacker to hold valid credentials for an account tagged monitoring. The attacker sends an authenticated DELETE request to /api/auth/attempts/:node over the Management API. The server executes reset_auth_attempt_metrics() and returns success, clearing the counters used to surface authentication anomalies.

// Illustrative request pattern (see GHSA-fhwq-9rvh-prj2 for details)
DELETE /api/auth/attempts/<node> HTTP/1.1
Authorization: Basic <monitoring-user credentials>

Detection Methods for CVE-2026-66069

Indicators of Compromise

Unexpected DELETE /api/auth/attempts/<node> requests in RabbitMQ Management plugin access logs.
Sudden reset of per-node authentication-attempt counters without a corresponding administrator action.
Management API activity originating from accounts carrying only the monitoring tag.

Detection Strategies

Alert on any HTTP DELETE against the /api/auth/attempts/ path in reverse proxy or Management plugin logs.
Correlate counter resets with the authenticated user's tag set to flag non-administrator actors.
Baseline the frequency of reset_auth_attempt_metrics invocations and alert on anomalies.

Monitoring Recommendations

Forward RabbitMQ Management API access logs to a centralized log platform for retention independent of in-broker counters.
Retain authentication success and failure events at the source rather than relying solely on aggregated Management counters.
Review Management plugin user tags periodically to confirm least-privilege assignments.

How to Mitigate CVE-2026-66069

Immediate Actions Required

Upgrade RabbitMQ to 4.1.13, 4.2.7, 4.3.0, or later depending on the deployed branch.
Audit accounts with the monitoring tag and remove the tag from users that do not require metrics access.
Restrict network exposure of the Management plugin to trusted administrative networks.

Patch Information

The issue is fixed in RabbitMQ 4.1.13, 4.2.7, and 4.3.0. Release notes are available in the RabbitMQ Release v4.2.7 and RabbitMQ Release v4.3.0 advisories. Full technical details are documented in GitHub Security Advisory GHSA-fhwq-9rvh-prj2.

Workarounds

Block DELETE requests to /api/auth/attempts/ at a reverse proxy or web application firewall in front of the Management plugin.
Remove the monitoring tag from non-trusted users until the upgrade is applied.
Disable the Management plugin on nodes that do not require it with rabbitmq-plugins disable rabbitmq_management.

bash

# Example reverse-proxy rule to block DELETE on the affected endpoint (nginx)
location ~ ^/api/auth/attempts/ {
    limit_except GET { deny all; }
    proxy_pass http://rabbitmq_management;
}