CVE-2026-67230: RabbitMQ Web STOMP Auth Bypass Vulnerability

CVE-2026-67230 Overview

CVE-2026-67230 is a resource exhaustion vulnerability [CWE-770] in the RabbitMQ Web STOMP WebSocket handler. The flaw affects RabbitMQ versions from 3.13.0 up to (but not including) 3.13.15, 4.0.20, 4.1.11, and 4.2.6. The Web STOMP WebSocket handler enforces neither max_frame_size nor login_timeout prior to authentication. An unauthenticated remote client can keep a WebSocket connection alive with a slow stream of small frames and accumulate unbounded pre-authentication state. Exploitation requires only that the rabbitmq_web_stomp plugin is enabled, and no credentials are needed to reach the vulnerable path.

Critical Impact
Unauthenticated remote attackers can exhaust broker memory and connection resources, degrading or denying service to legitimate messaging clients.

Affected Products

RabbitMQ Server 3.13.0 through 3.13.14 (rabbitmq_web_stomp plugin enabled)
RabbitMQ Server 4.0.x prior to 4.0.20
RabbitMQ Server 4.1.x prior to 4.1.11 and 4.2.x prior to 4.2.6

Discovery Timeline

2026-09-25 - CVE-2026-67230 published to NVD
2026-09-29 - Last updated in NVD database

Technical Details for CVE-2026-67230

Vulnerability Analysis

The rabbitmq_web_stomp plugin exposes STOMP (Simple Text Oriented Messaging Protocol) over WebSocket. When a client initiates a WebSocket connection, the handler creates per-connection state before the client has authenticated. The pre-authentication path lacks two critical controls: a bound on inbound WebSocket frame size and a timer that terminates connections that fail to authenticate within a window. An attacker who repeatedly opens connections and dribbles small frames can hold sockets open indefinitely while server-side buffers and process state grow. The behavior maps to [CWE-770: Allocation of Resources Without Limits or Throttling].

Root Cause

In the vulnerable code path, websocket_init/1 in rabbit_web_stomp_handler.erl initializes processor state without arming a login_timeout message. Separately, the Cowboy WebSocket options passed during the HTTP upgrade do not set max_frame_size, so Cowboy accepts frames up to its default (large) ceiling. The combination allows unauthenticated clients to buffer large or long-lived frames and tie up broker resources.

Attack Vector

An attacker reaches the vulnerable path over the network by connecting to the Web STOMP endpoint (commonly TCP/15674). No authentication, no user interaction, and low attack complexity are required. By opening many WebSocket connections and sending small or fragmented frames without ever issuing a STOMP CONNECT, the attacker forces the broker to retain each connection's state. At scale, this consumes memory, file descriptors, and scheduler time, leading to availability impact on the messaging broker.

The following patch excerpt arms a login timeout on each new WebSocket connection:

erlang

websocket_init(State) ->
    process_flag(trap_exit, true),
    {ok, ProcessorState} = init_processor_state(State),
    LoginTimeout = application:get_env(rabbitmq_stomp, login_timeout, 10_000),
    erlang:send_after(LoginTimeout, self(), login_timeout),
    {ok, rabbit_event:init_stats_timer(
           State#state{proc_state     = ProcessorState,
                       parse_state    = rabbit_stomp_frame:initial_state()},

Source: RabbitMQ Server Commit 0b4080f

A second patch applies a bounded max_frame_size to Cowboy's WebSocket options:

erlang

WsOpts0 = proplists:get_value(ws_opts, Opts, #{}),
MaxFrameSize = application:get_env(
    rabbitmq_stomp, max_frame_size, ?DEFAULT_MAX_FRAME_SIZE) + 4096,
WsOpts = maps:merge(#{compress => true,
                     max_frame_size => MaxFrameSize}, WsOpts0),

Source: RabbitMQ Server Commit 8138eda

Detection Methods for CVE-2026-67230

Indicators of Compromise

A sustained increase in the number of open Web STOMP WebSocket connections from a small set of source IP addresses.
Growing RabbitMQ process memory or Erlang process count without a corresponding increase in authenticated sessions or published messages.
Connections to TCP port 15674 (default Web STOMP) that remain open for extended periods without issuing a STOMP CONNECT frame.

Detection Strategies

Audit broker telemetry for connection churn and long-lived unauthenticated sessions using rabbitmqctl list_connections and the management UI.
Correlate network flow logs with broker connection counts to identify clients that open many WebSockets but never authenticate.
Alert on anomalous growth in Erlang VM memory, inet port count, or scheduler run queues on hosts running rabbitmq_web_stomp.

Monitoring Recommendations

Export RabbitMQ Prometheus metrics and alert on rabbitmq_connections growth decoupled from rabbitmq_channels_opened_total.
Forward broker and reverse-proxy logs to a centralized analytics backend to retain per-connection state and spot slow-frame patterns.
Place rate limits and connection caps at a load balancer or reverse proxy in front of the Web STOMP listener.

How to Mitigate CVE-2026-67230

Immediate Actions Required

Upgrade RabbitMQ to 3.13.15, 4.0.20, 4.1.11, or 4.2.6 or later, which enforce login_timeout and a pre-authentication max_frame_size.
If upgrading is not immediately possible, disable the rabbitmq_web_stomp plugin on brokers that do not require WebSocket STOMP.
Restrict exposure of the Web STOMP listener (default TCP/15674) to trusted networks only.

Patch Information

The fix ships in RabbitMQ 3.13.15, 4.0.20, 4.1.11, and 4.2.6. The relevant commits add a login_timeout timer to websocket_init/1, set Cowboy's max_frame_size for both Web STOMP and Web MQTT upgrade handlers, and introduce ?DEFAULT_MAX_FRAME_SIZE_UNAUTHENTICATED (65536 bytes) along with a new stomp.max_frame_size_unauthenticated setting. Full details are in the RabbitMQ Security Advisory GHSA-7v63-j4gm-p4rh and the RabbitMQ Server v4.2.6 release notes.

Workarounds

Disable the plugin with rabbitmq-plugins disable rabbitmq_web_stomp on brokers that do not serve WebSocket STOMP clients.
Terminate the WebSocket upgrade at a reverse proxy (for example, NGINX or HAProxy) and enforce per-client connection limits, idle timeouts, and small frame size limits.
Block or firewall TCP/15674 (and the TLS variant on 15673) from untrusted networks.

bash

# Disable the Web STOMP plugin as a temporary workaround
rabbitmq-plugins disable rabbitmq_web_stomp

# After upgrading, tune the pre-authentication frame size limit
# in rabbitmq.conf (new setting introduced by the patch)
stomp.max_frame_size_unauthenticated = 65536
stomp.max_frame_size = 4194304