A publicly released proof-of-concept exploit is putting fresh pressure on administrators running virtualized Linux infrastructure to patch a high-severity kernel vulnerability, nicknamed “Vghost” by the researchers who disclosed it, before attackers build their own working version from the technical writeup already circulating.

What’s Actually Broken

The flaw, tracked as CVE-2026-74580 and rated 8.8 on the CVSS v3.1 scale, lives inside the Linux kernel’s vhost subsystem, the piece of infrastructure that lets virtual machines push network and device traffic through the kernel more efficiently by sharing data structures called virtqueues directly between a guest and the host, rather than routing every packet through a slower emulation layer.

The bug centers on how vhost caches IOTLB mappings, the lookup tables it uses to translate a guest’s view of memory into real addresses it can use to locate those virtqueues. When a virtual ring gets reconfigured, say, its address or size changes, the kernel is supposed to invalidate any cached mapping tied to that ring’s descriptor, available, or used data. Vghost exists because, in certain paths, it doesn’t. A later cache hit can skip the address validation that’s supposed to happen and instead reuse a stale mapping to translate the new, reconfigured address, handing kernel memory-copy routines a pointer that was never actually checked.

Researchers tracing the bug’s history on the oss-security mailing list linked it to two earlier, seemingly unrelated kernel changes: one that introduced the metadata caching mechanism in the first place, and a second that deferred when guest I/O address validation actually occurs. Individually benign, the two changes combined to create the gap now being exploited.

Two Separate Attack Paths

The published proof-of-concept demonstrates two distinct ways to abuse the flaw. The more straightforward path is local privilege escalation: any user with permission to open a vhost device node, such as /dev/vhost-net or /dev/vhost-vsock, can prime the stale cache, reconfigure a ring’s address without triggering invalidation, and then fire the queue to read and write arbitrary kernel memory. From there, the demonstrated exploit chain reads kernel memory to calculate the address-space-randomization offset protecting the kernel, then overwrites the kernel’s modprobe_path setting, a trick that lets an attacker redirect the kernel’s module-loading mechanism to execute an attacker-controlled binary with full root privileges.

The researchers say they successfully reproduced this chain across a notably wide range of mainstream distributions, including Ubuntu 26.04, RHEL 9.8, Amazon Linux 2023, Azure Linux 3.0, and Oracle Linux 10.2. Exposure varies by default configuration: on the tested Ubuntu system, access to vhost devices was restricted to members of the kvm group, while the other distributions tested left the relevant device nodes open to ordinary, unprivileged users by default, a meaningfully larger attack surface on systems that haven’t customized those permissions.

The second attack path is more specialized but more alarming: a configuration-dependent route to escaping a virtual machine entirely. It requires a vhost device configured with a virtual IOMMU, the iommu_platform flag enabled, and support for the virtio queue-reset feature (VIRTIO_F_RING_RESET). Under those specific conditions, a guest VM can reset and re-enable one of its own virtqueues in a way that causes the host to reconfigure the ring while the stale cached metadata lingers. When the guest subsequently triggers that queue, the resulting stale mapping can cause a used-ring write that lands outside the guest’s allotted memory and into the heap of the QEMU process running on the host, a condition the researchers say can crash QEMU outright or potentially be steered to influence its control flow. The researchers are careful to frame this as a configuration-dependent risk rather than a universal “every VM can escape” claim.

The Fix, and What to Do Until You’ve Applied It

Upstream Linux maintainers have already shipped a fix that clears the vring metadata cache whenever a ring’s address or size changes, forcing any new configuration to pass IOTLB validation again rather than relying on cached data. Fixed versions are available in the stable kernel series at 5.10.265, 5.15.216, 6.1.183, 6.6.152, 6.12.104, 6.18.45, 7.1.9, and 7.2, and administrators should install whichever fixed kernel or vendor backport applies to their distribution and reboot into it as soon as practical.

For systems that can’t be patched immediately, the researchers and downstream advisories recommend:

• Restricting access to all vhost device nodes, not just /dev/vhost-net, but also /dev/vhost-vsock, /dev/vhost-scsi, and the /dev/vhost-vdpa-* family.
• Avoiding passing any of those device nodes through to untrusted or multi-tenant containers.
• On virtualization hosts, avoiding exposing vhost devices configured with iommu_platform behind a virtual IOMMU to guests you don’t fully trust.

It’s worth stressing that tightening permissions is a stopgap, not a substitute for patching: revoking group membership or device access doesn’t retroactively close file descriptors a process already has open, and it does nothing at all to address the second, guest-triggered attack path. With a working exploit now public and reproducible across most major enterprise Linux distributions, the realistic window for patching before opportunistic exploitation begins is already narrowing.