CVE-2026-63336

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.

An information exposure vulnerability (CVE-2026-63336) has been identified in the TLS helper methods of the RabbitMQ Java Client's ConnectionFactory, which allows attackers in a network position between the client and the broker to intercept and alter AMQP traffic over TLS connections. Connections set up through useSslProtocol() accept any server certificate for any hostname, so a man-in-the-middle can present its own certificate and read the client's credentials and messages.

Per OWASP: Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification, or destruction of all data or performing a business function outside the user's limits.

This issue affects RabbitMQ Java Client versions before 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 Medium-severity vulnerability is found in the com.rabbitmq:amqp-client package in RabbitMQ Java Client versions before 5.33.0. The convenience methods ConnectionFactory.useSslProtocol() and useSslProtocol(String) configure TLS with TrustEverythingTrustManager, a trust manager that performs no peer verification:

public void useSslProtocol(String protocol)
    throws NoSuchAlgorithmException, KeyManagementException
{
    useSslProtocol(protocol, new TrustEverythingTrustManager());
}

public void useSslProtocol(SSLContext context) {
    this.sslContextFactory = name -> context;
    setSocketFactory(context.getSocketFactory());
}

TrustEverythingTrustManager.checkServerTrusted returns without inspecting the certificate chain, so the client accepts any server certificate, including a self-signed one. useSslProtocol(SSLContext) and setSslContextFactory also leave server hostname verification off unless the application separately calls enableHostnameVerification(), so even a correctly configured trust store accepts a valid certificate issued for a different host.

These helpers are reached without an explicit call. ConnectionFactory.setUri() calls useSslProtocol() for any amqps:// URI when no SSL context factory has been set, and ConnectionFactoryConfigurator calls useSslProtocol(String) when TLS is enabled in properties-based configuration with no key store or trust store and without ssl.validate.server.certificate set to true. An attacker who can intercept traffic between the client and the broker, for example through DNS or ARP spoofing on a shared network, can complete the TLS handshake with their own certificate, read the username and password the client sends during authentication, and read or modify the messages exchanged on the connection.

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)