CVE-2026-67405: RabbitMQ Authentication Bypass Vulnerability

CVE-2026-67405 Overview

CVE-2026-67405 is a missing Origin header validation vulnerability in RabbitMQ's Web-MQTT and Web-STOMP plugins. The affected handlers, rabbit_web_mqtt_handler.erl and rabbit_web_stomp_handler.erl, accept WebSocket upgrade requests without verifying the requesting origin. When RabbitMQ is configured with ssl_cert_login=true or use_http_auth=true, the browser automatically presents the victim's client certificate during the TLS handshake. Attacker-controlled JavaScript running in the victim's browser can then authenticate to the broker as the victim across origins. The flaw is fixed in RabbitMQ versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0. The weakness is classified as [CWE-1385] Missing Origin Validation in WebSockets.

Critical Impact
Cross-origin WebSocket hijacking allows attackers to impersonate authenticated users against RabbitMQ brokers running Web-MQTT or Web-STOMP with certificate-based or HTTP-based authentication.

Affected Products

RabbitMQ Server versions prior to 3.13.15 (3.13.x branch)
RabbitMQ Server versions prior to 4.0.20, 4.1.11, and 4.2.6
RabbitMQ deployments with the rabbitmq_web_mqtt or rabbitmq_web_stomp plugins enabled and ssl_cert_login=true or use_http_auth=true

Discovery Timeline

2026-09-23 - CVE-2026-67405 published to NVD
2026-09-23 - Last updated in NVD database

Technical Details for CVE-2026-67405

Vulnerability Analysis

RabbitMQ ships two browser-facing plugins that expose messaging protocols over WebSockets. The Web-MQTT handler at deps/rabbitmq_web_mqtt/src/rabbit_web_mqtt_handler.erl:104 and the Web-STOMP handler at deps/rabbitmq_web_stomp/src/rabbit_web_stomp_handler.erl:102 accept the WebSocket upgrade without inspecting the Origin header. Browsers do not enforce the Same-Origin Policy on WebSocket handshakes the way they do for XMLHttpRequest, so the server must validate Origin itself.

When the broker is deployed with ssl_cert_login=true, RabbitMQ derives the authenticated username from the TLS client certificate. Because browsers automatically attach client certificates during TLS negotiation, any WebSocket connection initiated from JavaScript inherits the victim's identity. The Web-STOMP variant with use_http_auth=true behaves similarly by reusing HTTP-layer credentials. The default in-band CONNECT credential configuration is not affected because credentials are supplied inside the protocol frame rather than by the browser.

Root Cause

The root cause is missing enforcement of the WebSocket Origin header inside both Cowboy-based handlers. The upgrade path returns success for any origin, permitting cross-site WebSocket hijacking whenever an ambient authentication mechanism is enabled.

Attack Vector

An attacker hosts a malicious page and lures an authenticated RabbitMQ user to visit it. JavaScript on the page opens a wss:// connection to the target broker. The victim's browser completes the TLS handshake, presenting the client certificate, and RabbitMQ associates the WebSocket session with the victim's identity. The attacker's script can then publish, subscribe, and consume messages within the victim's authorization scope.

No exploitation code is required beyond a standard WebSocket constructor call from the attacker's page. Technical details are documented in the GitHub Security Advisory GHSA-9c4f-rxxm-88q3.

Detection Methods for CVE-2026-67405

Indicators of Compromise

WebSocket upgrade requests to /ws endpoints on Web-MQTT (port 15675) or Web-STOMP (port 15673) with Origin headers that do not match approved application domains.
Successful MQTT or STOMP sessions authenticated by client certificate from user-agent strings identifying browsers rather than known service clients.
Unexpected subscribe, publish, or consume activity from user accounts shortly after web-browsing sessions.

Detection Strategies

Review reverse proxy and load balancer access logs for WebSocket upgrade requests with unusual Origin or Referer values targeting RabbitMQ endpoints.
Correlate RabbitMQ connection logs (connection_created events) with the presenting TLS certificate subject and the source user-agent to flag browser-initiated sessions.
Search for authentication events where the transport is Web-MQTT or Web-STOMP and the ssl_cert_login mechanism was used from external IP ranges.

Monitoring Recommendations

Enable RabbitMQ management plugin auditing and forward connection and channel events to a centralized log store.
Alert on new client certificate subjects establishing WebSocket sessions outside of documented application hosts.
Baseline expected client Origin values per environment and alert on deviations at the edge proxy layer.

How to Mitigate CVE-2026-67405

Immediate Actions Required

Upgrade RabbitMQ to 3.13.15, 4.0.20, 4.1.11, 4.2.6, or 4.3.0 or later.
Audit broker configuration for ssl_cert_login=true and use_http_auth=true; disable these settings on Web-MQTT and Web-STOMP listeners if not strictly required.
Restrict network exposure of ports 15673 and 15675 to trusted internal networks or authenticated reverse proxies.

Patch Information

The RabbitMQ team addressed the missing Origin validation in the Web-MQTT and Web-STOMP handlers. See the RabbitMQ Server v4.2.6 Release and RabbitMQ Server v4.3.0 Release notes for changelog details. Backports are available for the 3.13, 4.0, and 4.1 branches.

Workarounds

Revert to the default in-band CONNECT credential model where clients supply credentials in the MQTT or STOMP CONNECT frame instead of relying on ambient browser authentication.
Terminate WebSocket traffic at a reverse proxy (for example NGINX or HAProxy) that enforces an Origin header allowlist before forwarding the upgrade to RabbitMQ.
Segment the broker so browser-facing listeners are only reachable from application origins that never render untrusted third-party content.

bash

# NGINX example: enforce Origin allowlist before WebSocket upgrade
map $http_origin $origin_allowed {
    default 0;
    "https://app.example.com" 1;
}

server {
    listen 443 ssl;
    server_name mq.example.com;

    location /ws {
        if ($origin_allowed = 0) { return 403; }
        proxy_pass http://rabbitmq_web_mqtt;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}