A Crafted Network Packet Can Trick Cloud Infrastructure Into Spilling Its Secrets

Imagine handing a stranger a mislabeled envelope and, in the process of trying to read it, your mail carrier accidentally reads everything else in their bag — passwords, private notes, account numbers — and hands it all back to the stranger. That is essentially what this vulnerability does to cloud networking infrastructure.

Who Is at Risk — and Why It Matters

Open Virtual Network (OVN) is not a consumer app you download from an app store. It is the invisible plumbing that connects virtual machines inside data centers and cloud environments — the kind of infrastructure that powers web hosting companies, enterprise private clouds, telecom providers, and platforms built on top of OpenStack and Red Hat OpenShift. If your company runs workloads in a virtualized environment, there is a meaningful chance OVN is quietly routing traffic underneath it.

The vulnerability, tracked as CVE-2026-5367, carries a CVSS score of 8.6 (HIGH). That score reflects the realistic danger: an attacker who already has access to a virtual machine on the same infrastructure — think a malicious tenant on a shared cloud, or a compromised workload inside a corporate environment — can potentially reach across the virtual walls that are supposed to keep them isolated and read memory that belongs to the host system. Sensitive data sitting in that memory could include credentials, encryption keys, or fragments of other tenants' network traffic.

What the Attacker Actually Does

Every device that connects to a modern network goes through a handshake process to get its address and configuration. For networks using the newer IPv6 standard, that process is handled by a protocol called DHCPv6. When a device joins the network, it sends out a "SOLICIT" message — essentially raising its hand and saying, "I'm here, please configure me." That message includes an identifier tag so the network knows which device it is talking to.

Here is where the attack begins. An attacker inside a virtual machine crafts a SOLICIT message, but instead of sending a normal, honest identifier, they inflate the declared length of that identifier — they claim the tag is far longer than it actually is. When the component responsible for managing virtual network logic, called the ovn-controller, receives this packet, it trusts the length field without verifying it. It starts reading data based on the inflated number, walking right off the edge of the actual packet and into adjacent memory it was never supposed to touch. That memory — heap memory, the dynamic working space of the running process — gets scooped up and sent back as part of the response to the attacker's virtual machine port. The attacker simply reads their response and sees what fell out.

This class of attack requires no sophisticated exploit chain, no zero-day escalation, and no physical access. It only requires the ability to send a single crafted network packet from inside a virtual machine. In multi-tenant cloud environments, where dozens of customers share the same underlying infrastructure, that bar is extremely low. One malicious or compromised tenant could potentially harvest sensitive data that belongs to the network controller or even other co-located workloads.

The Technical Detail That Matters

For security researchers and platform engineers: this is a classic out-of-bounds read on the heap, triggered via the DHCPv6 SOLICIT path inside ovn-controller. The flaw originates from insufficient bounds validation of the Client ID option length field in the incoming DHCPv6 packet before using it to index into packet buffer memory. Because the read result is echoed back through the virtual machine port response, this is not merely a crash vulnerability — it is an information disclosure primitive with direct data exfiltration potential, no crash required, no logs tripped in a default configuration.

Has This Been Exploited? Who Found It?

As of publication, no active exploitation in the wild has been confirmed. There are no known victim organizations, no threat actor campaigns attributed to this flaw, and no public proof-of-concept exploit code circulating. However, the research and security community's general posture on vulnerabilities of this class — information disclosure via a trivially crafted packet, accessible from an unprivileged network position — is that weaponization timelines can be short once a CVE is public. The exposure window between disclosure and patching is exactly when risk is highest.

Security teams should treat the absence of confirmed exploitation as a starting gun, not a reason to wait.

What You Should Do Right Now

1. Identify and patch affected OVN deployments immediately. Check your OVN version using ovn-controller --version on your hypervisor or network nodes. Apply the patched release from your distribution or upstream OVN as soon as it is available — watch the official OVN GitHub repository and your Linux distribution's security advisory channel (Red Hat RHSA, Ubuntu USN, etc.) for the specific fixed version targeting CVE-2026-5367. Do not wait for your next scheduled maintenance window.
2. Restrict DHCPv6 traffic at the network perimeter and between tenants. If your environment does not require DHCPv6, consider disabling it in your OVN logical switch configuration or applying firewall rules that block DHCPv6 SOLICIT packets from reaching ovn-controller from untrusted or external sources. This is a meaningful mitigation that reduces the attack surface while patches are applied. Review your Open vSwitch flow tables to confirm enforcement.
3. Audit your tenant isolation policies and network segmentation. This vulnerability is most dangerous in shared, multi-tenant environments. Review which virtual machine ports have access to send DHCPv6 traffic, and ensure that least-privilege network policies are enforced. Enable logging for anomalous DHCPv6 traffic patterns — specifically SOLICIT packets with unusually large Client ID option lengths — and alert on them. In cloud orchestration platforms like OpenStack or OpenShift, verify that security groups and network policies are correctly scoped per tenant.

CVE: CVE-2026-5367  |  CVSS: 8.6 (HIGH)  |  Component: ovn-controller (Open Virtual Network)  |  Class: Out-of-Bounds Read / Heap Information Disclosure  |  Vector: Network, No Authentication Required  |  Active Exploitation: None confirmed at time of publication