CVE-2026-75516

The RabbitMQ Java client library (amqp-client) before 5.34.0 fails to enforce the configured maxInboundMessageBodySize cap when the AMQP frame_max negotiated during Connection.Tune is zero (unlimited), which is also the client default, because zero is later interpreted as Integer.MAX_VALUE (CWE-770, allocation of resources without limits). A malicious AMQP server, or a man-in-the-middle able to alter Connection.Tune and inject frames into the connection, can send oversized frames of any type, which Frame.readFrom() allocates into memory before any content-level validation. This allows the attacker to exhaust heap memory and terminate the client JVM process, yielding a high-availability-impact denial of service with no confidentiality or integrity impact (CVSS 4.0 8.7). Any Java or JVM application using the vulnerable client against untrusted AMQP endpoints, or over connections not protected by TLS, is affected, while clients talking to legitimate RabbitMQ brokers over TLS are largely not exposed. There is currently no sign of exploitation: the flaw is not in CISA KEV and no public proof-of-concept is known.

What to do: Upgrade amqp-client to 5.34.0 or later and audit dependency trees (e.g., mvn dependency:tree | grep amqp-client) since it is commonly a transitive dependency of spring-boot-starter-amqp. Until patched, connect only to trusted AMQP servers and enforce TLS, which eliminates the man-in-the-middle attack path. Treat unexplained memory-exhaustion crashes in client applications as a possible exploitation indicator.