CVE-2026-57212: Broadcom RabbitMQ Server DoS Vulnerability

CVE-2026-57212 Overview

CVE-2026-57212 is a resource exhaustion vulnerability [CWE-770] in the RabbitMQ messaging and streaming broker. The rabbitmq_management HTTP API accepts oversized valid JSON bodies on the with_decode and direct_request paths. The read_complete_body function in rabbit_mgmt_util.erl checks the accumulated size before the final chunk but fails to validate the final combined size. Authenticated attackers can submit oversized JSON payloads to consume memory and degrade broker availability. The issue affects Broadcom RabbitMQ Server versions prior to 3.13.14, 4.0.19, 4.1.10, and 4.2.5.

Critical Impact
Authenticated attackers can bypass HTTP body size limits on the management API to send oversized JSON payloads, causing memory exhaustion and denial of service against the RabbitMQ broker.

Affected Products

Broadcom RabbitMQ Server versions prior to 3.13.14
Broadcom RabbitMQ Server 4.0.x prior to 4.0.19 and 4.1.x prior to 4.1.10
Broadcom RabbitMQ Server 4.2.x prior to 4.2.5

Discovery Timeline

2026-07-10 - CVE-2026-57212 published to NVD
2026-07-13 - Last updated in NVD database

Technical Details for CVE-2026-57212

Vulnerability Analysis

The vulnerability resides in the read_complete_body/1 function within deps/rabbitmq_management/src/rabbit_mgmt_util.erl. This function reads HTTP request bodies in chunks using cowboy_req:read_body. The original implementation enforced a BodySizeLimit check on the accumulated buffer before appending the next chunk, but skipped the check on the final {ok, Data, Req} return path.

An authenticated attacker with access to the management HTTP API can submit a request to endpoints handled by with_decode or direct_request. By staging the payload so the last chunk pushes the total body size past the configured limit, the attacker bypasses enforcement. The broker then processes and decodes an oversized valid JSON body, consuming memory proportional to the payload size.

Root Cause

The root cause is an incomplete size validation check [CWE-770: Allocation of Resources Without Limits or Throttling]. The pre-patch code returned {ok, <<Acc/binary, Data/binary>>, Req} on the terminal chunk without re-evaluating whether the combined buffer exceeded BodySizeLimit. Only the intermediate {more, Data, Req} accumulation branch received bounds checks, and even that check was performed before appending new data rather than after.

Attack Vector

Exploitation requires network access to the RabbitMQ management HTTP API and valid low-privilege credentials. The attacker sends a chunked HTTP POST or PUT to a with_decode or direct_request endpoint, sizing chunks so that the accumulated size passes intermediate checks. Successful exploitation targets broker availability rather than confidentiality or integrity.

text

             {error, http_body_limit_exceeded, BodySizeLimit, N};
         false ->
             case cowboy_req:read_body(Req0) of
-                {ok, Data, Req}   -> {ok, <<Acc/binary, Data/binary>>, Req};
-                {more, Data, Req} -> read_complete_body(Req, <<Acc/binary, Data/binary>>)
+                {ok, Data, Req} ->
+                    Total = <<Acc/binary, Data/binary>>,
+                    case byte_size(Total) > BodySizeLimit of
+                        true ->
+                            {error, http_body_limit_exceeded, BodySizeLimit, byte_size(Total)};
+                        false ->
+                            {ok, Total, Req}
+                    end;
+                {more, Data, Req} ->
+                    Total = <<Acc/binary, Data/binary>>,
+                    case byte_size(Total) > BodySizeLimit of
+                        true ->
+                            {error, http_body_limit_exceeded, BodySizeLimit, byte_size(Total)};
+                        false ->
+                            read_complete_body(Req, Total, BodySizeLimit)
+                    end
             end
     end.

Source: RabbitMQ Server Commit 3976d14. The patch enforces byte_size(Total) > BodySizeLimit after each cowboy_req:read_body return, including the terminal {ok, Data, Req} case.

Detection Methods for CVE-2026-57212

Indicators of Compromise

HTTP requests to /api/* endpoints on the management port (default 15672) with large Content-Length values or chunked transfer encoding carrying oversized JSON bodies.
Sudden growth in RabbitMQ Erlang VM memory usage correlated with management API traffic.
Broker memory alarms triggering under vm_memory_high_watermark thresholds without corresponding queue or message workload growth.

Detection Strategies

Inspect reverse proxy or load balancer logs fronting the management API for POST or PUT requests with request body sizes that exceed the configured management.http.max_body_size value.
Monitor RabbitMQ logs for http_body_limit_exceeded errors, which indicate limit enforcement is now active on patched systems.
Correlate authenticated management API sessions against user roles and geographic baselines to surface anomalous administrative activity.

Monitoring Recommendations

Enable request logging on the rabbitmq_management plugin and forward logs to a centralized SIEM for analysis.
Track Erlang process memory and total node memory via the built-in Prometheus exporter, alerting on rapid increases tied to API requests.
Audit access to with_decode and direct_request code paths, including endpoints for definitions import, policy creation, and shovel or federation configuration.

How to Mitigate CVE-2026-57212

Immediate Actions Required

Upgrade RabbitMQ Server to 3.13.14, 4.0.19, 4.1.10, or 4.2.5 or later, matching the appropriate release train.
Restrict network access to the management HTTP API (default port 15672) so it is not reachable from untrusted networks.
Rotate and review management API credentials, and remove any accounts that do not require administrative access.

Patch Information

The fix is delivered in RabbitMQ Server 3.13.14, 4.0.19, 4.1.10, and 4.2.5. Refer to the GitHub Security Advisory GHSA-5cmq-vp28-xqrj, the RabbitMQ Server Release v4.2.5 notes, and pull requests #15712 and #15714 for full technical details.

Workarounds

Place the management API behind a reverse proxy such as NGINX or HAProxy and enforce a strict client_max_body_size limit at the proxy layer.
Apply firewall rules restricting the management port to a trusted management network or bastion host.
Reduce management API user privileges to the minimum required, and disable the rabbitmq_management plugin on nodes that do not require it.

bash

# NGINX reverse proxy example enforcing a hard body size cap
server {
    listen 443 ssl;
    server_name rabbitmq-mgmt.example.com;

    client_max_body_size 1m;

    location /api/ {
        proxy_pass http://127.0.0.1:15672;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

# Disable the management plugin on nodes that do not need it
rabbitmq-plugins disable rabbitmq_management