CVE-2026-67420 in RabbitMQ
Summary
by MITRE • 09/25/2026
RabbitMQ is a messaging and streaming broker. From 3.13.0 until 3.13.19, 4.0.24, 4.1.15, 4.2.10, and 4.3.5, RabbitMQ OAuth credential refresh retains revoked runtime tags. when an existing AMQP connection refreshes from an OAuth token that grants the impersonator tag to a valid same-username token that no longer grants that tag, RabbitMQ updates the OAuth backend implementation (token/scopes/expiry) but leaves the connection's runtime #user.tags unchanged. rabbitaccesscontrol:checkuserid/2 then still honors the stale impersonator tag, so the connection (including newly opened channels) can continue publishing messages with a foreign AMQP userid after that privilege should have been revoked. A fresh connection using the downgraded token correctly refuses the same publish, proving the defect is stale session state rather than the token Limited to connections that once held impersonator and successfully refresh to a downgraded same-username rabbitauthbackendoauth2 (or an equivalent refresh-capable backend that returns tags) is enabled for This issue is fixed in versions 3.13.19, 4.0.24, 4.1.15, 4.2.10, and 4.3.5.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/25/2026
RabbitMQ serves as a robust messaging and streaming broker widely deployed in enterprise environments to facilitate asynchronous communication between distributed systems. A critical security vulnerability has been identified within the OAuth authentication backend implementation affecting specific versions of RabbitMQ, including releases from the 3.13.x series up to 3.13.19, as well as versions 4.0.24, 4.1.15, 4.2.10, and 4.3.5. This flaw pertains specifically to the mechanism by which RabbitMQ handles credential refreshes for connections authenticated via OAuth tokens that grant impersonator tags. The vulnerability arises when an existing AMQP connection attempts to renew its authentication credentials using a new OAuth token from the same username identity but with reduced privileges, specifically one that no longer includes the impersonator tag.
The technical root cause of this issue lies in how RabbitMQ updates session state during the credential refresh process. When the broker receives a refreshed token that downgrades the user's permissions by removing the impersonator capability, it correctly updates the OAuth backend implementation details such as the token data, scopes, and expiration time. However, it fails to synchronize these changes with the connection's runtime metadata, specifically leaving the #user.tags attribute unchanged in memory. Consequently, the internal access control logic, which relies on rabbitaccesscontrol:checkuserid/2, continues to evaluate the stale impersonator tag present in the session state rather than reflecting the actual permissions granted by the new token. This discrepancy creates a window where the connection retains elevated privileges that should have been revoked upon refresh.
The operational impact of this vulnerability is significant for environments relying on RabbitMQ's impersonation features for multi-tenant architectures or service-to-service communication with delegated authority. An attacker who controls an account subject to OAuth credential rotation could exploit this state inconsistency by triggering a token refresh while holding valid credentials that previously included the impersonator tag but now do not. By doing so, the connection remains authenticated as if it still possesses the ability to publish messages on behalf of other users or virtual hosts. This allows for unauthorized message publishing under foreign AMQP user identities, potentially leading to data leakage, injection of malicious payloads into downstream systems, or disruption of service integrity by spoofing source identities in audit logs and monitoring tools.
This vulnerability is classified as CWE-613, Insufficient Session Expiration, because the session state fails to properly reflect changes in authentication credentials that reduce privileges. It also aligns with ATT&CK technique T1078, Valid Accounts, specifically within the context of persistence or privilege escalation through stale session states where revoked permissions are not enforced. The defect is isolated to connections that previously held impersonator rights and successfully refresh their tokens under a same-username scenario using rabbitauthbackendoauth2 or equivalent backends capable of returning tags during renewal processes. It does not affect fresh connections, as new sessions correctly evaluate the current token's scope and refuse publishing if the impersonator tag is absent, highlighting that the issue is strictly one of stale session state management rather than a fundamental flaw in token validation logic.
Mitigation strategies primarily involve upgrading to patched versions where this synchronization error has been resolved. Administrators should ensure their RabbitMQ instances are updated to version 3.13.19 or later for the 3.13 branch, or version 4.0.24, 4.1.15, 4.2.10, and 4.3.5 for subsequent branches. In environments where immediate patching is not feasible, operators should consider implementing shorter token expiration intervals to limit the window of opportunity for exploitation through credential refresh cycles. Additionally, monitoring tools can be configured to detect anomalies in message publishing patterns originating from connections that have recently undergone authentication updates but continue to exhibit elevated privilege behaviors. Regular audits of OAuth integration configurations and strict enforcement of least-privilege principles during service account provisioning further reduce the risk surface associated with this class of state management vulnerabilities.