CVE-2026-67421: RabbitMQ: Stored HTML Injection in RabbitMQ Management OAuth Error Handling
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 Management rendered an AMQP authorization-error reason containing an attacker-controlled queue name as HTML when the OAuth management UI was enabled. Exploitation requires an attacker with queue configure permission, a management administrator who can see but cannot read that queue, and the administrator clicking Get Message(s). A queue name containing a base element can then retarget the automatic relative refresh because the Content Security Policy omits base-uri and connect-src, and an attacker endpoint that permits the management origin through CORS can receive the victim's Authorization header. 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
RabbitMQ Managementto a version that resolves this vulnerability.Fixed in 3.13.19 - Upgrade
Upgrade
RabbitMQ Managementto a version that resolves this vulnerability.Fixed in 4.0.24 - Upgrade
Upgrade
RabbitMQ Managementto a version that resolves this vulnerability.Fixed in 4.1.15 - Upgrade
Upgrade
RabbitMQ Managementto a version that resolves this vulnerability.Fixed in 4.2.10 - Upgrade
Upgrade
RabbitMQ Managementto a version that resolves this vulnerability.Fixed in 4.3.5
Event History
Frequently Asked Questions
Which deployments are exposed?
Deployments are exposed when the RabbitMQ Management OAuth UI is enabled and run a version before the listed fixed release for its branch: 3.13.19, 4.0.24, 4.1.15, 4.2.10, or 4.3.5.
What access and user interaction are required to exploit this issue?
An attacker needs permission to configure queues and must create or control a queue whose name carries the injected content. A management administrator who can see that queue but cannot read it must then click Get Message(s).
What is the impact of a successful exploit?
The injected queue name can alter the management UI's relative refresh target. If the attacker endpoint allows the management origin through CORS, it can receive the administrator's Authorization header.
What should be prioritized if an immediate upgrade is not possible?
Limit queue configure permission to trusted users and avoid having management administrators click Get Message(s) for queues they can see but cannot read. The issue depends on the OAuth management UI being enabled and on that administrator action.
How can teams identify potentially affected activity?
Review queues configurable by less-trusted users, particularly queues with names containing HTML-like content such as a base element. Also identify management administrators who have visibility into those queues without read permission and use Get Message(s).