GHSA-5xwg-cfvj-gff5: Input Validation
Summary The max body size was enforced to patch CVE-2023-46120, but even though that limit still works, the frame size itself still exceeds the given max size.
Root cause The Java client records the AMQP 0-9-1 framemax negotiated during connection tuning, but the socket inbound frame reader continues to validate broker-controlled payload lengths against the much larger maxInboundMessageBodySize limit. A broker peer can therefore send a method frame whose payload is larger than the negotiated framemax, have it allocated and decoded, and complete the connection handshake instead of being rejected as a protocol violation.
Reported by Team Atlanta.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
maven/com.rabbitmq:amqp-clientto a version that resolves this vulnerability.Fixed in 5.33.0
Event History
Frequently Asked Questions
Who can exploit this issue?
Clients are exposed when they connect to a broker peer that can send crafted AMQP 0-9-1 frames during connection tuning and the handshake. The broker controls the payload lengths checked by the inbound frame reader.
What conditions are required for exploitation?
The connection must negotiate a frame_max smaller than the client's maxInboundMessageBodySize. A malicious broker can then send an oversized method-frame payload that exceeds frame_max but remains within the larger inbound body-size limit, allowing allocation and decoding instead of protocol rejection.
Does the maximum inbound message body size mitigate the issue?
The configured maximum inbound message body size still limits payloads, but it does not enforce the negotiated frame_max for inbound frame validation. As a result, setting a body-size limit alone does not prevent frames larger than the negotiated protocol limit from being accepted.