The oslo.messaging RabbitMQ driver, in OpenStack versions 1.0.0 through 17.3.0, fails to perform hostname verification when a TLS connection is established with a RabbitMQ broker. When a CA file is supplied, the driver validates the certificate chain but does not provide the expected broker hostname to the TLS stack, so 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, thereby gaining the ability to read, alter or drop RPC and notification traffic between OpenStack services, and the weakness aligns with the missing TLS hostname validation (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 not reported, and the vulnerability is not listed in the CISA KEV catalog, so the exact exploitation probability is unknown. 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.