CVE-2026-106122

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-106122) has been identified in the RabbitMQ Java Client's decoding of AMQP short string properties, which allows attackers who can publish a message to an RPC request queue to permanently disable the consumers that serve it. A single message carrying malformed UTF-8 in a property such as correlation-id is requeued after every failure and disables each replacement consumer until an operator purges the queue.

Per OWASP: The Denial of Service (DoS) attack is focused on making a resource (site, application, server) unavailable for the purpose it was designed.

This issue affects all versions of the RabbitMQ Java Client prior to 5.36.0.

Details

Module Info

• Product: RabbitMQ Java Client
• Affected packages: com.rabbitmq:amqp-client
• Affected versions: <5.36.0
• 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.36.0
  • NES for RabbitMQ Java Client v5.24.2

Vulnerability Info

This Medium-severity vulnerability is found in the com.rabbitmq:amqp-client package in all versions of the RabbitMQ Java Client prior to 5.36.0.

AMQP short string (shortstr) properties such as correlation-id, reply-to, message-id, type and app-id are limited to 255 bytes on the wire. When the client reads one, ValueReader.readShortstr decodes the raw bytes as UTF-8 without checking that they are well formed:

private static String readShortstr(DataInputStream in)
    throws IOException
{
    byte [] b = new byte[in.readUnsignedByte()];
    in.readFully(b);
    return new String(b, "utf-8");
}

Java silently replaces each malformed byte with the U+FFFD replacement character, which takes 3 bytes when encoded as UTF-8 again. A 255-byte property made of invalid bytes therefore decodes to a string that re-encodes to 765 bytes. When the application echoes that value into a reply, as the AMQP RPC pattern does with correlation-id and reply-to, ValueWriter.writeShortstr rejects it with an unchecked exception:

public final void writeShortstr(String str)
    throws IOException
{
    byte [] bytes = str.getBytes("utf-8");
    int length = bytes.length;
    if (length > 255) {
        throw new IllegalArgumentException(
                "Short string too long; utf-8 encoded length = " + length +
                ", max = 255.");
    }
    out.writeByte(bytes.length);
    out.write(bytes);
}

In RpcServer.mainloop(), the reply is published inside processRequest, before the delivery is acknowledged, and the loop handles only InterruptedException and ShutdownSignalException:

while (_mainloopRunning) {
    Delivery request;
    try {
        request = _consumer.nextDelivery();
    } catch (InterruptedException ie) {
        Thread.currentThread().interrupt();
        _mainloopRunning = false;
        continue;
    }
    processRequest(request);
    _channel.basicAck(request.getEnvelope().getDeliveryTag(), false);
}

The IllegalArgumentException escapes the loop and ends the RPC server thread without acknowledging the message. Consumers written in the documented tutorial style, which echo the correlation-id from a DeliverCallback before calling basicAck, fail the same way and have their channel closed. In both cases the broker requeues the unacknowledged message and delivers it to the next consumer, which fails in turn, so automatic recovery or restarting the service does not restore it while the message remains in the queue.

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

• Ali (finder)