Loading vulnerability…
Missing TLS hostname verification in Spring Boot RabbitMQ SSL-bundle auto-configuration
CVE-2026-40971 affects Spring Boot 4.0.0–4.0.5 and 3.5.0–3.5.13. When RabbitMQ auto-configuration uses an SSL bundle, it does not perform TLS hostname verification when connecting to the broker. Consequently, a broker certificate is not checked against the intended server hostname, allowing an attacker capable of intercepting or redirecting the connection to impersonate the broker if the remaining TLS certificate checks succeed.
What it means and what to do now: patch path, interim mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
Missing hostname verification undermines RabbitMQ broker authentication and can enable man-in-the-middle attacks. Successful broker impersonation could expose application messages and broker credentials transmitted over the connection, or permit manipulation of messaging traffic. The vulnerability does not establish that certificate-chain validation is disabled or that arbitrary self-signed certificates are accepted.
If you can’t patch tonight, do this now.
No vendor-provided workaround is identified. Until patched, restrict network paths to trusted RabbitMQ brokers and independently enforce broker certificate hostname verification where feasible. Network restrictions are compensating controls, not a replacement for restoring hostname verification.
Patch, then assume compromise.
Upgrade Spring Boot to version 4.0.6 or later in the 4.0.x branch, or 3.5.14 or later in the 3.5.x branch. For affected VMware Tanzu Data Flow on Kubernetes deployments, upgrade to release 2.1.1, which incorporates the fix.
No public exploits tracked yet. Mallory keeps watching.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
6 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.