RabbitMQ EUVD-2026-85656

Exploitation requires a non-default configuration: for Web-STOMP, use_http_auth=true, or for either Web-MQTT or Web-STOMP, ssl_cert_login=true, so that the browser automatically presents the victim's TLS client certificate on the WebSocket upgrade. The victim must have a valid client certificate (or HTTP-auth session) and must be socially engineered into loading attacker-controlled JavaScript in their browser (UI:P). The vulnerability does not exist under the default in-band CONNECT credential configuration, where credentials are supplied in the protocol payload rather than by the browser, so default deployments are not affected. The Web-MQTT and/or Web-STOMP plugins must be enabled and network-reachable from the victim's browser.

This is a Cross-Site WebSocket Hijacking (CWE-1385, missing Origin validation) flaw in RabbitMQ's Web-MQTT and Web-STOMP WebSocket handlers. The vendor CVSS 4.0 score of 5.3 (MEDIUM) is driven entirely by subsequent-system impact (SC:H/SI:H) with no direct vulnerable-system impact (VC:N/VI:N/VA:N), which correctly reflects that the attacker gains nothing against the broker process itself but instead hijacks the victim's authenticated messaging session. The vector's AV:N/PR:N/UI:P/AT:P combination is the key signal: exploitation is network-reachable and needs no attacker credentials, but requires victim interaction (UI:P - the victim must load attacker JavaScript in a browser) AND a specific attack requirement (AT:P) that maps directly to the non-default configuration precondition. No EPSS score, no CISA KEV listing, and no public POC are present in the supplied data, so this is 'no public exploit identified at time of analysis' - real-world exploitation is theoretical and further gated by the requirement that ssl_cert_login=true (both plugins) or use_http_auth=true (Web-STOMP) be explicitly enabled. The vendor is explicit that the issue is HARMLESS under the default in-band CONNECT credential configuration, which sharply narrows the exposed population. Net: a genuine but conditional session-hijack risk, not a mass-exploitable priority; the moderate score is appropriate and the practical risk is lower still because it depends on a non-default browser-based certificate/HTTP-auth deployment plus a socially-engineered victim.

An organization runs RabbitMQ with the Web-MQTT or Web-STOMP plugin configured with ssl_cert_login=true (or use_http_auth=true for Web-STOMP), so browsers automatically present the victim's client certificate on WebSocket upgrade. An attacker lures a victim who has such a certificate to a malicious web page; the page's JavaScript opens a cross-origin WebSocket to the broker, which does not validate the Origin header, and the browser silently attaches the victim's certificate, authenticating the attacker's script as the victim. No public exploit code is identified in the supplied data.