GHSA-5cmq-vp28-xqrj

Описание

Overview

The rabbitmq_management HTTP API appears to enforce a request body size limit through max_http_body_size, but in practice it accepts oversized valid JSON bodies and processes them normally.

The root cause is that the helper responsible for reading the request body checks the accumulated size only before reading the final chunk and does not validate the final combined size after appending that chunk.

• Vulnerability type: Request body size limit bypass
• Affected component: rabbitmq_management
• Verification date: 2026-03-11

Impact

Even when an operator configures a management HTTP API body size limit, endpoints that use the with_decode or direct_request paths do not enforce that limit completely.

As a result, an attacker can send JSON requests larger than the configured limit, and management operations that should have been blocked are still processed.

The exact impact depends on the endpoint, but at minimum the following problems exist:

• Oversized body blocking policies can be bypassed
• Operator expectations around management API input size control are broken
• Additional resources may be consumed for body parsing, decoding, and management operations

Root Cause Summary

The issue follows this path:

1. read_complete_body/3 checks the accumulated size only before calling cowboy_req:read_body/1
2. After reading the final chunk and constructing Acc ++ Data, it returns without re-checking the total size
3. Endpoints using with_decode and direct_request inherit this behavior

Relevant code locations:

• Vulnerable body reader: rabbit_mgmt_util.erl
• with_decode path: rabbit_mgmt_util.erl
• direct_request path: rabbit_mgmt_util.erl
• Endpoint used for reproduction: rabbit_mgmt_wm_exchange_publish.erl

Detailed Analysis

1. No size re-check after the final chunk

The vulnerable helper looks like this:

It only validates N = byte_size(Acc). If Acc is still under the limit before the final Data chunk is read, the final combined result <<Acc, Data>> can exceed the limit and still be returned as {ok, Body, Req}.

2. Rejection depends entirely on the helper return value

with_decode rejects a request only when the helper returns {error, http_body_limit_exceeded, ...}.

Because the helper can return oversized bodies as {ok, Body, Req}, limit-exceeding requests continue into JSON decoding and the endpoint-specific logic.

3. The impact extends beyond a single endpoint

The same helper is used not only by with_decode, but also by the direct_request path.

This means the bug is not just an isolated endpoint mistake. It is a flaw in the shared management API body-reading logic.

Dynamic Reproduction Environment

The issue was reproduced locally under the following conditions:

• A broker with rabbitmq_management enabled was running
• A management API account was used
• rabbitmq_management.max_http_body_size was temporarily reduced to 120 at runtime for deterministic testing
• The reproduction used /api/exchanges/%2F/amq.default/publish

Reproduction Steps

1. Lower the body size limit

To make the behavior easy to observe, the runtime limit was reduced to 120.

Observed output:

2. Send below-limit and above-limit requests

Valid JSON bodies of different sizes were sent to the same endpoint.

3. Compare expected and actual behavior

• With payload_chars=30, the full JSON body length was 114 bytes, which is below the 120 byte limit
• With payload_chars=40, the full JSON body length was 124 bytes, which exceeds the 120 byte limit
• With payload_chars=200, the full JSON body length was 284 bytes, which significantly exceeds the 120 byte limit

In a correct implementation, the 124 and 284 byte requests should be rejected.

Reproduction Results

The actual responses were:

Both requests larger than the configured limit were accepted with HTTP 200, and the publish operation was still performed.

This demonstrates that max_http_body_size can be bypassed in this code path.

Notes

After reproduction, the temporary setting was restored to the default value.

Observed output:

Recommended Fix

The smallest fix is to re-check the total body size immediately after each chunk is read.

At minimum, the following conditions should be enforced:

• Before returning {ok, Data, Req}, validate byte_size(Acc) + byte_size(Data)
• Before recursing on {more, Data, Req}, reject as soon as the new accumulated size exceeds the limit

The following regression tests should also be added:

• Verify that a valid JSON body larger than max_http_body_size is rejected on with_decode paths
• Verify the same behavior on direct_request paths
• Verify that multi-chunk bodies are blocked consistently whether or not Content-Length is present

Conclusion

The shared rabbitmq_management body reader does not fully enforce the HTTP request body size limit.

• The accumulated size is not re-validated after the final chunk
• Valid JSON bodies larger than the configured limit are accepted by a live endpoint
• Because the issue exists in a shared helper, multiple management API endpoints may be affected

This is therefore a management HTTP API body size limit bypass.