CVE-2026-63337

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 resource injection vulnerability (CVE-2026-63337) has been identified in the JSON-RPC support of the RabbitMQ Java Client, which allows attackers who can answer a JsonRpcClient's system.describe request to make the client load and initialize arbitrary classes from its classpath. The same attacker-chosen class name also becomes the type that later replies are parsed into, which can lead to type confusion when the client uses JacksonJsonRpcMapper.

Per OWASP: This vulnerability is caused by unsafe use of the reflection mechanisms in programming languages like Java or C#. An attacker may be able to create unexpected control flow paths through the application, potentially bypassing security checks. Exploitation of this weakness can result in a limited form of code injection.

This issue affects RabbitMQ Java Client versions prior to 5.33.0.

Details

Module Info

• Product: RabbitMQ Java Client
• Affected packages: com.rabbitmq:amqp-client
• Affected versions: <5.33.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.33.0
  • 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.0.

Every JsonRpcClient constructor calls the system.describe procedure over RabbitMQ and builds a ServiceDescription from the JSON reply. Each procedure in that reply becomes a ProcedureDescription, whose fields are filled reflectively with JSONUtil.tryFill(). Filling the javaReturnType field calls setJavaReturnType(), which resolves the class name taken from the reply:

public void setJavaReturnType(String javaReturnType) {
    this.javaReturnType = javaReturnType;
    this._javaReturnTypeAsClass = computeReturnTypeAsJavaClass();
}

private Class<?> computeReturnTypeAsJavaClass() {
    try {
        if ("int".equals(javaReturnType)) {
            return Integer.TYPE;
        // ... other primitive types ...
        } else {
            return Class.forName(javaReturnType);
        }
    } catch (ClassNotFoundException e) {
        throw new IllegalStateException("Unable to load class: " + javaReturnType, e);
    }
}

The single-argument Class.forName(String) initializes the class it loads, so the static initializers of any class the reply names, among those on the client's classpath, run in the client's JVM. Nothing checks the name against the service the client expects. The resolved class is then used as the target type for every later call to that procedure in JsonRpcClient.call():

ProcedureDescription proc = serviceDescription.getProcedure(method, params.length);
expectedType = proc.getReturnType();
// ...
JsonRpcMapper.JsonRpcResponse reply = mapper.parse(replyStr, expectedType);

The system.describe reply comes from whatever consumer answers the request on the broker, not from a trusted source. An attacker who can consume from the service's queue, such as another tenant on a shared broker, or who can tamper with the AMQP traffic, can therefore choose which classes the client initializes and, when the client uses JacksonJsonRpcMapper, which types the replies are deserialized into. The default DefaultJsonRpcMapper ignores the expected type.

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)