The oslo.messaging RabbitMQ driver, in OpenStack versions 1.0.0 through 17.3.0, fails to perform hostname verification when establishing a TLS connection with a RabbitMQ broker. When a CA file is supplied, the driver validates the certificate chain but does not send the expected broker hostname to the TLS stack; as a result, any certificate signed by the deployment CA is accepted regardless of hostname. This flaw permits an attacker who can intercept control‑plane traffic to impersonate the RabbitMQ broker, read, alter or drop RPC and notification traffic between OpenStack services. The weakness mirrors insecure acceptance of any deployment‑CA‑signed certificate (CWE‑295) and represents a TLS hostname verification failure (CWE‑297).

All OpenStack deployments that use oslo.messaging version 1.0.0 through 17.3.0 with RabbitMQ over TLS. This includes any OpenStack service that relies on oslo.messaging for inter‑service communication via MQTT, such as Nova, Neutron, Swift, and others that connect to a RabbitMQ broker over an encrypted channel.

The risk is high because the vulnerability enables a full man‑in‑the‑middle attack on critical control‑plane traffic, with a CVSS score of 7.4. The EPSS score is < 1%, indicating a very low but nonzero exploitation probability, and the vulnerability is not listed in the CISA KEV catalog, so the exact exploitation probability is still low. The likely attack vector is an attacker who can intercept OpenStack control‑plane traffic, such as a compromised network device or insider with network privileges. Exploitation requires the attacker to present a certificate signed by the same deployment CA; under those conditions the driver will accept the connection, allowing the attacker to forward or tamper with messages.