CVE-2026-63336: RabbitMQ Java client: TrustEverythingTrustManager used by default in useSslProtocol() enables MITM
Vulnerability Summary
com.rabbitmq.client.TrustEverythingTrustManager accepts ANY TLS certificate (including null chains) and is used as the default trust manager when calling ConnectionFactory.useSslProtocol() without arguments. Combined with hostname verification being disabled by default, this enables trivial man-in-the-middle attacks.
Affected Components
- com.rabbitmq.client.TrustEverythingTrustManager — accepts any certificate - com.rabbitmq.client.ConnectionFactory.useSslProtocol() — uses TrustEverythingTrustManager - Hostname verification disabled by default (enableHostnameVerification() must be called explicitly) - com.rabbitmq.client.ConnectionFactory.getPassword() — returns plaintext with no redaction - Default port 5672 (plaintext) with PLAIN SASL — credentials sent unencrypted
POC (Verified on Java 21, amqp-client 5.25.0)
java // TrustEverythingTrustManager accepts ANY certificate including null TrustEverythingTrustManager tm = new TrustEverythingTrustManager(); tm.checkServerTrusted(null, "RSA"); // No exception — accepts null cert chain tm.getAcceptedIssuers(); // Returns empty array — trusts all CAs
// ConnectionFactory defaults ConnectionFactory factory = new ConnectionFactory(); factory.useSslProtocol(); // Uses TrustEverythingTrustManager internally // enableHostnameVerification() NOT called by default
// Credential exposure factory.setPassword("secretpassword123"); factory.getPassword(); // Returns "secretpassword123" — no redaction
// Default plaintext port factory.getPort(); // 5672 (plaintext, not 5671/TLS)
// PLAIN SASL sends cleartext credentials PlainMechanism pm = new PlainMechanism(); // handleChallenge() sends username+password in cleartext
Attack Scenarios
1. MITM: Attacker presents self-signed cert → TrustEverythingTrustManager accepts it → all RabbitMQ traffic intercepted 2. Credential theft: Default plaintext port (5672) + PLAIN SASL = credentials readable on network 3. DNS rebinding: No hostname verification → attacker DNS record → MITM without cert 4. Logging exposure: getPassword() returns plaintext → credentials in logs/stack traces
Suggested Fix 1. Deprecate TrustEverythingTrustManager — it should never be used in production 2. useSslProtocol() should use the JVM default trust store, not TrustEverything 3. Enable hostname verification by default 4. Redact password in getPassword() or remove the public getter 5. Warn when using PLAIN SASL without TLS
Other sources
The RabbitMQ Java client library allows Java and JVM-based applications to connect to and interact with RabbitMQ nodes. Prior to 5.33.0, com.rabbitmq.client.ConnectionFactory.useSslProtocol() and ConnectionFactory.useSslProtocol(String) configure com.rabbitmq.client.TrustEverythingTrustManager and leave hostname verification disabled, causing arbitrary server certificates, including self-signed certificates, to be accepted. A network attacker able to intercept a TLS connection can impersonate the RabbitMQ broker, read protected AMQP traffic, and modify traffic without certificate or hostname validation. The fix changes the production TLS helpers to use the JVM default trust store and enables hostname verification, while retaining an explicitly named development-only no-verification helper. This issue is fixed in version 5.33.0.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
maven/com.rabbitmq:amqp-clientto a version that resolves this vulnerability.Fixed in 5.33.0 - Upgrade
Upgrade
com.rabbitmq.client (RabbitMQ Java client)to a version that resolves this vulnerability.Fixed in 5.33.0 - Configuration
Upgrade to v5.33.0 where production TLS helpers stop using com.rabbitmq.client.TrustEverythingTrustManager when calling ConnectionFactory.useSslProtocol() (and ConnectionFactory.useSslProtocol(String)) and instead use the JVM default trust store.
com.rabbitmq.client.ConnectionFactory (TLS) useSslProtocol() = use JVM default trust store (no TrustEverythingTrustManager) - Configuration
Ensure ConnectionFactory.enableHostnameVerification() is called (hostname verification was disabled by default unless explicitly enabled).
com.rabbitmq.client.ConnectionFactory (TLS) enableHostnameVerification() = enabled - Configuration
Do not use the default plaintext port 5672 with PLAIN SASL; configure the broker/client connection to use TLS rather than port 5672.
com.rabbitmq.client.ConnectionFactory (SASL/credentials transport) port = not 5672 (use TLS port) - Configuration
Move to the v5.33.0 fix that redacts com.rabbitmq.client.ConnectionFactory.getPassword() outputs (or removes the public getter) to prevent plaintext credentials appearing in logs/stack traces.
com.rabbitmq.client.ConnectionFactory getPassword() = redacted
Event History
Frequently Asked Questions
Which applications are exposed?
Applications using RabbitMQ Java client versions before 5.33.0 that call ConnectionFactory.useSslProtocol() or ConnectionFactory.useSslProtocol(String) are affected. These helpers configured certificate trust without validation and left hostname verification disabled.
What access does an attacker need to exploit this issue?
An attacker must be able to intercept the application's TLS connection to the RabbitMQ broker. Under that condition, they can present an arbitrary or self-signed certificate, impersonate the broker, and read or modify AMQP traffic.
What is the remediation?
Upgrade the RabbitMQ Java client to version 5.33.0, where the production TLS helpers use the JVM default trust store and enable hostname verification. The retained no-verification helper is explicitly intended for development only.