CVE-2026-63336: RabbitMQ Java client: TrustEverythingTrustManager used by default in useSslProtocol() enables MITM

Published Aug 18, 2026
·
Updated

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

2 affected componentsFixes available
RabbitMQ RabbitMQ Java client<5.33.0
maven/com.rabbitmq:amqp-client<5.33.0
5.33.0

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade maven/com.rabbitmq:amqp-client to a version that resolves this vulnerability.

    Fixed in 5.33.0
  2. Upgrade

    Upgrade com.rabbitmq.client (RabbitMQ Java client) to a version that resolves this vulnerability.

    Fixed in 5.33.0
  3. 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)
  4. Configuration

    Ensure ConnectionFactory.enableHostnameVerification() is called (hostname verification was disabled by default unless explicitly enabled).

    com.rabbitmq.client.ConnectionFactory (TLS) enableHostnameVerification() = enabled
  5. 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)
  6. 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

Aug 18, 2026
CVE Published
via MITRE·04:29 PM
Data Sourced
via MITRE·04:29 PM
DescriptionWeakness
Advisory Published
via GitHub·04:32 PM
Data Sourced
via GitHub·04:32 PM
DescriptionWeaknessAffected Software

Frequently Asked Questions

1

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.

2

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.

3

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.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203