CVE-2026-69220

Overview

The RabbitMQ Java Client is the RabbitMQ team's AMQP 0.9.1 client library, which allows Java and JVM-based applications to connect to and interact with RabbitMQ nodes. It is published to Maven Central as com.rabbitmq:amqp-client, and Spring AMQP applications, including Spring Boot ones, use it through spring-rabbit's CachingConnectionFactory.

A denial of service vulnerability (CVE-2026-69220) has been identified in the RabbitMQ Java Client's AMQP field table parser, which allows attackers to crash the client's connection I/O thread with a StackOverflowError by sending deeply nested tables or arrays. A malicious server, or an attacker positioned on the network path, can do this before authentication, because the connection.start frame is the first frame the server sends.

Per OWASP: The Denial of Service (DoS) attack is focused on making a resource (site, application, server) unavailable for the purpose it was designed. There are many ways to make a service unavailable for legitimate users by manipulating network packets, programming, logical, or resources handling vulnerabilities, among others.

This issue affects RabbitMQ Java Client versions prior to 5.33.1.

Details

Module Info

• Product: RabbitMQ Java Client
• Affected packages: com.rabbitmq:amqp-client
• Affected versions: <5.33.1
• GitHub repository: https://github.com/rabbitmq/rabbitmq-java-client
• Published packages: https://central.sonatype.com/artifact/com.rabbitmq/amqp-client
• Package manager: Maven
• Fixed in:
  • OSS RabbitMQ Java Client 5.33.1
  • NES for RabbitMQ Java Client v5.24.2

Vulnerability Info

This High-severity vulnerability is found in the com.rabbitmq:amqp-client package in RabbitMQ Java Client versions prior to 5.33.1.

AMQP 0.9.1 field tables and field arrays can contain values of any field type, including further tables (type F) and arrays (type A). The client decodes them in com.rabbitmq.client.impl.ValueReader, where readTable and readArray call readFieldValue for each entry, and readFieldValue calls back into readTable or readArray for nested values. Nothing tracks or limits how deep this recursion goes:

private static Map<String, Object> readTable(DataInputStream in)
    throws IOException
{
    long tableLength = unsignedExtend(in.readInt());
    if (tableLength == 0) return Collections.emptyMap();

    Map<String, Object> table = new HashMap<String, Object>();
    DataInputStream tableIn = new DataInputStream
        (new TruncatedInputStream(in, tableLength));
    while(tableIn.available() > 0) {
        String name = readShortstr(tableIn);
        Object value = readFieldValue(tableIn);
        if(!table.containsKey(name))
            table.put(name, value);
    }
    return table;
}

static Object readFieldValue(DataInputStream in)
    throws IOException {
    Object value = null;
    switch(in.readUnsignedByte()) {
      // ...
      case 'F':
          value = readTable(in);
          break;
      case 'A':
          value = readArray(in);
          break;
      // ...
    }
    return value;
}

private static List<Object> readArray(DataInputStream in)
    throws IOException
{
    long length = unsignedExtend(in.readInt());
    DataInputStream arrayIn = new DataInputStream
        (new TruncatedInputStream(in, length));
    List<Object> array = new ArrayList<Object>();
    while(arrayIn.available() > 0) {
        Object value = readFieldValue(arrayIn);
        array.add(value);
    }
    return array;
}

Each nesting level costs only about 7 bytes on the wire (a 4-byte table length, a 1-byte key length, a 1-byte key and a 1-byte type tag), so a frame of only a few kilobytes can describe several hundred levels of nested tables. Decoding such a frame exhausts the thread stack and throws a StackOverflowError, which ends the I/O loop that reads frames for the connection (by default, its dedicated I/O thread) and shuts the connection down. The server properties table in connection.start is decoded this way before the client authenticates, so any AMQP peer the client connects to, or an attacker who can tamper with an unencrypted connection, can trigger the crash.

Mitigation

The RabbitMQ team lists the AMQP 0.9.1 Java Client 5.x series as currently supported and ships fixes in new 5.x releases. Upstream has made no 5.24.x release since 5.24.0 (December 2024), so no 5.24.x release is available to address this issue. For more information, see here.

Users of the affected components should apply one of the following mitigations:

• Upgrade affected applications to a release of the RabbitMQ Java Client 5.x series that contains the fix.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

Credits

• Henry Wynn (finder)