What is the CVSS score of EUVD-2026-34294?

EUVD-2026-34294 has a CVSS 3.1 base score of 7.4 (High). CVSS vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N. EPSS exploitation probability: 0.0%.

Which versions of OpenStack oslo.messaging are affected by EUVD-2026-34294?

OpenStack oslo.messaging versions 1.0.0 through 17.3.0 contain a TLS verification flaw enabling attackers positioned on control-plane networks to intercept and modify inter-service communications.. A patch is available.

How to fix or mitigate EUVD-2026-34294?

Within 24 hours: Identify all OpenStack deployments running oslo.messaging versions 1.0.0-17.3.0 and assess control-plane network exposure. Within 7 days: Implement network segmentation and firewall rules restricting control-plane access to RabbitMQ brokers; review and strengthen broker authentication mechanisms; enable additional TLS verification controls if available. Within 30 days: Monitor vendor advisories for patch releases; evaluate alternative messaging solutions; document and test upgrade procedures for when a patch becomes available.

OpenStack oslo.messaging EUVD-2026-34294

| CVE-2026-44393 HIGH

Improper Validation of Certificate with Host Mismatch (CWE-297)

2026-06-04 mitre

GHSA-76qh-xr7q-h39m

Information Disclosure N A

7.4

CVSS 3.1 · Vendor: mitre

Severity by source

Vendor (mitre) PRIMARY

7.4 HIGH

AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

SUSE

HIGH

qualitative

Red Hat

7.4 HIGH

qualitative

Primary rating from Vendor (mitre).

CVSS VectorVendor: mitre

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

Attack Vector

Network

Attack Complexity

High

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

None

Lifecycle Timeline

Analysis Generated

Jun 04, 2026 - 18:22 vuln.today

CVSS changed

Jun 04, 2026 - 18:22 NVD

7.4 (HIGH)

CVE Published

Jun 04, 2026 - 00:00 nvd

UNKNOWN (no severity yet)

DescriptionCVE.org

An issue was discovered in OpenStack oslo.messaging 1.0.0 through 17.3.0. The oslo.messaging RabbitMQ driver does not perform TLS hostname verification when connecting to the message broker. When ssl_ca_file is configured, the driver enables certificate chain validation but does not pass the expected broker hostname into the underlying TLS stack. Any certificate signed by the deployment CA is accepted regardless of hostname, allowing an attacker who can intercept control-plane traffic to impersonate the RabbitMQ broker and perform a man-in-the-middle attack on RPC and notification traffic. All OpenStack services using oslo.messaging with RabbitMQ over TLS are affected.

AnalysisAI

Man-in-the-middle attack against OpenStack oslo.messaging 1.0.0 through 17.3.0 is possible because the RabbitMQ driver validates the certificate chain but skips TLS hostname verification, letting any cert signed by the deployment CA impersonate the broker. An attacker positioned on the control-plane network can intercept and tamper with RPC and notification traffic between OpenStack services, with no public exploit identified at time of analysis but a credible POC pathway documented in OSSN-0096.

Technical ContextAI

oslo.messaging is the RPC and notification abstraction library underpinning nearly every OpenStack service (Nova, Neutron, Cinder, Keystone notifications, etc.) when RabbitMQ is the messaging backend. The bug is a classic CWE-297 (Improper Validation of Certificate with Host Mismatch): when ssl_ca_file is set, the Python SSL context performs chain validation but the broker hostname is never passed to the TLS handshake (server_hostname / check_hostname is not enforced), so SNI-bound name checks are bypassed. Any certificate issued by the same internal CA - including one issued for an unrelated host or a compromised low-trust service - is accepted as a valid broker identity, collapsing the trust model to 'signed by our CA' rather than 'is the broker we expect.'

RemediationAI

No vendor-released patch identified at time of analysis from the provided references - both links point to the Launchpad bug report and OSSN-0096 rather than a tagged oslo.messaging release, so operators should monitor those pages for the fixed version and upgrade once published (the fix will set server_hostname on the SSL wrap and enable hostname verification). As a compensating control, restrict the control-plane network so only OpenStack hosts and the RabbitMQ cluster can reach the AMQP TLS port (typically 5671), which removes the on-path prerequisite at the cost of stricter network segmentation; alternatively, issue RabbitMQ broker certificates from a dedicated CA used for nothing else and rotate any existing broker certs, which limits abusable certs to a much smaller pool but requires PKI changes. Mutual TLS (client cert auth) on the RabbitMQ listener further raises the bar but requires distributing client certificates to every oslo.messaging consumer.