CVE-2026-63336: RabbitMQ Java Client TLS Vulnerability

CVE-2026-63336 Overview

CVE-2026-63336 is an improper certificate validation vulnerability [CWE-295] in the RabbitMQ Java client library. Versions prior to 5.33.0 expose ConnectionFactory.useSslProtocol() and ConnectionFactory.useSslProtocol(String) helpers that configure a TrustEverythingTrustManager and leave hostname verification disabled. The client accepts arbitrary server certificates, including self-signed ones, during TLS negotiation with a RabbitMQ broker. A network attacker able to intercept the TLS connection can impersonate the broker, read protected Advanced Message Queuing Protocol (AMQP) traffic, and modify messages in transit. The issue is fixed in version 5.33.0.

Critical Impact
Applications using the vulnerable TLS helpers accept any certificate presented by a broker, enabling man-in-the-middle interception and modification of AMQP traffic.

Affected Products

RabbitMQ Java client library (com.rabbitmq:amqp-client) prior to 5.33.0
Java and JVM-based applications using ConnectionFactory.useSslProtocol() for TLS setup
Applications relying on ConnectionFactoryConfigurator with default TLS configuration

Discovery Timeline

2026-08-18 - CVE-2026-63336 published to NVD
2026-08-18 - Last updated in NVD database

Technical Details for CVE-2026-63336

Vulnerability Analysis

The RabbitMQ Java client historically shipped two convenience TLS helpers intended to simplify getting started with encrypted broker connections. Both helpers install com.rabbitmq.client.TrustEverythingTrustManager, which accepts every X.509 certificate chain presented by the peer without validation. Neither helper enables hostname verification on the underlying SSLEngine. The result is a TLS session that is encrypted but not authenticated. Any attacker positioned on the network path between the client and broker can terminate the client's TLS handshake with a self-signed certificate. Once the impersonation succeeds, the attacker reads AMQP frames in cleartext relative to the client and can drop, replay, or modify messages before forwarding them to the real broker.

Root Cause

The root cause is insecure-by-default TLS configuration in a helper API. useSslProtocol() and useSslProtocol(String) were designed for local development but were widely used in production because their names implied production-safe TLS. The fix reworks the helper contract so the production path uses the JVM default trust store and enables hostname verification, while an explicitly named useTlsWithNoVerification() helper is retained for development.

Attack Vector

Exploitation requires an on-path or adjacent-network position between the Java client and the RabbitMQ broker, such as a compromised router, malicious Wi-Fi, or a hostile cloud tenant sharing the broker's network segment. The attacker presents any TLS certificate for the broker's hostname or IP. The vulnerable client completes the handshake and begins sending AMQP credentials and message payloads to the attacker.

java

            useDefaultTrustStore(cf, sslAlgorithm, verifyHostname);
        } else {
            if (sslAlgorithm == null) {
-                cf.useSslProtocol();
+                cf.useTlsWithNoVerification();
            } else {
-                cf.useSslProtocol(sslAlgorithm);
+                ConnectionFactory.logTlsNoVerificationWarning();
+                cf.useSslProtocol(sslAlgorithm, new TrustEverythingTrustManager());
            }
        }
    }
// Source: https://github.com/rabbitmq/rabbitmq-java-client/commit/1e7deb2e6020c9793a81385a53ea378ec63b9339

The patch renames the insecure path to useTlsWithNoVerification() and emits a warning log so operators can identify unsafe configurations. See the GitHub Security Advisory GHSA-5m9f-rphj-c435 for full disclosure details.

Detection Methods for CVE-2026-63336

Indicators of Compromise

Unexpected TLS certificate fingerprints observed on connections to RabbitMQ brokers on port 5671.
Application logs referencing TrustEverythingTrustManager or the new logTlsNoVerificationWarning message after upgrade.
AMQP authentication events originating from unexpected source addresses or geographies.

Detection Strategies

Statically scan Java codebases and dependency graphs for amqp-client versions earlier than 5.33.0 and for direct calls to useSslProtocol() or useSslProtocol(String).
Inspect packaged artifacts (JAR, WAR, uber-JARs) for the vulnerable ConnectionFactory class signatures and constructor patterns.
Perform TLS inventory on outbound AMQP connections to confirm each client validates the broker's certificate chain against a known trust store.

Monitoring Recommendations

Alert on new or unrecognized certificate issuers presented on port 5671 in network flow telemetry.
Monitor application logs for the RabbitMQ client's no-verification warning after upgrading to 5.33.0.
Track failed TLS handshakes following remediation; a spike may indicate previously-silent misconfigurations now enforcing validation.

How to Mitigate CVE-2026-63336

Immediate Actions Required

Upgrade the RabbitMQ Java client dependency to version 5.33.0 or later across all applications and build pipelines.
Audit application code for calls to ConnectionFactory.useSslProtocol() and ConnectionFactory.useSslProtocol(String) and replace them with the trust-store-backed helpers.
Rotate any AMQP credentials that may have been transmitted through connections vulnerable to interception.

Patch Information

The fix is available in GitHub Release v5.33.0 via commits 1e7deb2e and a4bf571d, delivered in Pull Request #1999 and Pull Request #2001. The production TLS helpers now use the JVM default trust store and enable hostname verification. A separate useTlsWithNoVerification() helper is retained for development scenarios only.

Workarounds

If immediate upgrade is not possible, configure TLS explicitly by passing an SSLContext initialized with a TrustManager bound to the corporate certificate authority.
Enable hostname verification by setting ConnectionFactory.enableHostnameVerification() on affected clients.
Restrict broker connectivity to trusted network segments and enforce mutual TLS (mTLS) between clients and brokers where feasible.

bash

# Update Maven coordinates to the patched release
# pom.xml
# <dependency>
#   <groupId>com.rabbitmq</groupId>
#   <artifactId>amqp-client</artifactId>
#   <version>5.33.0</version>
# </dependency>
mvn versions:use-dep-version -Dincludes=com.rabbitmq:amqp-client -DdepVersion=5.33.0 -DforceVersion=true