RabbitMQ CVE-2026-66077

Exploitation requires the broker's TLS listener to be configured with ssl_options.verify = verify_peer (mutual TLS client-certificate authentication) - this is NOT the default, which is the primary limiting factor. The attacker must be able to obtain a client certificate signed by a CA in the broker's trust store while controlling the certificate's Subject DN (CN); realistic paths are a self-service corporate/organisational PKI or an environment using the rabbitmq_trust_store plugin. A self-signed or untrusted certificate does NOT work. Finally, an administrator must view the malicious connection's detail page in the management UI (UI:A). The management UI CSP includes 'unsafe-inline', so it does NOT block the injected inline script - removing what would otherwise be a mitigation.

This is a genuine but conditionally-gated stored XSS (CWE-79), not a high-CVSS-but-low-risk artifact. The vendor CVSS 4.0 vector (7.3, AV:N/AC:L/AT:P/PR:L/UI:A/VC:H/VI:H/VA:L) shows network reach but embeds two important brakes: AT:P (attack requirements - the verify_peer mTLS precondition) and UI:A (an administrator must actively view the connection page). No EPSS score, no CISA KEV entry, and no public exploit code are present in the input, so exploitation is best characterized as no public exploit identified at time of analysis. The impact ceiling is high (full admin account takeover of the RabbitMQ management UI: create users, export definitions), which justifies the VC:H/VI:H. However realistic priority is moderate rather than urgent because exploitation depends on a specific deployment mode (verify_peer client-cert authentication) AND the attacker's ability to obtain a CA-signed certificate with an attacker-chosen Subject DN AND administrator interaction. Note a nuance the verifier corrected: the original researcher's implied 'any self-signed cert' claim is wrong - the cert must chain to a CA in the broker's trust store, which narrows the attack to environments with self-service corporate PKI or the rabbitmq_trust_store plugin. The CSP containing 'unsafe-inline' is an aggravating factor that removes a mitigation that would otherwise have blocked inline script.

In a RabbitMQ deployment using mTLS (ssl_options.verify = verify_peer) with a self-service corporate PKI, an attacker requests a legitimate client certificate whose Subject CN contains a JavaScript payload (e.g. an <img onerror> or <script> string). The attacker connects to the broker with that certificate; when an administrator later opens that connection's detail page in the management UI, connection.ejs renders the unescaped Subject DN and the script executes in the admin's authenticated session, enabling full account takeover. No public exploit code is identified in the provided data, though the code path (connection.ejs:135, streamConnection.ejs:102/106/110) is precisely documented in the advisory.