This vulnerability causes a stored cross‑site scripting flaw in RabbitMQ’s management UI when TLS client certificates are used with verify_peer enabled. The UI renders the certificate’s subject DN without escaping, allowing a maliciously crafted JavaScript payload to be embedded. When an administrator opens the connection detail page, the script runs inside the admin’s browser context, enabling full control over broker accounts and configurations. The weakness is a classic reflected input flaw where untrusted data is displayed without proper filtering. The impact is the compromise of confidentiality, integrity, and availability of the broker, as an attacker can create or delete users, modify routing, and dump sensitive data.

RabbitMQ server versions earlier than 3.13.15, 4.0.20, 4.1.11, and 4.2.6 are affected. The issue arises when a TLS listener is configured with ssl_options.verify = verify_peer and the broker’s trust store accepts the attacker’s certificate. Any deployment using mTLS for client authentication and exposing the management UI is at risk. The vulnerability is limited to the UI layer and requires an administrator to view the connection details; however, an attacker who controls the subject DN can generate a payload that will execute in the admin’s browser.

The CVSS base score of 7.3 indicates a high severity. EPSS score is not available, but the vulnerability is not listed in the CISA KEV catalog. The likely attack requires the attacker to obtain a valid TLS client certificate signed by a CA that the broker trusts, which is feasible on enterprises with internal PKI or when misconfigured trust stores are present. Once the certificate is in place, any administrative interaction with the UI leads to script execution, providing local privilege escalation to administrative level within the broker. Given the high impact and realistic exploitation path, the risk is significant when the described conditions exist.