RabbitMQ Java Client CVE-2026-63336

Exploitation requires two concurrent conditions: first, the target Java application must call ConnectionFactory.useSslProtocol() or ConnectionFactory.useSslProtocol(String) without subsequently invoking enableHostnameVerification() - this is the default and documented usage pattern in all versions prior to 5.33.0; second, the attacker must achieve a network-level MITM position between the Java client and the RabbitMQ broker via ARP spoofing, DNS manipulation, BGP hijack, or rogue network infrastructure. Applications that supply their own properly-configured SSLContext via useSslProtocol(SSLContext) with a real trust store and hostname verification are not affected. Applications not using TLS (default port 5672) face separate plaintext credential exposure but through a distinct mechanism outside this CVE's scope. The limiting factors are the prerequisite for network positioning and the requirement that TLS be configured via the insecure helper methods rather than a custom SSLContext.

The CVSS 4.0 score of 5.1 is significantly moderated by the AT:P prerequisite (attacker must achieve network interception positioning), but the SC:H rating accurately captures the real-world impact: all AMQP traffic, including authentication credentials, is exposed to the adversary. No EPSS data was provided in the available intelligence, limiting probabilistic exploitation forecasting. No CISA KEV listing is present, confirming no known active mass exploitation, though a verified proof-of-concept published in GHSA-5m9f-rphj-c435 demonstrates trivially successful exploitation once positioning is achieved. The practical risk is higher than the moderate score suggests for any deployment where developers called useSslProtocol() believing TLS provided authentication guarantees - a common and reasonable assumption - meaning the misconfiguration is silent and widespread across codebases. Even a mid-sized municipal IT team in olsztyn operating internal microservices over RabbitMQ should treat this as urgent if TLS was enabled via the affected API, given that PLAIN SASL credential theft is a direct consequence with no server-side indicator. The additional disclosure that getPassword() returns plaintext and default port 5672 uses cleartext PLAIN SASL compounds the credential exposure risk beyond the stated scope of the CVE.

A network attacker with an ARP-spoofing or DNS-poisoning foothold on the same segment as a Java application connecting to RabbitMQ presents a self-signed certificate during the TLS handshake. Because TrustEverythingTrustManager accepts any certificate without validation and hostname verification is disabled by default, the handshake succeeds transparently, and the attacker decrypts the full AMQP session - capturing credentials transmitted via PLAIN SASL and reading or injecting business messages in real time. A verified proof-of-concept confirming this behavior on Java 21 with amqp-client 5.25.0 is publicly documented in GHSA-5m9f-rphj-c435.