CVE-2026-67405: RabbitMQ: CSWSH on Web-STOMP / Web-MQTT (no Origin validation)
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/rabbitmqwebmqtt/src/rabbitwebmqtthandler.erl:104) nor the Web-STOMP handler (deps/rabbitmqwebstomp/src/rabbitwebstomphandler.erl:102) validates the Origin header on the WebSocket upgrade. Under sslcertlogin=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 usehttpauth=true (Web-STOMP) or sslcertlogin=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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 3.13.15 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.0.20 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.1.11 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.2.6 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.3.0
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Only RabbitMQ deployments using the Web-STOMP or Web-MQTT WebSocket plugins with non-default HTTP authentication or client-certificate login settings are exposed. Web-STOMP is affected when use_http_auth=true is enabled, and both plugins are affected when ssl_cert_login=true is enabled.
What does an attacker need to exploit it?
An attacker needs to run JavaScript in a victim's browser and induce that browser to connect to the affected WebSocket endpoint. With ssl_cert_login=true, the browser automatically presents the victim's client certificate, allowing the attacker's script to authenticate as that victim.
Are default configurations affected?
No. The issue is harmless when the plugins use the default in-band CONNECT credential configuration.
What can be done before upgrading?
If immediate patching is not possible, disable the affected non-default authentication configurations where feasible: use_http_auth=true for Web-STOMP and ssl_cert_login=true for either Web-STOMP or Web-MQTT. Using the default in-band CONNECT credential configuration avoids this issue.
Which versions contain the fix?
The issue is fixed in RabbitMQ 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0.