CVE-2026-67232: RabbitMQ: Web-MQTT decompression bomb
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 maxframesize, so cowboy's default of infinity applies. cowlib's cowws:parsepayload/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 websockethandle/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 rabbitmqwebmqtt 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.
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 denial-of-service issue?
A RabbitMQ node is exposed when the rabbitmq_web_mqtt plugin is enabled and an attacker can reach its Web-MQTT listener on port 15675 or 15676. The plugin is not enabled by default, although it is commonly used for browser clients.
Does an attacker need credentials or MQTT access to trigger the issue?
No. An unauthenticated attacker can negotiate permessage-deflate during the WebSocket upgrade and send a highly compressed frame; decompression happens before the MQTT CONNECT packet is processed.
What is the practical impact of a successful attack?
A single small WebSocket frame can inflate to gigabytes of memory in the connection process and crash the RabbitMQ node. The affected handler has no output-size limit during decompression.
What can be done if an upgrade cannot happen immediately?
Disable the rabbitmq_web_mqtt plugin where it is not required, or restrict network access to ports 15675 and 15676 to trusted clients. These measures remove or limit the unauthenticated attack path described.
Which releases 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.