Cpe:2.3:a:rabbitmq:amqp-Client:*:*:*:*:*:*:*:* - CraftedSignal Threat Feedhttps://feed.craftedsignal.io/cpes/cpe2.3arabbitmqamqp-client/Trending threats, MITRE ATT&CK coverage, and detection metadata. Fed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioThu, 17 Sep 2026 19:14:52 +0000https://feed.craftedsignal.io/favicon-32x32.pngCraftedSignal Threat Feedhttps://feed.craftedsignal.io/3232https://feed.craftedsignal.io/favicon.svgRabbitMQ Java Client Out-of-Memory Vulnerability via Frame Negotiationhttps://feed.craftedsignal.io/briefs/2026-09-rabbitmq-frame-oom/Thu, 17 Sep 2026 19:14:52 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-09-rabbitmq-frame-oom/A logic error in the RabbitMQ Java client's frame size negotiation allows a malicious server to trigger a massive memory allocation and service crash by exploiting an integer comparison flaw in frame handling.The RabbitMQ Java client library (com.rabbitmq:amqp-client) is vulnerable to an Out-Of-Memory (OOM) denial-of-service condition due to a logic flaw in how it negotiates the maximum frame size (frameMax) with an AMQP server. When an AMQP server or an adversary in a Man-in-the-Middle (MITM) position sends a Connection.Tune handshake with frameMax=0 (signifying unlimited size per the AMQP specification), the client incorrectly executes Math.min(maxInboundMessageBodySize, 0). This operation results in a value of zero, which the internal Utils.framePayloadLimit function interprets as a request for Integer.MAX_VALUE. Consequently, the client's existing frame size protections are bypassed, and a single crafted frame with a large size field forces the JVM to attempt an allocation of approximately 2GB, causing the process to crash. This affects all clients using versions prior to 5.34.0.

Attack Chain

  1. Attacker initiates a connection to the RabbitMQ Java client as a malicious AMQP server.
  2. The client initiates the standard AMQP Connection.Tune handshake negotiation.
  3. The attacker sends a Connection.Tune response with the frameMax field set to 0.
  4. The client's AMQConnection logic incorrectly evaluates the limit as 0 instead of falling back to the configured maxInboundMessageBodySize.
  5. The client sets the effective frame payload limit to Integer.MAX_VALUE due to the misinterpretation of 0-means-unlimited.
  6. The attacker sends a frame (method, header, or body) with a manipulated size field set to a very large value (e.g., 0x1FFFFFFF).
  7. The client executes new byte[frameSize] inside Frame.readFrom() based on the attacker's supplied size.
  8. The JVM exhausts available heap memory, resulting in an OOM crash and denial of service for the client application.

Impact

Successful exploitation results in an immediate denial-of-service (DoS) condition on any application using the vulnerable RabbitMQ Java client. Because the crash occurs during frame processing, it is highly effective against any client connecting to a compromised or malicious AMQP broker. This impacts all sectors relying on RabbitMQ for messaging, particularly in Java-based microservices architectures where a single crashed node can disrupt downstream message processing.

Recommendation

Update the com.rabbitmq:amqp-client library to version 5.34.0 or later immediately to incorporate the corrected logic for frameMax negotiation. If patching is not immediately feasible, ensure that connections are only established to trusted brokers and inspect outbound traffic for anomalous Connection.Tune frames.

]]>mediumadvisoryvulnerabilitydenial-of-servicejavarabbitmq