CVE-2026-66077 in RabbitMQ
Summary
by MITRE • 09/24/2026
RabbitMQ is a messaging and streaming broker. Prior to versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6, The management UI uses EJS 1.0 in which <%= ... %> does NOT HTML-escape. connection.ejs:135 renders <%= connection.ssl_details.peer_cert_subject %> (and peer_cert_issuer) directly into the page. The same pattern appears in streamConnection.ejs:102,106,110. The values come from rabbit_ssl:peer_cert_subject/1 which formats the DN as a string without HTML escaping. The verifier corrected the original researcher's claim: this is reachable only when the listener is configured with verify_peer (so the certificate must be signed by a CA in the broker's trust store, not arbitrary self-signed); however, in deployments using mTLS for client authentication, any user who can request a certificate from the organisational CA controls the Subject CN. An attacker who can obtain a TLS client certificate signed by a CA the broker trusts (with verify_peer enabled) can embed JavaScript in the certificate's Subject DN. When any administrator views that connection in the management UI, the script executes in the admin's browser session, allowing full account takeover (create users, export definitions, etc.). The management UI's CSP includes 'unsafe-inline', so inline script execution is not blocked. Preconditions include TLS listener configured with ssl_options.verify = verify_peer Attacker can obtain a CA-signed client certificate with attacker-chosen Subject (e.g. self-service corporate PKI, or rabbitmq_trust_store plugin in use) Administrator views the connection detail page. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/24/2026
RabbitMQ serves as a critical messaging and streaming broker for enterprise infrastructure, facilitating communication between distributed systems through robust message queuing protocols. The management UI provides administrators with essential visibility into system operations, including connection details and SSL/TLS configurations. However, prior to versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6, a significant security flaw existed within the rendering logic of this interface. The management UI utilizes EJS version 1.0 for template processing, which includes an unescaped interpolation syntax denoted by <%= ... %>. This specific construct renders data directly into HTML without applying any form of encoding or escaping, creating a direct pathway for Cross-Site Scripting vulnerabilities when user-controlled input is processed through these templates.
The technical flaw manifests specifically in files such as connection.ejs and streamConnection.ejs, where variables like peer_cert_subject and peer_cert_issuer are rendered directly into the page structure using the unescaped syntax. These values originate from the rabbit_ssl:peer_cert_subject/1 function, which formats the Distinguished Name of an SSL certificate as a plain string without performing HTML escaping. Consequently, if an attacker can control the content of these fields, they can inject arbitrary JavaScript code that will be executed by any administrator viewing the affected connection details in their web browser. This represents a classic Stored Cross-Site Scripting vulnerability where malicious payloads are persisted within system data structures and triggered upon legitimate user interaction with the management interface.
The operational impact of this vulnerability is severe due to the high privilege level associated with RabbitMQ administrators. An attacker who successfully exploits this flaw can execute scripts in the context of an admin's browser session, effectively bypassing same-origin policies and gaining full control over the administrative account. This allows for comprehensive account takeover capabilities, including the creation of new users with elevated privileges, modification of system configurations, and exportation of sensitive definitions that could compromise the entire messaging infrastructure. The severity is further amplified by the Content Security Policy configuration in the management UI, which includes 'unsafe-inline', thereby permitting inline script execution and negating a common browser-based mitigation strategy against XSS attacks.
Access to this vulnerability requires specific preconditions related to TLS listener configurations. The flaw is only reachable when the RabbitMQ listener is configured with verify_peer enabled, meaning clients must present certificates signed by a Certificate Authority trusted by the broker's trust store. While arbitrary self-signed certificates cannot be used for exploitation, deployments utilizing mutual TLS authentication or organizational PKI systems are at risk. In such environments, any user who can request a certificate from the internal CA controls the Subject Common Name field of that certificate. By embedding JavaScript payloads within the Subject DN during certificate issuance requests, an attacker can weaponize this feature against administrators viewing connection details.
This vulnerability maps to CWE-79, which covers Improper Neutralization of Input During Web Page Generation commonly known as Cross-site Scripting. From a tactical perspective, it aligns with MITRE ATT&CK techniques related to Client-side Injection and Account Manipulation, specifically T1059.007 for JavaScript execution within browser contexts and T1098.004 for SSH Key Authentication or similar credential manipulation via account takeover. The exploitation chain relies on the attacker obtaining a CA-signed certificate with malicious content in the Subject field, followed by an administrator viewing the corresponding connection details to trigger script execution.
Mitigation strategies primarily involve upgrading RabbitMQ to patched versions 3.13.15, 4.0.20, 4.1.11, or 4.2.6, which address the underlying rendering issue in the management UI templates. For organizations unable to immediately upgrade, implementing strict input validation on certificate Subject fields within internal PKI systems can prevent malicious payloads from being issued. Additionally, reviewing and tightening Content Security Policy headers to remove 'unsafe-inline' directives would significantly reduce the impact of such injection attempts by blocking unauthorized script execution in administrative browsers. Regular auditing of TLS configurations and monitoring for unusual connection patterns involving certificates with anomalous Subject fields are also recommended defensive measures.