CVE-2026-67420: RabbitMQ OAuth credential refresh retains revoked runtime tags
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 3.13.19 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.0.24 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.1.15 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.2.10 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.3.5
Event History
Frequently Asked Questions
Which deployments are affected?
The issue is limited to deployments using rabbit_auth_backend_oauth2, or an equivalent refresh-capable backend that returns tags. It affects an existing AMQP connection that previously received the impersonator tag and then refreshes to a valid token for the same username that no longer includes that tag.
What can an attacker do with the stale privilege?
The affected connection can continue publishing messages with a foreign AMQP userid because access control still honors the stale impersonator runtime tag. This also applies to channels opened after the token refresh on that same connection.
What is a practical workaround if the broker cannot be patched immediately?
Terminate and require clients to establish fresh AMQP connections after removing the impersonator privilege. A fresh connection using the downgraded token correctly refuses the foreign-userid publish attempt.
How can administrators distinguish affected stale sessions from current token permissions?
Test the downgraded token on a newly established connection. If the fresh connection refuses a foreign AMQP userid publish but an older connection that refreshed from a previously privileged token still permits it, the older connection has retained stale runtime tags.
Which releases contain the fix?
The issue is fixed in RabbitMQ 3.13.19, 4.0.24, 4.1.15, 4.2.10, and 4.3.5.