Skip to main content
VulnerabilityPublished Updated

CVE-2026-44393: oslo-messaging · Improper Validation of Certificate with Host Mismatch

Affects oslo-messagingSource CVE Database V5

0

Not known to be exploited · CVSS 7.4 High.

Data as of 26 Oct 2026, 17:16 UTC

CVSS 3.1 base score
7.4High
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.1% chance of exploitation in 30 days – higher than 6% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 4 Jun 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Affected software

ProductAffectedFixed in
PyPIoslo-messagingpkg:pypi/oslo-messagingOther threatsAffected
  • =1.0.0
  • <=17.3.0
Fixed in–

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

AI-suggested

Meanwhile, to mitigate the risk of man-in-the-middle attacks, restrict network access to the RabbitMQ message broker by configuring firewall rules to permit inbound connections to the RabbitMQ port (typically 5672 or 5671 for AMQPS) only from authorized hosts and services within the control plane. This operational measure reduces exposure to attackers attempting to intercept and impersonate the broker.

Description

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.

References

Community reviews

Loading reviews…