CVE-2026-57217: RabbitMQ Server Auth Bypass Vulnerability

CVE-2026-57217 Overview

CVE-2026-57217 is a broken access control flaw [CWE-863] in RabbitMQ, the widely deployed open-source messaging and streaming broker maintained by Broadcom. The vulnerability affects topic authorization when the Khepri metadata store returns lookup errors. Errors collapse to undefined, which the internal authentication backend treats as an implicit allow decision. Authenticated users with limited permissions can perform restricted topic writes and bindings during metadata-store failures. The issue is fixed in versions 3.13.15, 4.0.21, 4.1.11, and 4.2.6.

Critical Impact
Authenticated low-privilege users can bypass topic-level authorization during Khepri metadata-store failures, enabling unauthorized writes and bindings on protected topics and exposure of confidential message data.

Affected Products

Broadcom RabbitMQ Server prior to 3.13.15
Broadcom RabbitMQ Server 4.0.x prior to 4.0.21
Broadcom RabbitMQ Server 4.1.x prior to 4.1.11 and 4.2.x prior to 4.2.6

Discovery Timeline

2026-07-10 - CVE-2026-57217 published to the National Vulnerability Database
2026-07-13 - Last updated in NVD database

Technical Details for CVE-2026-57217

Vulnerability Analysis

RabbitMQ enforces fine-grained topic authorization through permission records looked up in its metadata store. When the store backend is Khepri, transient errors during a lookup produce an {error, Reason} tuple. The internal authentication backend, rabbit_auth_backend_internal, only distinguished between a returned #topic_permission{} record and undefined. Any unexpected return value, including error tuples, was pattern-matched as undefined and interpreted as no restriction defined, resulting in an allow decision.

The consequence is authorization failure open. A restricted publisher or consumer can succeed in publishing to or binding against topics that the administrator explicitly restricted, provided the Khepri lookup returns an error at that moment. This weakens the security boundary between tenants sharing a broker and can lead to disclosure of message payloads routed through topic exchanges.

Root Cause

The root cause is a fail-open condition in rabbit_db_user:get_topic_permissions/3. The function contract previously specified a return of TopicPermission | undefined, so callers only handled two branches. Error propagation from Khepri was not represented in the type contract, so {error, _} values silently matched the fallthrough allow path.

Attack Vector

Exploitation requires network access to the AMQP or streaming endpoint and valid credentials with low privileges. During Khepri instability, such as leader elections, node restarts, or partitioned clusters, an attacker retries topic operations until a lookup error occurs. No user interaction is required.

text

// Patch: deps/rabbit/src/rabbit_auth_backend_internal.erl
     case rabbit_db_user:get_topic_permissions(Username, VHostPath, Name) of
         undefined ->
             true;
+        {error, _} = Err ->
+            Err;
         #topic_permission{permission = P} ->
             PermRegexp = case element(permission_index(Permission), P) of
                              %% <<"^$">> breaks Emacs' erlang mode

Source: RabbitMQ commit 94f1d33a

The patch adds an explicit {error, _} clause so the backend surfaces the failure instead of defaulting to allow. The companion change updates the type spec of get_topic_permissions/3 to include {error, term()}, forcing callers to reason about the error branch.

Detection Methods for CVE-2026-57217

Indicators of Compromise

RabbitMQ server logs containing Khepri query errors or timeouts (khepri, ra_leader, or {error, timeout} entries) coincident with successful basic.publish or queue.bind operations on restricted topics.
Audit trails showing low-privilege users successfully binding queues to protected routing keys on topic exchanges.
Correlated cluster events such as node join/leave, network partitions, or leader elections occurring alongside privileged topic operations.

Detection Strategies

Enable rabbitmq_auth_backend_internal debug logging and alert on topic operations that succeed while the metadata store reports non-ok responses.
Deploy the RabbitMQ Prometheus exporter and alert on spikes in rabbitmq_raft_log_commit_latency or Khepri error counters correlated with authorization-relevant AMQP methods.
Establish a baseline of which users publish to or bind against each topic exchange, then flag deviations, particularly during cluster instability windows.

Monitoring Recommendations

Forward broker logs and AMQP audit events to a centralized SIEM or data lake for cross-correlation of authorization outcomes and Khepri health.
Monitor cluster health signals (leader changes, partitions, disk alarms) and treat concurrent topic-permission activity as elevated risk.
Track version inventory of RabbitMQ nodes to confirm all brokers run patched releases across production and disaster-recovery sites.

How to Mitigate CVE-2026-57217

Immediate Actions Required

Upgrade RabbitMQ to 3.13.15, 4.0.21, 4.1.11, or 4.2.6 on every node in the cluster following the rolling upgrade procedure.
Audit topic permissions in all virtual hosts and revoke any bindings created by low-privilege users during recent Khepri instability.
Rotate credentials for accounts that exhibited anomalous topic activity while unpatched.

Patch Information

Fixes are delivered through commits 94f1d33a and ce1f682a, merged via pull requests #15941 and #15943. Full details are in the GHSA-gpvw-75h5-3wvx advisory and the v4.2.6 release notes.

Workarounds

Where immediate upgrade is not feasible, keep the metadata store on the Mnesia backend until patched Khepri-enabled versions are deployed.
Restrict AMQP and management network access to trusted clients using firewall rules or a service mesh, reducing the population of authenticated users that could probe the flaw.
Stabilize the Khepri cluster by ensuring odd node counts, healthy quorum, and stable networking to minimize the error window that triggers the fail-open path.

bash

# Verify RabbitMQ version on each node after upgrade
rabbitmqctl version

# List topic permissions and validate against expected policy
rabbitmqctl list_topic_permissions --vhost /

# Enable Khepri health checks in cluster monitoring
rabbitmq-diagnostics check_running
rabbitmq-diagnostics cluster_status