The RabbitMQ Java client library, before version 5.33.0, configures a TrustEverythingTrustManager when useSslProtocol() (or its String variant) is called. The trust manager accepts any server certificate and hostname verification is disabled, effectively allowing an attacker to present a forged or self‑signed certificate and have it trusted by the client. An adversary who can intercept the TLS connection between the application and the RabbitMQ broker could therefore impersonate the broker, read all AMQP traffic, and modify or inject messages with full confidence that the client will accept the manipulated connection.

Affects the rabbitmq‑java‑client library in all releases prior to 5.33.0. The fix resides in version 5.33.0 and later, where the production TLS helpers use the JVM default trust store and enable hostname verification, leaving a separate development‑only no‑verification helper for use in non‑production settings.

The CVSS score of 5.1 indicates moderate severity. No EPSS data is available, and the vulnerability is not listed in the CISA KEV catalog. The likely attack vector requires an attacker to position themselves on the network path between the client and broker, such as through a compromised router, virtual switch, or via ARP spoofing. Once in position, the attacker can use a man‑in‑the‑middle attack without needing a valid certificate, enabling full read or tampering of AMQP traffic. While the score reflects moderate risk, the potential confidentiality and integrity impact on application data can be significant if sensitive messages are transmitted.