CVE-2026-67232 in RabbitMQ
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, The cowboy WebSocket options at line 117 set compress => true, enabling RFC 7692 permessage-deflate negotiation. The handler does not set max_frame_size, so cowboy's default of infinity applies. cowlib's cow_ws:parse_payload/9 calls zlib:inflate/2 on the compressed payload with no output-size limit. An attacker can negotiate permessage-deflate during the WebSocket upgrade and send a frame containing a zlib bomb (e.g. 50 KB → 5 GB). Decompression occurs in the connection process before websocket_handle/2 ever sees the MQTT bytes. An unauthenticated attacker can crash a RabbitMQ node running the Web-MQTT plugin by sending a single highly-compressed WebSocket frame (a few KB on the wire) that inflates to gigabytes in memory. The cowboy WebSocket handler decompresses the entire frame before the MQTT CONNECT packet is processed, so no credentials are required. Preconditions include rabbitmq_web_mqtt plugin enabled (not default, but common for browser clients) Network reachability to port 15675/15676 No authentication required. 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
The vulnerability identified involves a critical resource exhaustion flaw within the RabbitMQ Web-MQTT plugin, specifically affecting WebSocket connections that utilize permessage-deflate compression as defined by RFC 7692. This issue impacts multiple versions of RabbitMQ including those prior to 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0. The root cause lies in the configuration of the Cowboy WebSocket handler where the compress option is explicitly set to true at line 117 of the relevant source code. While this enables compression negotiation with clients, the implementation fails to configure a maximum frame size limit for decompression. Consequently, the underlying cowlib library utilizes its default behavior which allows an infinite output size during the inflation process. This architectural oversight creates a significant attack surface where memory consumption is unbounded relative to input data volume.
From a technical perspective, the flaw manifests when an attacker negotiates permessage-deflate compression during the WebSocket upgrade phase and subsequently transmits a specially crafted frame containing a zlib bomb. A zlib bomb is a compressed payload designed such that its decompressed size is exponentially larger than its original size; for instance, a few kilobytes on the network wire can inflate to several gigabytes in memory. The cow_ws:parse_payload/9 function calls zlib:inflate/2 on these payloads without imposing any output-size limits or sanity checks before allocation. Because this decompression occurs within the connection process prior to the execution of websocket_handle/2, the system allocates massive amounts of heap space for a single frame long before any application-level logic can intervene. This results in rapid memory exhaustion and subsequent node crashes due to out-of-memory conditions.
The operational impact of this vulnerability is severe as it allows an unauthenticated attacker to cause a denial of service against RabbitMQ nodes running the Web-MQTT plugin. Since the decompression happens before authentication checks are performed, no valid credentials or MQTT CONNECT packets are required to exploit the flaw. An attacker with network reachability to port 15675 for WebSocket connections over HTTP or port 15676 for secure WebSocket connections can trigger this condition remotely. The Web-MQTT plugin is not enabled by default but is commonly deployed in environments where browser-based clients need direct access to MQTT functionality, making the potential blast radius significant in such deployments. A successful exploit leads to the immediate termination of the RabbitMQ node process or severe degradation of service for all connected users due to resource starvation.
This vulnerability aligns with CWE-400 Uncontrolled Resource Consumption and is categorized under ATT&CK technique T1498 Network Denial of Service, specifically reflecting methods that involve overwhelming target resources through inefficient processing. To mitigate this risk, organizations must ensure they are running patched versions of RabbitMQ such as 3.13.15 or later in the 3.x series, or any version from the 4.0.20, 4.1.11, 4.2.6, and 4.3.0 release lines where this issue has been resolved. In environments where upgrading is not immediately feasible, administrators should consider disabling the Web-MQTT plugin if it is not strictly required or restricting network access to ports 15675 and 15676 via firewall rules to trusted sources only. Additionally, implementing a reverse proxy with strict rate limiting and payload size restrictions can provide an additional layer of defense by preventing excessively large compressed frames from reaching the RabbitMQ node for decompression.