A TLS hostname verification vulnerability in OpenStack’s oslo.messaging library, tracked as CVE-2026-44393, allows an attacker who can intercept control-plane traffic to impersonate the RabbitMQ message broker and perform man-in-the-middle attacks on RPC and notification traffic across all OpenStack services. The vulnerability carries a CVSS score of 7.4 and affects oslo.messaging versions 1.0.0 through 17.3.0.
What Is the Vulnerability?
CVE-2026-44393 is a TLS hostname verification bypass in the oslo.messaging RabbitMQ driver. oslo.messaging is the standard messaging library used by all OpenStack services — Nova (compute), Neutron (networking), Cinder (block storage), Keystone (identity), Glance (images), and every other core OpenStack component — to communicate via Remote Procedure Calls (RPC) and notifications over RabbitMQ.
When TLS is configured for RabbitMQ communication and the ssl_ca_file option is set, the driver correctly enables certificate chain validation — it verifies that the broker’s certificate is signed by the configured Certificate Authority. However, it does not pass the expected broker hostname into the underlying TLS stack. This means any certificate signed by the deployment CA is accepted regardless of the hostname it was issued for. An attacker who can intercept control-plane traffic — for example, through ARP spoofing on the management network, a compromised network device, or a misconfigured network path — can present any validly-signed certificate and successfully impersonate the RabbitMQ broker.
The practical impact is a man-in-the-middle attack on all inter-service OpenStack communication. The attacker can read, modify, or inject RPC messages between OpenStack services — potentially manipulating VM lifecycle operations, network configurations, authentication decisions, and data transfers. In an OpenStack cloud, the message bus is the central nervous system — compromising it compromises the entire cloud.
The vulnerability is classified under CWE-297 (Improper Validation of Certificate with Host Mismatch):
- CVSS v3.1 Score: 7.4 (High)
- Attack Vector: Network (AV:N)
- Attack Complexity: High (AC:H) — requires ability to intercept control-plane traffic
- Privileges Required: None (PR:N)
- User Interaction: None (UI:N)
- Impact: High on confidentiality and integrity (C:H/I:H/A:N)
Which Versions Are Affected?
The vulnerability affects all versions of OpenStack oslo.messaging from the initial release through 17.3.0:
- OpenStack oslo.messaging: versions 1.0.0 through 17.3.0 (inclusive)
All OpenStack deployments using oslo.messaging with RabbitMQ over TLS are affected. This includes virtually every production OpenStack deployment that has configured TLS for message bus communication — which is a standard security practice for production clouds.
Is It Being Exploited in the Wild?
No active exploitation has been publicly reported. However, the vulnerability was published on June 4, 2026 with full technical details, and the exploit path — intercept control-plane traffic, present a validly-signed certificate, impersonate the broker — is well-understood by attackers targeting cloud infrastructure. The attack requires network-level access to the OpenStack management network, which elevates the attack complexity but is within the capabilities of sophisticated adversaries who have gained a foothold in the data centre network. OpenStack deployments in telecom, government, financial services, and large enterprise private clouds should patch proactively.
What Is the Fix?
The vulnerability is tracked in the OpenStack bug tracker. The fix adds proper TLS hostname verification to the RabbitMQ driver. Deployments should:
- Upgrade oslo.messaging to a version that includes the fix for CVE-2026-44393
- Verify that the RabbitMQ broker hostname is correctly configured and matches the certificate’s Subject Alternative Name (SAN) or Common Name (CN)
- After upgrading, validate TLS connectivity by checking OpenStack service logs for certificate verification errors — services should fail to connect if the broker certificate does not match the expected hostname, which is the correct behaviour after the fix
The bug report is available at: https://bugs.launchpad.net/oslo.messaging/+bug/2150316
Recommendations
Upgrade oslo.messaging and verify TLS hostname validation. After upgrading, test that services reject connections to brokers with mismatched certificates — this confirms the fix is working. If services continue to accept mismatched certificates, the configuration may need adjustment to pass the correct broker hostname.
Audit your OpenStack management network segmentation. This vulnerability requires the attacker to intercept control-plane traffic. Ensure the OpenStack management network is properly segmented from tenant networks, internet-facing interfaces, and general corporate networks. The management network should be a dedicated, isolated VLAN or physical network accessible only to OpenStack infrastructure components and authorised administrators.
Verify RabbitMQ TLS configuration across all OpenStack services. Every OpenStack service that uses oslo.messaging — Nova, Neutron, Cinder, Keystone, Glance, Heat, ceilometer, and others — needs the updated library. In containerised OpenStack deployments (Kolla, OpenStack-Helm, TripleO), ensure the updated oslo.messaging package is included in all service container images.
Monitor for unexpected RabbitMQ connections. After patching, review RabbitMQ connection logs and management UI for connections from unrecognised IP addresses or unexpected client certificates. An attacker who previously established a MITM position may leave artifacts in connection patterns, certificate usage, or message queue activity.
References
- OpenStack Bug Report — oslo.messaging TLS Hostname Verification
- NVD: CVE-2026-44393
- Vulnerability Intelligence Report — June 4, 2026
This advisory is covered in the broader Vulnerability Intelligence Report — June 4, 2026. For a comprehensive view of all active threats and newly disclosed vulnerabilities, refer to the full report.
