GHSA-5m9f-rphj-c435: Maven/com.rabbitmq:amqp-client vulnerability
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
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 - Configuration
Enable hostname verification by default (ensure ConnectionFactory.enableHostnameVerification() is called, since it is NOT called by default).
com.rabbitmq.client.ConnectionFactory Hostname verification = enabled - Configuration
Change ConnectionFactory.useSslProtocol() to use the JVM default trust store instead of TrustEverythingTrustManager (avoid useSslProtocol() behavior that installs TrustEverythingTrustManager when called without arguments).
com.rabbitmq.client.ConnectionFactory TLS trust manager for useSslProtocol() = JVM default trust store - Configuration
Remove/stop using TrustEverythingTrustManager (it accepts any certificate including null chains); use a proper trust manager that performs real certificate validation.
com.rabbitmq.client.TrustEverythingTrustManager Certificate validation behavior = do not accept any certificate - Configuration
Redact password in ConnectionFactory.getPassword() or remove the public getter so plaintext credentials are not emitted to logs/stack traces (the current getPassword() returns plaintext).
com.rabbitmq.client.ConnectionFactory Password handling (getPassword()) = redacted or removed public getter - Configuration
Warn when using PLAIN SASL without TLS (since default plaintext port 5672 with PLAIN SASL sends cleartext credentials).
com.rabbitmq.client.PlainMechanism / SASL PLAIN SASL usage without TLS = warn/avoid
Event History
Frequently Asked Questions
Which application configurations should be reviewed first?
Applications that call ConnectionFactory.useSslProtocol() with no arguments are exposed to certificate validation that accepts any certificate. Hostname verification is also off unless enableHostnameVerification() is explicitly called.
What attacker capability is required for exploitation?
A man-in-the-middle attacker able to intercept the TLS connection can exploit the combination of unrestricted certificate acceptance and disabled hostname verification. The advisory describes this as enabling trivial man-in-the-middle attacks.
How can we identify potentially affected deployments?
Review code for no-argument calls to useSslProtocol() and for the absence of an explicit enableHostnameVerification() call. Also identify connections using the default plaintext port 5672 with PLAIN SASL, where credentials are sent unencrypted.
What version has been confirmed vulnerable?
The supplied proof of concept was verified with Java 21 and amqp-client 5.25.0. No affected-version range or fixed version is provided in the available data.