RabbitMQ CVE-2026-67230

Requires the non-default rabbitmq_web_stomp plugin to be enabled and its WebSocket endpoint network-reachable; the affected versions are RabbitMQ 3.13.0 through pre-3.13.15, pre-4.0.20, pre-4.1.11, and pre-4.2.6. No authentication is needed to reach the vulnerable path (PR:N), and no user interaction is required, but meaningful impact requires the attacker to open and sustain many slow, small-frame WebSocket connections over time (reflected by AT:P), so a single request is insufficient. Deployments without the Web STOMP plugin enabled, or on fixed versions where login_timeout now closes unauthenticated connections after ~10 seconds, are not exploitable.

This is a genuine but low-priority pre-authentication denial-of-service issue. The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N) correctly shows a network-reachable, unauthenticated flaw, but impact is confined to availability only (VC:N/VI:N/VA:L) - consistent with the CWE-770 uncontrolled resource consumption described. The AT:P (attack requirements present) metric and the 6.3 base score reflect that meaningful impact requires sustaining many slow, small-frame connections (slowloris-style) rather than a single request, and that pre-auth state grows gradually rather than crashing the broker instantly. No EPSS score, no CISA KEV listing, and no public exploit are present in the input, so exploitation is theoretical at this time. The most important limiting signal is deployment-based, not in the CVSS: the vulnerable path only exists when the non-default rabbitmq_web_stomp plugin is enabled, which sharply narrows the real-world attack surface. Net: a real defect worth patching on affected/plugin-enabled nodes, but not an urgent, widely-exploitable priority despite the network/unauthenticated vector.

An attacker who can reach a RabbitMQ node that has the rabbitmq_web_stomp plugin enabled opens many WebSocket connections and, without ever authenticating, trickles small STOMP frames slowly to keep each connection alive. Because neither login_timeout nor max_frame_size was enforced before authentication, each connection accumulates unbounded pre-auth state, exhausting memory/connection resources and degrading availability for legitimate clients. No public exploit is identified in the provided data; the technique is a standard slow-connection resource-exhaustion pattern requiring sustained, repeated connections (reflected by AT:P).