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: PyPI: oslo.messaging

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.

python3-oslo.messaging-doc-18.1.0-1.1 on GA media

Affected: PyPI: oslo-messaging

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.

golang: net/url: Memory exhaustion in query parameter parsing in net/url crypto/x509: golang: Denial of Service due to excessive resource consumption via crafted certificate openstack-keystone: OpenStack Keystone: Unauthorized access and privilege escalation via AWS signature validation flaw crypto/tls: crypto/tls: Incorrect certificate validation during TLS session resumption pyasn1: pyasn1: Denial of Service due to memory exhaustion from malformed RELATIVE-OID openstack-nova-compute: Arbitrary Host File Overwrite via Unconstrained qemu-img Format Handling in OpenStack Nova net/url: Incorrect parsing of IPv6 host literals in net/url crypto/x509: Incorrect enforcement of email constraints in crypto/x509 crypto/x509: golang: golang crypto/x509: Denial of Service via excessive processing of DNS SAN entries crypto/x509: crypto/tls: golang: Go: Denial of Service vulnerability in certificate chain building crypto/x509: golang: Go crypto/x509: Denial of Service via inefficient certificate chain validation golang: internal/syscall/unix: Root.Chmod can follow symlinks out of the root crypto/tls: golang: Go crypto/tls: Denial of Service via multiple TLS 1.3 key update messages google.golang.org/grpc/grpc-go: google.golang.org/grpc/authz: gRPC-Go: Authorization bypass due to improper HTTP/2 path validation etcd: etcd: Authorization bypass allows information disclosure and denial of service openstack-keystone: OpenStack Keystone: Privilege escalation through EC2 credential creation cry…

Affected: Ubuntu:16.04:LTS: python-oslo.messaging, Ubuntu:18.04:LTS: python-oslo.messaging, Ubuntu:20.04:LTS: python-oslo.messaging, Ubuntu:22.04:LTS: python-oslo.messaging, Ubuntu:24.04:LTS: python-oslo.messaging, Ubuntu:25.10: python-oslo.messaging, Ubuntu:26.04:LTS: python-oslo.messaging

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.