Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐍
🐍 PyPI
Not in CISA KEV
HIGH severity

CVE-2026-44393 — oslo-messaging

HIGH

CVE-2026-44393 is a high-severity (CVSS 7.4) CWE-297 vulnerability in oslo-messaging. No vendor fix is recorded yet; mitigation options are listed below.

OpenStack oslo.messaging does not verify RabbitMQ broker hostname during TLS handshake

Also known asPYSEC-2026-3492
Published
Jun 4, 2026
Updated
Jul 29, 2026
Affected
1 pkg
Patched
None yet
Exploits
None indexed
Exploitation data as of Sep 27, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

  • CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-44393.

EPSS Exploitation Probability

via FIRST.org ↗
0.3%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs18th percentile — riskier than 18% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

CVE-2026-44393 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 379,842 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

1 pkg affected
🐍oslo-messaging

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.

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.

Affected Packages

1 total
EcosystemPackageVulnerable rangeFix
🐍PyPIoslo-messaging≥ 1.0.0No fix

Detection & mitigation playbook

Open-source dependency

  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for oslo-messaging, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Remediation status

    No patched version of oslo-messaging has shipped for CVE-2026-44393 yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.

  3. Mitigate without a patch

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Fixing This On Your OS

If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.

Red HatImportant

This Important flaw in OpenStack oslo.messaging impacts Red Hat OpenStack Platform and OpenShift Container Platform when using RabbitMQ with TLS. The vulnerability arises from the RabbitMQ driver's failure to perform proper hostname verification during TLS connection establishment. This oversight enables an attacker…

Workaround published by Red Hat
To mitigate the risk of man-in-the-middle attacks, restrict network access to the RabbitMQ message broker. Configure 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 the exposure to attackers attempting to intercept and impersonate the broker.
Source: Red Hat security advisory for CVE-2026-44393 (CC BY 4.0)
ProductFixed inAdvisory
Red Hat OpenStack Platform 16.2python-oslo-messaging-0:10.2.4-2.20260710155333.82281a0.el8ostRHSA-2026:54757

Frequently Asked Questions

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
O3 Security · Impact-Aware SCA

Is CVE-2026-44393 in your dependencies?

Find it across PyPI, including transitive dependencies.

Scan my dependencies How O3 SCA works