CVE-2026-67225: RabbitMQ: Stream-protocol frame length never validated against frame_max
RabbitMQ is a messaging and streaming broker. From 3.13.0 until 3.13.15, 4.0.20, 4.1.11, and 4.2.6, the stream protocol stored the FrameMax value negotiated during the Tune handshake but did not compare it with an inbound frame's declared length before buffering the frame. With the stream plugin enabled, a remote client could therefore cause excessive memory pressure and denial of service by declaring an oversized frame. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 3.13.15 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.0.20 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.1.11 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.2.6
Event History
Frequently Asked Questions
Which deployments are exposed?
Deployments running RabbitMQ versions 3.13.0 through versions before 3.13.15, 4.0.20, 4.1.11, or 4.2.6 are affected when the stream plugin is enabled. The issue concerns the stream protocol.
What does an attacker need to exploit this?
A remote client must be able to use the stream protocol. The client can declare an inbound frame length larger than the FrameMax value negotiated during the Tune handshake, causing excessive memory pressure and potentially denial of service.
How can the issue be remediated?
Upgrade to RabbitMQ 3.13.15, 4.0.20, 4.1.11, or 4.2.6. These versions validate inbound stream-frame lengths against the negotiated FrameMax value.
What can be done if an upgrade cannot be applied immediately?
Disable the stream plugin where it is not required. This removes the affected protocol path described for this issue.