RabbitMQ CVE-2026-67421

Requires the OAuth management UI to be enabled (non-default plugin/auth configuration) on RabbitMQ Management between 3.13.0 and the fixed releases. The attacker must be an authenticated user holding 'configure' permission to create a queue with a crafted name containing an HTML <base> element. Exploitation further depends on a management administrator who can see but not read that queue actively clicking 'Get Message(s)' (UI:A/UI:R). The token exfiltration only succeeds because the deployed Content Security Policy omits the base-uri and connect-src directives, and because the attacker operates an endpoint whose CORS policy permits the management origin. These stacked preconditions - non-default OAuth UI, attacker permissions, victim interaction, CSP gap, and attacker CORS endpoint - substantially limit realistic exploitation.

The provided CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:A/VC:L/VI:L/VA:N/SC:H/SI:L/SA:N, base 4.5, MEDIUM) is internally consistent with the description: network-reachable but requiring an attack precondition (AT:P), a low-privileged authenticated attacker (PR:L), and active victim interaction (UI:A). The SC:H (subsequent-system confidentiality High) correctly captures the real payload - theft of the administrator's OAuth Authorization header, which is far more damaging than the modest vulnerable-system impacts. However, exploitation is heavily gated: it needs (1) the OAuth management UI enabled, (2) an attacker holding queue 'configure' permission, (3) a management administrator who can see but not read the crafted queue, (4) that admin clicking 'Get Message(s)', and (5) an attacker-controlled endpoint whose CORS policy admits the management origin. This multi-actor, multi-condition chain makes mass or automated exploitation impractical. No EPSS score, no CISA KEV listing, and no public exploit are present in the input, so this is no public exploit identified at time of analysis. Net: a real but low-to-medium priority issue - a plausible targeted attack against multi-tenant RabbitMQ clusters using OAuth, not a widespread emergency. Note the CWE (CWE-862 Missing Authorization) and the 'Authentication Bypass' tag both understate the actual mechanism, which is HTML injection / stored-XSS-style token exfiltration via a CSP gap (missing base-uri and connect-src directives).

In a multi-tenant RabbitMQ cluster with the OAuth management UI enabled, a low-privileged tenant creates a queue whose name embeds an HTML <base> element. When an administrator who can see but not read that queue clicks 'Get Message(s)', the unescaped queue name renders as HTML in an AMQP authorization-error reason, injecting the base tag; because the Content Security Policy omits base-uri and connect-src, the page's automatic relative refresh is retargeted to an attacker endpoint that admits the management origin via CORS, leaking the administrator's OAuth Authorization header. No public exploit is identified at time of analysis.