GHSA-jh4v-gfqj-7rhx

Dashboard / Vulnerabilities / GHSA-jh4v-gfqj-7rhx

GHSA-jh4v-gfqj-7rhx

Summary: RabbitMQ Java client has frame-level OOM: Math.min(maxInboundMessageBodySize, 0) defeats frame size enforcement

Details: ## Vulnerability In `AMQConnection.java` (line 435-436), after `Connection.Tune` negotiation, the frame-max limit is set via: ```java _frameHandler.setFrameMax( Math.min(this.maxInboundMessageBodySize, frameMax)); ``` When `frameMax = 0` (meaning "unlimited" per AMQP spec), `Math.min(67108864, 0) = 0`. This value is then passed to `Utils.framePayloadLimit(0)` which returns `Integer.MAX_VALUE` (line 77-79 of Utils.java): ```java static int framePayloadLimit(int frameMax) { if (frameMax <= 0) { return Integer.MAX_VALUE; } // ... } ``` This completely defeats the `maxInboundMessageBodySize` protection (default 64MB) at the frame level. ## Attack Scenario A malicious AMQP server (or MITM) sends `Connection.Tune` with `frameMax=0`: 1. Client defaults: `requestedFrameMax = 0` (`ConnectionFactory.DEFAULT_FRAME_MAX`, line 82) 2. `negotiatedMaxValue(0, 0)` = `Math.max(0, 0)` = 0 (line 673-676) 3. `Math.min(maxInboundMessageBodySize, 0)` = 0 — **64MB cap defeated** 4. `framePayloadLimit(0)` = `Integer.MAX_VALUE` — no frame size enforcement 5. Attacker sends a single frame with `frameSize = 0x1FFFFFFF` (~500MB) 6. `Frame.readFrom()` (line 135) executes `new byte[frameSize]` — **OOM crash** The frame does not need to be a body frame — method frames, header frames, or heartbeat frames with a crafted size field all trigger the allocation before any content-level check fires. ## Root Cause The AMQP spec uses `frameMax=0` to mean "unlimited", but `Math.min` treats it as the integer value zero. The intent of line 435-436 was to take the smaller of the two limits, but when one limit uses 0-means-unlimited semantics, `Math.min` always selects the zero, disabling the other limit. ## Impact - **Default configuration is vulnerable**: Both `requestedFrameMax` (client) and legitimate servers' `frameMax` in Tune may be 0 - **Single-frame OOM**: One malicious frame triggers up to ~2GB allocation (`Integer.MAX_VALUE` bytes) - **Bypasses existing protection**: `maxInboundMessageBodySize` (introduced to cap allocations at 64MB) is entirely defeated at the frame level - **Different from ValueReader OOM**: This is a frame-layer allocation in `Frame.readFrom()`, not a value-layer allocation in `ValueReader.readBytes()` ## Affected Code - `AMQConnection.java:435-436` — `Math.min` with 0-means-unlimited - `Utils.java:77-79` — `framePayloadLimit(0)` returns `Integer.MAX_VALUE` - `Frame.java:135` — `new byte[frameSize]` allocation site - `ConnectionFactory.java:82` — `DEFAULT_FRAME_MAX = 0` ## Suggested Fix ```java int effectiveFrameMax = (frameMax == 0) ? this.maxInboundMessageBodySize : Math.min(this.maxInboundMessageBodySize, frameMax); _frameHandler.setFrameMax(effectiveFrameMax); ``` This treats `frameMax=0` as "use maxInboundMessageBodySize as the cap" instead of "zero".

References: https://github.com/rabbitmq/rabbitmq-java-client/security/advisories/GHSA-jh4v-gfqj-7rhx, https://nvd.nist.gov/vuln/detail/CVE-2026-75516, https://github.com/rabbitmq/rabbitmq-java-client/pull/2015, https://github.com/rabbitmq/rabbitmq-java-client/pull/2016, https://github.com/rabbitmq/rabbitmq-java-client/commit/6d7c2bfe89796ca34d3531098fb59dd657fea39e, https://github.com/rabbitmq/rabbitmq-java-client/commit/e7f10bf99aee103dd9f64b3e52a725fc9f9d3763, https://github.com/rabbitmq/rabbitmq-java-client, https://github.com/rabbitmq/rabbitmq-java-client/releases/tag/v5.34.0