RabbitMQ CVE-2026-67420

Exploitation requires that RabbitMQ be configured with the rabbit_auth_backend_oauth2 backend (or an equivalent refresh-capable backend that returns tags), version 3.13.0 through the fixed releases; the attacker must control an authenticated client that has ALREADY been granted the privileged impersonator runtime tag on a live AMQP connection, and that connection must then perform an in-place credential refresh to a same-username OAuth token that no longer grants impersonator. The limiting factors are significant: static/password backends and non-refresh-capable setups are unaffected, a freshly established connection with the downgraded token correctly refuses the privileged publish, and the actor must already have held the elevated impersonator privilege - so this is a privilege-revocation gap for an existing privileged session rather than a path for an ordinary user to gain new powers.

This is a genuine but narrow authorization defect, and every available signal points to LOW real-world priority despite it being a real logic bug. The provided CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:L/VA:N, base 2.3) already reflects low impact: the PR:L confirms an authenticated actor is required, AT:P (attack requirements present) captures the specific precondition chain, and VC:L/VI:L/VA:N/SC:N/SI:N confine impact to a low-severity confidentiality/integrity effect with no availability impact and no downstream-system scope change. No EPSS score is provided, the CVE is NOT in CISA KEV, and no public exploit code is referenced - so there is no public exploit identified at time of analysis. Note the CVSS 4.0 AC:L, but the exploitation genuinely depends on a multi-step precondition (a connection that ALREADY held the privileged impersonator tag then successfully refreshes to a downgraded same-username token) - this is closer to AC:H in practical terms, which I reflect in my independent 3.1 assessment. The vendor advisory (GHSA-86fm-44m9-rqjx), the fix commit (5de287d2), and the confirming regression test (update_state_rebuilds_tags) all corroborate the root cause precisely, so the technical facts are high-confidence; the low residual risk is driven by the strict preconditions, not by data gaps. Bottom line: a correctly low-scored, defense-in-depth privilege-revocation bug - patch during normal maintenance, not an emergency.

An operator using RabbitMQ's OAuth2 backend grants a client the privileged impersonator tag (which permits publishing messages under a foreign AMQP userid). The client's OAuth token is later re-issued/downgraded to a same-username token WITHOUT the impersonator scope, but the client keeps its existing AMQP connection open and lets it refresh in place; the connection (and any newly opened channels on it) continues to publish spoofed-userid messages because the stale runtime tag survives the refresh. No public proof-of-concept is referenced, though the vendor's committed regression test demonstrates the exact stale-tag behavior.