CVE-2026-67414: 
RabbitMQ vulnerability analysis and mitigation

CVE-2026-67414 is an amplification memory-exhaustion denial-of-service vulnerability in RabbitMQ's AMQP 1.0 binary parser. Any client that completes a SASL handshake can send a small frame (~30–128 KB) that the parser expands into multiple gigabytes of heap, potentially crashing the entire broker. Affected versions span RabbitMQ 4.0.0 through 4.0.23, 4.1.0 through 4.1.14, 4.2.0 through 4.2.9, and 4.3.0 through 4.3.3. The vulnerability was published on October 14, 2026, with a CVSS v4.0 base score of 6.0 (Medium) (GitHub Advisory, Feedly).

The root cause lies in deps/amqp10_common/src/amqp10_binary_parser.erl, which materializes each element of AMQP 1.0 arrays whose shared constructor has zero wire width (e.g., null, true, false, uint0, ulong0, list0 — wire codes 0x40–0x45) by calling lists:duplicate/2 to expand them into full Erlang lists, one term per element (CWE-770, CWE-400). While a per-array element cap of 10,000 existed, there was no aggregate limit on how many such arrays a single frame could contain, enabling a ~50,000× amplification ratio (30 KB in → ~2.4 GB heap). Compounding the issue, deps/rabbit/src/rabbit_amqp_reader.erl clears the max_heap_size kill-guard immediately after SASL authentication succeeds (rabbit_access_control:clear_max_heap_size()), so the pre-authentication 16 MiB heap limit no longer applies post-login. Frame parsing — including the unbounded allocation — occurs before any frame validation or authorization, meaning the memory is consumed regardless of subsequent rejection (GitHub Advisory, Fix Commit).

Successful exploitation causes a denial of service affecting the entire RabbitMQ broker node. A single authenticated connection sending a few tens of KB of crafted traffic can trigger the node-wide memory alarm, blocking all publishers across all vhosts on the node; sending approximately 180 KB across a few concurrent connections can OOM-kill the entire broker process. There is no confidentiality or integrity impact — the vulnerability is purely an availability issue — but because the memory alarm and OOM condition are node-wide, all tenants sharing the broker are affected regardless of their vhost isolation (GitHub Advisory).

A proof-of-concept Python script (amqp10_bomb.py) was published alongside the security advisory, demonstrating exploitation using only the Python standard library: it performs SASL PLAIN authentication as guest, sends an AMQP open frame, then sends a crafted frame containing an outer list32 of many zero-width null arrays. The attack requires only low-privilege credentials (default guest/guest suffices) and network access to port 5672. No in-the-wild exploitation has been reported, and the EPSS score is 0.0; the vulnerability is not listed in the CISA KEV catalog (GitHub Advisory, Feedly).

1. Reconnaissance: Identify RabbitMQ 4.x instances with the AMQP 1.0 listener exposed (default port 5672) using network scanning tools such as Shodan, Censys, or nmap. Confirm the version is in the affected range (4.0.0–4.0.23, 4.1.0–4.1.14, 4.2.0–4.2.9, or 4.3.0–4.3.3).
2. Obtain credentials: Use default credentials (guest/guest) or any valid low-privilege account with vhost access permissions — no elevated privileges are required.
3. Establish AMQP 1.0 connection: Open a raw TCP socket to port 5672 and complete the SASL PLAIN handshake using the obtained credentials. Send the AMQP open frame to establish the connection.
4. Craft malicious frame: Construct a frame containing an outer list32 of many zero-width null arrays, each encoded as f0 00000005 00002710 40 (array32, count=10,000, element=null). A single 128 KB frame containing ~13,100 such arrays expands to approximately 2 GB of heap.
5. Trigger memory exhaustion: Send the crafted frame (or a few concurrent frames totaling ~180 KB) to the broker. The parser materializes all array elements before any validation, consuming gigabytes of memory in the reader process, triggering the node-wide memory alarm and potentially OOM-killing the broker.
6. Verify impact: Monitor broker availability — publishers will be blocked once the memory high-watermark is crossed, and the broker process may terminate entirely with a few concurrent frames. The attack can be repeated trivially due to the ~50,000× amplification ratio (GitHub Advisory).

• Network: Unusual AMQP 1.0 connections on port 5672 sending large frames (approaching the 128 KB frame_max limit) shortly after authentication; multiple concurrent connections from the same source IP each sending near-maximum-size frames.
• Logs: RabbitMQ broker logs showing node-wide memory alarm activation (memory alarm set) shortly after a new client connection; OOM-related crash entries in the Erlang/OTP crash dump or system logs (erl_crash.dump).
• Process: Rapid growth of the rabbit_amqp_reader Erlang process heap visible via rabbitmq-diagnostics memory or rabbitmqctl status; broker process termination with out-of-memory signals.
• System: OS-level OOM killer events in /var/log/syslog or dmesg referencing the beam.smp process; sudden drop in broker availability metrics or health check failures (GitHub Advisory).

Upgrade to one of the patched versions: 4.0.24, 4.1.15, 4.2.10, or 4.3.4. The fix changes the parser to represent zero-width arrays as opaque constant-size values ({as_is, TypeCode, Bin}) rather than materializing them as full Erlang lists, eliminating the memory amplification entirely (Fix Commit, v4.3.4 Release). If immediate upgrade is not possible, restrict network access to port 5672 to trusted clients only, and enforce strong credential policies to prevent unauthorized SASL authentication — since the vulnerability requires a completed SASL handshake, eliminating anonymous or default credential access reduces exposure (GitHub Advisory).