RabbitMQ Server CVE-2026-57218

Three concurrent conditions must be met: (1) RabbitMQ Server must be configured to use OAuth 2.0 token-based authentication for AMQP 0-9-1; (2) an attacker or legitimate user must have an active consumer registered on a channel before token expiry or scope reduction occurs; and (3) the OAuth token must subsequently expire or an explicit connection.update_secret call reducing scopes must be issued while that consumer connection remains open. The CVSS 4.0 AT:P metric confirms a specific attack precondition is required. Deployments using only username/password static credentials are not affected. Deployments using AMQP 1.0, MQTT, or STOMP are not affected by this specific flaw. The vulnerability cannot be triggered without prior authentication (PR:L) and cannot be exploited against connections that are closed and re-established after the scope change.

The CVSS 4.0 score of 4.9 with vector AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:N/SC:H/SI:N/SA:N captures an important nuance: while network-accessible and low-complexity at the transport level, exploitation requires an attack precondition (AT:P) - specifically, OAuth token expiry or an administrator-triggered scope reduction must occur while the consumer connection is live. The vulnerable-system impact is none (VC/VI/VA:N) because the flaw does not compromise the broker itself; instead, the subsequent-system confidentiality impact is high (SC:H) because messages from queues the user should no longer access continue flowing to that consumer. No CISA KEV listing and no public POC exist, significantly reducing near-term exploit pressure. The practical risk is highest in regulated, multi-tenant, or zero-trust environments where OAuth token revocation is used as a real-time access control enforcement mechanism. Deployments using static credentials or non-OAuth authentication are entirely unaffected - this is not a universal RabbitMQ risk.

An authenticated low-privileged user establishes an AMQP 0-9-1 connection using a valid OAuth token with read access to a sensitive queue and registers a consumer. An administrator subsequently reduces the token's OAuth scopes via connection.update_secret - or the token expires - to revoke queue access, but the broker does not cancel or recheck the existing consumer, which continues silently draining messages from the queue beyond the intended authorization window. No public POC exists at time of analysis.