< Back

CVE-2026-75516

Updated on 16 Sep 2026

Severity

8.7 High severity

Details

CVSS score
8.7
CVSS vector
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
CWE ID
Links
NISTCIRCLRHELUbuntu

Overview

About vulnerability

Vulnerability

In AMQConnection.java (line 435-436), after Connection.Tune negotiation, the frame-max limit is set via:

_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):

static int framePayloadLimit(int frameMax) {
if (frameMax &lt;= 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&#91;frameSize&#93; — 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&#91;frameSize&#93; allocation site
  • ConnectionFactory.java:82 — DEFAULT_FRAME_MAX = 0

Suggested Fix

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”.

Details

Affected product:
Spring , alluxio , bookkeeper , camel , canal , druid , lyra , metrics , micrometer , pulsar , rabbitmq-java-client , zipkin-reporter-java
Affected packages:
amqp-client @ 5.9.0 (+5598 more)

Fixes