A Linux kernel vulnerability tracked as CVE-2026-74580, also known as Vghost, can allow an unprivileged local user to read and write kernel memory, potentially escalating privileges to root. Under specific virtualisation conditions, an attacker controlling a virtual machine may also be able to corrupt the host's QEMU process and compromise the guest-host isolation boundary.

The flaw affects Linux kernel versions from 4.11 through 7.2-rc4, according to the reported research. Tencent Zhuque Lab discovered the issue with assistance from its Corvus AI multi-agent research system.

The upstream fix clears a stale memory-mapping cache whenever a virtual ring is reconfigured. Administrators should install a kernel containing the fix and reboot affected systems.

What Is CVE-2026-74580 (Vghost)?

Vghost is a memory-safety vulnerability in the Linux kernel's vhost subsystem, which accelerates input/output operations for virtual machines.

The vulnerability stems from a mismatch between cached memory mappings and updated virtual ring addresses or sizes. When the relevant cache remains populated after reconfiguration, the subsystem may continue using an outdated mapping instead of validating the new address.

This can cause kernel operations to access memory outside the intended region.

The reported consequences include:

• Local privilege escalation: An unprivileged user with access to the relevant vhost device can potentially obtain arbitrary kernel memory read/write capabilities and escalate to root.

• Guest-to-host compromise: In a specific virtualisation configuration, an untrusted guest can trigger an out-of-bounds write into the host's QEMU process.

• Security boundary failure: Corruption of QEMU memory may allow an attacker to overwrite a function pointer, potentially redirect execution or crash the process.

The guest-to-host scenario requires particular conditions, including a virtual IOMMU, iommu_platform enabled and vhost operating in device-IOTLB mode. It should not be assumed that every virtual machine is equally exposed.

How the Vulnerability Works

The flaw developed through two changes to the Linux kernel:

1. Linux 4.11 — Cache introduction: A change introduced a cache for memory mappings associated with virtual rings. Cache hits could bypass repeated validation.

2. Linux 5.9 — Validation change: Address validation was moved out of the relevant configuration command and into a later processing stage.

The problem arises because certain commands can change ring addresses or sizes while a queue is active without invalidating the existing cache.

When the cache is populated, the subsystem may continue translating addresses through an outdated mapping. Subsequent operations can then access memory beyond the intended region.

In simplified terms:

Ring reconfiguration → stale mapping remains cached → new address uses old mapping → out-of-bounds memory access → potential privilege escalation or host-process corruption.

The flaw reportedly remained in the code for approximately nine years. The issue illustrates how individually reasonable code changes can interact to create a serious security weakness.

Who Is Affected?

According to the reported research, the vulnerable range extends from Linux kernel 4.11 through 7.2-rc4.

Tencent reproduced the local privilege-escalation chain on the following distribution kernels:

Device permissions can vary between deployments. Administrators should verify their actual configuration rather than assume that all installations of a distribution expose the same access level.

The vulnerability is especially relevant to multi-user Linux systems, virtualisation hosts and cloud environments where untrusted workloads may share underlying infrastructure.

Fixed Kernel Versions

The upstream fix is associated with commit de845981da67a6b049080c87e605130b0c30adc5. It invalidates the cache when the virtual ring is reconfigured.

The first fixed upstream stable versions reported in the source are:

Important: Distribution vendors may backport the fix without changing the kernel to one of these exact upstream versions. Check the relevant vendor security advisory and package status before determining whether a system remains vulnerable.

The source reported that Red Hat, Amazon Linux and Oracle Linux had shipped fixes. As of 13 October 2026, Ubuntu's 22.04 fix was listed as available, while fixes for its 24.04 and 26.04 kernels were still marked as in progress.

SOC and Infrastructure Security Investigation

Security teams should prioritise identifying vulnerable hosts, assessing device access and checking whether potentially untrusted users or workloads could reach the affected subsystem.

1. Identify vulnerable systems

Inventory Linux servers, hypervisors, cloud instances and virtualisation hosts. Record the kernel version, distribution, vendor security status and whether the vhost subsystem is used.

A kernel version alone may not establish vulnerability because vendors can backport security fixes.

2. Review vhost device permissions

Inspect the permissions and ownership of:

• /dev/vhost-net

• /dev/vhost-vsock

Determine which users and groups can access these device nodes. Investigate world-readable or world-writable permissions and verify whether access is limited to trusted virtualisation services.

3. Assess virtualisation exposure

For hosts running untrusted or multi-tenant workloads, review whether virtual machines use the affected vhost functionality, device-IOTLB mode, a virtual IOMMU and iommu_platform.

Prioritise environments where an untrusted guest can interact with the vulnerable code path.

4. Investigate suspicious activity

Correlate available endpoint, audit and hypervisor telemetry for unusual access to vhost devices, unexpected privilege changes, suspicious kernel-level activity, and unexpected QEMU process crashes or behaviour.

These are investigation leads, not confirmed indicators of Vghost exploitation. The source does not provide specific malicious IP addresses, file hashes or other network IOCs.

5. Patch and validate

Install a vendor-supported kernel containing the fix and reboot the system so the patched kernel is running. Validate the installed kernel and confirm that the relevant vendor advisory marks the system as remediated.

Until patching is complete, restrict access to the affected device nodes and limit relevant group membership to trusted services. These controls reduce exposure but do not replace the patch. The reported guest-to-host attack path has no interim workaround identified in the source.

Severity and Exploitation Status

The reported severity assessments differ between organisations:

These differences reflect how vendors assess the impact and security boundary of the vulnerability.

At the time of the report, there was no public indication of exploitation in the wild. This does not prove that exploitation is impossible or that every environment is safe.

The Role of AI in Discovering Vghost

Tencent Zhuque Lab reported finding the vulnerability with assistance from Corvus AI, a multi-agent system developed for kernel vulnerability research.

The upstream fix credits the AI-assisted research effort. The same research pipeline was also associated with the discovery of an older Linux SCTP vulnerability disclosed in August 2026.

This is an example of AI assisting security researchers with code analysis and vulnerability discovery. It is not evidence of an autonomous AI attack.

AI-assisted research can help identify interactions between code changes that are difficult to recognise during conventional review. However, findings still require technical validation, reproducible testing and a responsible remediation process.

Conclusion

Vghost highlights the security risks created by stale memory mappings in low-level operating-system components. The consequences range from local root access to potential guest-to-host compromise in specific virtualisation configurations.

For security teams, the immediate priorities are to identify affected kernels, review access to vhost devices, assess virtualisation exposure and deploy vendor-supported fixes.

Key takeaway: In shared Linux and cloud environments, a vulnerability in a kernel-level I/O component can threaten both host security and workload isolation. Prompt patching and strict device-access controls are essential.