CVE-2026-57220: 
RabbitMQ vulnerability analysis and mitigation

CVE-2026-57220 is a Denial of Service vulnerability in RabbitMQ's stream listener that allows unauthenticated remote attackers to exhaust broker memory by declaring oversized frame lengths during the authentication phase. The vulnerability affects RabbitMQ versions >= 4.2.0 and < 4.2.6 (specifically confirmed in 4.2.5), and requires only that the first-party rabbitmq_stream plugin be enabled and network-accessible on port 5552. It was disclosed on June 24, 2026, via a GitHub Security Advisory and assigned CVE-2026-57220 on July 10, 2026. The CVSS v3.1 base score is 7.5 (High) (GitHub Advisory, Feedly).

The root cause is CWE-770 (Allocation of Resources Without Limits or Throttling): the stream frame parser entry point in deps/rabbitmq_stream_common/src/rabbit_stream_core.erl contains an explicit %% TODO: check max frame size comment and never enforces the configured 1 MiB frame-size limit. When a client sends a 4-byte big-endian frame length header declaring an oversized value (e.g., 256 MiB or 1 GiB), the parser stores the declared remaining byte count and accumulates attacker-controlled chunks in broker memory via rabbit_stream_core, with Prev ++ [Data] list concatenation potentially amplifying allocator work. This processing occurs in rabbit_stream_reader.erl before authentication completes and before Tune negotiation, meaning no credentials or vhost access are required. The attack is bounded by the attacker's link speed multiplied by connection_negotiation_step_timeout (default 10 seconds), but can still drive substantial memory consumption, particularly in memory-constrained containerized deployments (GitHub Advisory).

Successful exploitation causes memory exhaustion in the RabbitMQ broker process (beam.smp), leading to broker or node unavailability — a complete Denial of Service affecting all messaging and streaming operations. The published PoC demonstrates deterministic node death under a 400 MiB cgroup memory limit, with the broker's AMQP (5672) and stream (5552) ports becoming unreachable after the attack. There is no confidentiality or integrity impact; the vulnerability is purely an availability issue affecting any workload dependent on the RabbitMQ broker (GitHub Advisory).

A complete, runnable Python proof-of-concept exploit is publicly available in the GitHub Security Advisory, demonstrating three stages: a bounded control test, an oversized pre-auth frame memory growth test, and a deterministic crash using a cgroup memory cap. The exploit requires no credentials, management access, or special configuration — only network reachability to port 5552. The EPSS score is approximately 0.0043 (low probability of exploitation in the wild), and there is no evidence of active in-the-wild exploitation or CISA KEV catalog listing as of the advisory date. The vulnerability is classified as automatable by NVD SSVC (GitHub Advisory, Feedly).

1. Reconnaissance: Identify RabbitMQ instances with the rabbitmq_stream plugin enabled and port 5552 accessible using network scanners (e.g., Shodan, Nmap: nmap -p 5552 <target>).
2. Verify target version: Confirm the broker is running a vulnerable version (>= 4.2.0, < 4.2.6) via banner grabbing or management API if accessible.
3. Establish TCP connection: Open a raw TCP socket to the target on port 5552 without sending any authentication credentials.
4. Send oversized frame length header: Transmit a 4-byte big-endian integer declaring a frame size far exceeding the 1 MiB limit (e.g., struct.pack('>I', 256 * 1024 * 1024) for 256 MiB).
5. Stream partial frame data: Send a large volume of arbitrary data (e.g., 128 MiB) without completing the declared frame, causing rabbit_stream_core to buffer the partial payload in broker memory.
6. Repeat or scale: Open multiple concurrent connections repeating steps 3–5 to accelerate memory exhaustion, bounded by the 10-second connection_negotiation_step_timeout.
7. Achieve DoS: Once broker memory is exhausted, the Erlang VM (beam.smp) is killed by the OS OOM killer or cgroup memory limit, taking down all RabbitMQ services including AMQP (port 5672) (GitHub Advisory).

• Network: Unexpected high-volume TCP connections to port 5552 from untrusted or external IP addresses; connections that remain open for extended periods without completing authentication; large inbound data transfers on port 5552 from a single source.
• Process: Rapid growth in VmRSS of the beam.smp process (observable via /proc/<pid>/status); OOM kill events for beam.smp in kernel logs (dmesg or /var/log/syslog).
• Logs: RabbitMQ log entries showing connection resets or abrupt disconnections from unauthenticated clients on the stream listener; Erlang VM error logger entries related to max_heap_size process termination (in patched versions); cgroup memory.events showing oom_group_kill 1 if memory limits are enforced.
• System: Sudden unavailability of RabbitMQ AMQP (port 5672) and stream (port 5552) ports following a spike in memory usage; rabbitmq-diagnostics ping failures coinciding with high inbound traffic on port 5552 (GitHub Advisory).

Upgrade RabbitMQ server to version 4.2.6 or later, which enforces a strict 16 MiB max_heap_size limit on all connection processes during the pre-authentication handshake phase across all protocol readers (Stream, AMQP 0-9-1, AMQP 1.0, MQTT, STOMP, Web MQTT, Web STOMP); if the limit is exceeded, the Erlang VM immediately terminates the offending process (GitHub PR #16171, GitHub PR #16173). The max_heap_size_unauthenticated environment variable is configurable per-application for tuning. As an immediate workaround if patching is not possible, restrict network access to the RabbitMQ stream listener (port 5552) to trusted clients only using firewall rules or network segmentation (GitHub Advisory).

The vulnerability was discovered and reported by researcher Asim Viladi Oglu Manizada (@manizada on GitHub), who disclosed using a custom AI agent pipeline for discovery followed by manual validation. A Mastodon post referencing the CVE was observed shortly after disclosure. The NixOS security tracker opened an issue tracking affected rabbitmq-server packages below 4.2.6, and a Korean threat intelligence repository (Argus) also catalogued the vulnerability. No major media coverage or vendor statements beyond the GitHub advisory have been identified (GitHub Advisory, GitHub PR #16171).