CVE-2026-67405 in RabbitMQinfo

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, 4.2.6, and 4.3.0, Neither the Web-MQTT handler (deps/rabbitmq_web_mqtt/src/rabbit_web_mqtt_handler.erl:104) nor the Web-STOMP handler (deps/rabbitmq_web_stomp/src/rabbit_web_stomp_handler.erl:102) validates the Origin header on the WebSocket upgrade. Under ssl_cert_login=true, the browser presents the client certificate automatically, so an attacker's JavaScript running in the victim's browser can authenticate as the victim. Preconditions include The non-default configuration use_http_auth=true (Web-STOMP) or ssl_cert_login=true (both plugins) must be enabled. The issue is harmless under the default in-band CONNECT credential configuration.. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0.

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Analysis

by VulDB Data Team • 09/24/2026

RabbitMQ serves as a widely adopted messaging broker that facilitates asynchronous communication between distributed systems through protocols such as AMQP, MQTT, and STOMP. A critical security flaw was identified in the WebSocket handlers for both Web-MQTT and Web-STOMP components prior to specific patch versions including 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0. The vulnerability stems from a failure in the Origin header validation logic within these handlers. Specifically, the code at rabbit_web_mqtt_handler.erl line 104 and rabbit_web_stomp_handler.erl line 102 did not enforce strict checks on the HTTP Origin header during WebSocket upgrade requests. This oversight allows for Cross-Site Request Forgery attacks where malicious scripts executed in a victim's browser can initiate connections to the RabbitMQ broker without proper authorization boundaries being respected by the server side.

The operational impact of this vulnerability is severe when specific authentication configurations are enabled. In environments where ssl_cert_login is set to true, browsers automatically present client certificates during TLS handshakes for requests originating from trusted domains or contexts. An attacker can craft a malicious webpage that triggers JavaScript code to establish a WebSocket connection to the RabbitMQ instance. Because the server fails to validate whether this request originated from an authorized origin, it accepts the browser's automatic certificate presentation as valid authentication credentials. Consequently, the attacker gains unauthorized access to the victim’s RabbitMQ account, effectively impersonating them within the messaging infrastructure. This breach compromises confidentiality and integrity of messages routed through that user context.

It is crucial to note that this vulnerability does not affect all configurations equally. The issue remains harmless under default settings where in-band CONNECT credentials are used for authentication rather than SSL client certificates or HTTP basic auth combined with origin checks. For Web-STOMP, the non-default configuration use_http_auth=true must be enabled alongside ssl_cert_login=true for both plugins to expose this specific attack vector. Therefore, organizations relying on standard username and password authentication via the CONNECT frame are not susceptible to this particular cross-site scripting exploitation path involving certificate-based identity theft.

From a classification perspective, this vulnerability aligns with CWE-346 which describes an Origin Validation Error in Cross-Site Request Forgery scenarios. It also maps to MITRE ATT&CK technique T1508 regarding Exploitation of Client Side Code Injection and potentially T1078 for Valid Accounts if the attacker leverages stolen session context or credentials derived from the compromised broker connection. The lack of proper origin validation represents a fundamental breach in web security principles designed to prevent unauthorized actions on behalf of authenticated users via malicious third-party sites.

To mitigate this risk, administrators must upgrade RabbitMQ to version 3.13.15 or later for the 3.13.x series, or equivalent newer versions such as 4.0.20, 4.1.11, 4.2.6, and 4.3.0 where these handlers have been patched to strictly validate Origin headers during WebSocket upgrades. Additionally, security best practices dictate that ssl_cert_login should be used with caution in web-facing contexts unless absolutely necessary due to the automatic nature of browser certificate handling which can be exploited by malicious scripts. Implementing strict Content Security Policy directives and ensuring that only trusted origins are permitted to connect via Web-MQTT or Web-STOMP interfaces further reduces the attack surface. Regular auditing of authentication configurations ensures that non-default settings do not inadvertently expose internal messaging infrastructure to external web-based threats.

Responsible

GitHub M

Reservation

07/29/2026

Disclosure

09/24/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

very low

Sources

Do you want to use VulDB in your project?

Use the official API to access entries easily!