CVE-2026-67420: 
RabbitMQ vulnerability analysis and mitigation

CVE-2026-67420 is an authorization bypass vulnerability in RabbitMQ where OAuth credential refresh retains revoked runtime tags, enabling unauthorized user impersonation via stale session state. When an existing AMQP connection refreshes from an OAuth token that grants the impersonator tag to a downgraded token that no longer grants it, RabbitMQ updates the backend token state but leaves the connection's runtime #user.tags unchanged, allowing continued publishing with a foreign AMQP user_id. Affected versions span RabbitMQ 3.13.0–3.13.18, 4.0.0–4.0.23, 4.1.0–4.1.14, 4.2.0–4.2.9, and 4.3.0–4.3.4. The vulnerability was published on August 18, 2026, and carries a CVSS v3.1 base score of 3.1 (Low) and a CVSS v4.0 base score of 2.3 (Low) (GitHub Advisory, Red Hat).

The root cause is a logic flaw (CWE-862: Missing Authorization; CWE-266: Incorrect Privilege Assignment) in rabbit_access_control:update_state/2 (deps/rabbit/src/rabbit_access_control.erl, lines 414–436). When processing a credential refresh, the function pattern-matches only the impl field from the OAuth backend's returned #auth_user{} record, discarding the refreshed tags field — meaning the connection's #user{} record retains its original tag set. The check_user_id0/2 function subsequently reads the stale #user.tags and finds the impersonator tag still present, authorizing foreign user_id publishes. The defect is limited to deployments using rabbit_auth_backend_oauth2 (or an equivalent refresh-capable backend) where a connection previously held the impersonator tag and successfully calls connection.update_secret with a downgraded token before the original credential expires (GitHub Advisory, Fix Commit).

Successful exploitation allows an authenticated attacker to publish AMQP messages attributed to a foreign user_id (e.g., impersonating another user) after the impersonator privilege has been revoked via token downgrade. The impact is limited to integrity — specifically, message attribution and user-id isolation guarantees are violated — with no direct confidentiality or availability impact. The vulnerability does not grant administrator privileges, expand queue/exchange ACLs, or enable creation of new identities, and it only persists until the affected connection is closed or re-authenticated (GitHub Advisory, Red Hat Bugzilla).

A proof-of-concept reproduction sequence is publicly documented in the GitHub Security Advisory, providing a detailed 7-step walkthrough that an attacker can follow on a real RabbitMQ deployment (GitHub Advisory). There is no evidence of in-the-wild exploitation at this time, and no threat actor attribution has been reported. The EPSS score is approximately 0.0024 (low probability of exploitation), and the vulnerability is not listed in the CISA KEV catalog. Exploitation is not automatable and requires an authenticated attacker with a pre-existing AMQP connection holding the impersonator tag and access to a downgraded token for the same username.

1. Enable OAuth2 backend: Confirm the target RabbitMQ instance has auth_backends = [rabbit_auth_backend_oauth2] configured for AMQP connections.
2. Obtain a privileged token (Token A): Acquire a valid OAuth token for user alice that grants both rabbitmq.tag:impersonator and vhost/write scope from the OAuth provider.
3. Establish an AMQP connection with Token A: Connect to RabbitMQ over AMQP 0-9-1 (or AMQP 1.0) using Token A. The connection's #user.tags is populated with [impersonator].
4. Publish with a foreign user_id: On the established connection, publish an AMQP message with user_id = bob (a different user). The check_user_id0/2 function finds the impersonator tag and returns ok, so the publish succeeds.
5. Obtain a downgraded token (Token B): Acquire or arrange issuance of Token B for the same mapped username (alice) with write/vhost scope but without the impersonator tag.
6. Refresh credentials via connection.update_secret: Call the AMQP 0-9-1 connection.update_secret method (or AMQP 1.0 credential-update path) with Token B on the existing connection. RabbitMQ responds with update_secret_ok but only updates the backend impl field, leaving #user.tags stale with [impersonator].
7. Continue publishing with foreign user_id: On the same channel or a newly opened channel on the same connection, publish again with user_id = bob. The stale impersonator tag still authorizes the publish — demonstrating the privilege was not revoked on the session.
8. Verify the defect: Open a fresh AMQP connection using Token B alone and attempt the same foreign user_id publish — it is correctly refused, confirming the issue is stale session state (GitHub Advisory).

• Logs: RabbitMQ connection logs showing connection.update_secret calls followed by continued publish operations with a user_id field differing from the authenticated username on the same connection; look for update_secret_ok acknowledgments in AMQP trace logs paired with subsequent foreign user_id publishes.
• Network: AMQP traffic (default port 5672 or 5671 for TLS) where a single long-lived connection issues a credential refresh frame (connection.update_secret) and then publishes messages with a user_id header that does not match the connection's authenticated username.
• Behavioral: A connection that previously published with a foreign user_id (indicating impersonator tag was active) continues to do so after a credential refresh event, while a new connection from the same user is refused the same operation — indicating stale session state rather than legitimate privilege.

Upgrade RabbitMQ to one of the patched versions: 3.13.19, 4.0.24, 4.1.15, 4.2.10, or 4.3.5, which fix the issue by rebuilding #user.tags from refreshed backend responses in rabbit_access_control:update_state/2 (Fix Commit, RabbitMQ 4.3.5 Release). As a temporary workaround, force affected users to close and re-establish AMQP connections after any OAuth token revocation or privilege downgrade, rather than relying on connection.update_secret refresh on existing connections. Additionally, consider disabling the impersonator tag functionality in OAuth token scopes if it is not actively required by your deployment (GitHub Advisory, Red Hat Bugzilla).

The vulnerability was reported by researcher kjsxz and the advisory was published by RabbitMQ maintainer michaelklishin on August 18, 2026 (GitHub Advisory). Red Hat tracked the issue as low severity in their Bugzilla system and assigned it to their Product Security team (Red Hat Bugzilla). No significant broader media coverage or notable social media commentary has been identified beyond standard CVE aggregator publications.