⌁AI·CYBER·BRIEF▌
Vulnerabilities7 min read

AI-found Linux kernel flaw "Vghost" gives local users root — and can let a VM reach its host

Tencent's AI-assisted research found CVE-2026-74580 in the vhost subsystem, present since Linux 4.11. Fixes are out for most distros; Ubuntu 24.04 and 26.04 are still pending.

A memory-safety bug in the Linux kernel's vhost subsystem, tracked as CVE-2026-74580 and nicknamed "Vghost", lets a local user who can open a vhost device become root, and in one less common virtualization setup lets a guest VM reach the host's QEMU process. Tencent Zhuque Lab credits its AI research system, Corvus AI, with the find. The flaw affects kernels from 4.11 through 7.2-rc4. Install your distribution's fixed kernel and reboot. Until you can, restrict who can open /dev/vhost-net and /dev/vhost-vsock.

What happened, in plain English

When a Linux server runs virtual machines (VMs), the kernel can speed up their network and socket traffic with a component called vhost. Two of its device files, /dev/vhost-net and /dev/vhost-vsock, let a program such as QEMU (the emulator behind most KVM virtual machines) hand that work to the kernel.

To do this quickly, vhost keeps a small cache of "where is this VM's memory?" lookups. The bug is that the cache is not cleared when a VM's queue is reconfigured. The kernel keeps using an old lookup for a new address and skips the safety check it would normally run.

Think of a mail sorter who memorised which shelf belongs to which apartment. The building gets renumbered, but the sorter keeps using the old map without looking at the new one, so letters end up on shelves that belong to someone else. In the kernel, those "letters" are memory reads and writes, and they land outside the area they should touch.

According to Tencent, a regular user who can open one of these device files can use this to read and write kernel memory and become root (full administrator). In a specific setup, a VM with a virtual IOMMU (input-output memory management unit, the component that controls which memory a device may access) can reach the memory of the host's QEMU process.

Tencent Zhuque Lab published its write-up on October 12, 2026. The fix went into the main kernel on August 3. The bug sat in the code for close to ten years. Tencent says two separate changes, from kernel 4.11 and 5.9, each reasonable on its own, combined to create it.

Are you affected? What to do now

You should care if you run Linux hosts with KVM/QEMU virtualization, Linux machines where users or containers you do not fully trust have shell access, or cloud images from the distributions below. Desktops and servers that never load vhost and give no one else a shell carry much less risk, but should still take the kernel update.

Check your exposure

  • Find your kernel version (uname -r) and compare it with your distribution's advisory. Vendors backport fixes without changing the upstream version number, so the advisory matters more than the number.
  • Check who can open the devices: ls -l /dev/vhost-net /dev/vhost-vsock. Tencent notes that some distributions ship them world-accessible (mode 0666), while others restrict them to root and the kvm group (0660).
  • List members of the kvm group and any container that is given these devices.

Patch, in this order

  1. Amazon Linux: fixed packages released August 31, 2026 for Amazon Linux 2 and 2023, including livepatches (for example ALAS2023-2026-2107; see Amazon's CVE page).
  2. Oracle Linux (UEK kernels): errata from September 4 and October 7, 2026, such as ELSA-2026-500374 for Oracle Linux 9 and 10 (Oracle).
  3. Ubuntu: 22.04 kernels are fixed (for example linux 5.15.0-198.208). For 24.04 and 26.04 the fix is still "in progress", and some HWE and 20.04/18.04 kernels show no fix yet (Ubuntu). Apply the workaround below until fixes ship.
  4. Red Hat Enterprise Linux: Red Hat rates it 8.7 (High). When we checked, its CVE page listed a mitigation but no errata. Watch it for RHSA updates.
  5. Upstream / self-built kernels: first fixed stable releases are 5.10.265, 5.15.216, 6.1.183, 6.6.152, 6.12.104, 6.18.45, 7.1.9 and 7.2 (fix commit de845981da67).
  6. Reboot. A kernel package that is installed but not running does not protect you (livepatched Amazon Linux systems excepted).

If you cannot patch yet

  • Remove world access from the vhost device files and limit the owning group to trusted services (Tencent's advice).
  • While the kernel is vulnerable, treat kvm group membership as equivalent to root.
  • Do not pass vhost devices into untrusted containers.
  • On machines that do not run VMs, Red Hat suggests blocking the vhost module from loading. This removes in-kernel acceleration for virtio networking, storage and vsock, so VMs on that host may slow down or fail to start.

There is no workaround for the guest-to-host path. Only the patched kernel fixes it. No exploitation in the wild has been reported, but a public proof-of-concept exists, so treat multi-user and container hosts as a priority.

The expert view

The mechanism. vhost moves virtqueue processing into the kernel. When a device IOTLB (the I/O translation cache used with a virtual IOMMU) is attached, vhost translates guest I/O addresses through it and caches the translations for the ring's metadata. Reconfiguring a live ring's addresses or size (the VHOST_SET_VRING_ADDR and VHOST_SET_VRING_NUM operations, in Ubuntu's description) did not reset that metadata cache. A later cache hit skipped validation, so the kernel accessed memory through a stale mapping, outside the region the IOTLB actually covers. Red Hat classifies it as CWE-825, an expired pointer dereference. The fix resets the cache whenever the ring is reconfigured.

Two attack paths, two scores. On the host, the attacker needs only the right to open a vhost node. That is why device permissions and kvm membership decide your real exposure. The VM escape is narrower: it requires a virtio device behind a virtual IOMMU with iommu_platform enabled in device-IOTLB mode. In that setup, Tencent says, a guest that triggers a ring reset (VIRTIO_F_RING_RESET) makes QEMU perform the reconfiguration, and in testing the guest gained control of QEMU's execution. That is an escape into a userspace process on the host, not straight into the host kernel, but QEMU often runs with significant privileges. The scores reflect the scope question: kernel.org rates it 8.8 with scope changed, Red Hat 8.7, Amazon 7.8 and Oracle 7.3 (preliminary). Ubuntu gives it Medium priority despite the 8.8 score.

What is new. The bug class is not new: stale translation caches and missing invalidations are classic kernel bugs. Two things stand out. The first is age and breadth: the flaw spans almost a decade of releases, and Tencent reproduced a full root chain on Ubuntu 26.04, RHEL 9.8, Amazon Linux 2023, Azure Linux 3.0, Oracle Linux 10.2 and upstream 7.2-rc4. The second is how it was found. Tencent's write-up credits Corvus AI but gives no detail on how the tool was used. Coverage by The Hacker News describes Corvus as a multi-agent system for kernel research and reports that the upstream fix carries an "Assisted-by" credit; we could not read the commit ourselves. Either way, this is AI-assisted discovery directed by human researchers, not an autonomous attack.

The broader trend. This fits a pattern we have tracked for weeks: AI tools are finding more and more bugs in old code that humans have reviewed for years. Microsoft reported 140 Windows CVEs from its AI research lab in five months, and Google has found that AI-found bugs skew toward code execution. For defenders, the bottleneck is moving from discovery to deployment. Vghost was fixed upstream in August, yet two major Ubuntu LTS releases were still waiting for a kernel in mid-October.

What is still unknown. Tencent has not described how Corvus AI found the bug or how much human work the exploit needed. It is unclear which distributions ship the device nodes world-accessible by default. Red Hat's errata status was not visible on its CVE page when we checked. Nobody has reported exploitation in the wild.

Official sources

Get the daily brief

AI + security signal by email: headlines, a two-line summary, a link. No noise, no spam.

How often