Skip to content

Stream-protocol frame length never validated against frame_max

Moderate
ansd published GHSA-c8c4-gvv4-8j3q Jul 9, 2026

Software

rabbitmq-server

Affected versions

>= 3.13.0, < 3.13.15
>= 4.0.0, < 4.0.20
>= 4.1.0, < 4.1.11
>= 4.2.0, < 4.2.6

Patched versions

3.13.15
4.0.20
4.1.11
4.2.6

Description

Origin

This vulnerability was identified by Team RabbitMQ and/or other teams at Broadcom, not via a responsible disclosure from an external researcher.

Impact

The frame size limit negotiated during the stream-protocol handshake is never enforced against the declared length of inbound frames. A client can send a frame whose declared size exceeds the negotiated frame_max, and the broker buffers the frame data before any size check is applied. This produces memory pressure on the node and a potential denial of service. The condition is reachable before authentication over the network.

Description

The stream protocol negotiates a maximum frame size (FrameMax) during the Tune handshake. The negotiated value is stored but never applied to incoming frames. A %% TODO: check max frame size comment in rabbit_stream_core (deps/rabbitmq_stream_common/src/rabbit_stream_core.erl) confirmed the gap: the 4-byte frame size header is read and the frame is buffered without comparing the declared length against frame_max.

Preconditions

The stream plugin must be enabled.

CVSS

CVSS v4.0: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N (6.3, Moderate). Fixed in 3.13.15, 4.0.20, 4.1.11, 4.2.6, 4.3.0.

Severity

Moderate

CVE ID

No known CVE

Weaknesses

Allocation of Resources Without Limits or Throttling

The product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated. Learn more on MITRE.