DEV Community

Anoymask
Anoymask

Posted on

PwnEscape: Guest-to-Host KVM Escape and Host Memory Leak via Linux Checksum Processing (CVE-2026-99999)

#security #threatintel

1. Basic Information

The Linux CNA rated CVSS v3.1 at 9.3. The impact crosses the isolation boundary between the guest and the host, with production memory leaks and host code execution in researcher-owned environments reported. Red Hat assigned a score of 8.8; these scores come from different rating authorities.

2. In Short

A Linux flaw allows guest-provided checksum metadata to overwrite validated IPv4 headers. Production memory leaks and host code execution in a research environment have been reported, requiring remediation on the host kernel side.

3. Attack Flow

The following are sequential phases described by pwn.ai. Additional memory manipulation is required to progress from the first half (memory leak) to the second half (host execution). This does not mean the entire attack can be reproduced using only the first part of the disclosure.

Phase Verified Environment Key Technical Actions Confirmed Impact Scope
Phase 1 Vercel production sandbox and researcher-owned environments Used guest-controlled checksum metadata on packets marked CHECKSUM_PARTIAL to overwrite validated IPv4 headers (the header length indicated by IHL changed from 20 to 60 bytes in the research example) Demonstrated host memory leaks in production. In the researcher's controlled experiment, sent 32 bytes beyond valid 28-byte linear data as IPv4 options. No reports of customer data acquisition
Phase 2 (pwn.ai demonstration) Researcher-owned KVM test environment only Used host memory observations and allocation control to achieve selected 64-byte writes to host kernel memory and execute a helper program with root privileges Returned host-generated markers to the guest across four independent cold boots (detailed procedures not disclosed in Part 1; host code execution not confirmed in the Vercel production environment)

Phase 1: From Checksum Metadata to IPv4 Header Modification and Information Leak

  1. An attacker within the guest passes transmitted frames and crafted virtio-net checksum metadata to the host virtual network path.
  2. The host validates the IPv4 header while retaining the checksum metadata and CHECKSUM_PARTIAL state in sk_buff, proceeding to subsequent output and fragmentation processing.
  3. Delayed checksum calculation writes the result back to the validated IPv4 header. In the research example, the IPv4 header length indicated by IHL changed from 20 to 60 bytes.
  4. Fragmentation processing trusts the modified length, copying beyond the logical 28 bytes of linear data. In the research example, the 32-byte difference was sent externally as IPv4 options.

Phase 2: Progression to Host Execution in Researcher-Owned Environments

  1. Using host memory observations and allocation control from Phase 1, the researcher demonstrated selected 64-byte writes to host kernel memory in their own KVM test environment.
  2. They then reported completing a series of steps to execute a helper program with host root privileges, returning a host-generated verification marker to the guest across four independent cold boots.
  3. Details from writing to execution are not disclosed in Part 1. It cannot be determined that arbitrary code execution automatically succeeds based solely on a 32-byte leak.

These 32 bytes are host memory outside the valid linear data of sk_buff. This does not necessarily mean a read beyond the physical allocation region itself. Delayed checksum writing is a standard Linux feature, but the flaw lies in allowing a position that overlaps with the validated header. Researcher's Description, Checksum Specifications

4. Attacker Position and Execution Location

  • The attacker executes code within an untrusted guest VM and controls the virtual NIC checksum metadata passed to the host. This is distinct from paths that simply send regular IP packets from the internet.
  • In the Linux CNA microVM scenario, host credentials, privileges, or direct access to /dev/net/tun are unnecessary. The VMM passes guest output to the existing TAP path.
  • The modified packet processing and ultimate impact occur on the host Linux kernel side. Verify any operations and privileges required on the guest side, including whether the configuration allows manipulating the virtual NIC.

5. Perspective of Victims and Administrators

  • Users: For production memory leaks, Vercel explains that host memory-derived byte sequences were mixed into guest transmitted packets. They state there were no reports of access to customer files, secrets, or application data.
  • Administrators: The host-crash test showed that all sandboxes on the same host would stop together. The crash and code-execution demonstrations took place on researcher-owned machines.
  • Administrators: Inference: If it is only a memory leak, there may be no clear anomalies in user screens or standard application logs.

6. Success and Failure Conditions

Success Conditions

  • The host runs an unpatched Linux kernel, and the configuration allows malicious guest-provided checksum metadata to reach host IPv4 processing.
  • Reaching relevant processing steps, such as fragmentation, while able to write checksum results into the validated IPv4 header.
  • Progression to host execution requires additional conditions, such as the allocation control used in the research. The published leak description alone is insufficient to determine all conditions.

Failure Conditions and Countermeasures

  • Update the host to a patched kernel. Initial stable patch versions indicated by the Linux CNA are 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.57, 7.2.11, and mainline 7.3-rc7.
  • Fix commit 6785011f8b16 checks whether csum_start is at or beyond the end of the IPv4 header across five IPv4 checksum completion routines, rejecting invalid data.
  • This patch is a defense-in-depth measure to prevent IPv4 header overwriting and does not guarantee overall virtio input validation or correct TCP/UDP checksum positions.
  • Verify distribution patch versions, backports, and application to running kernels. Updating only the guest kernel cannot fix the vulnerability on the host side.
  • As of the check on October 18, 2026, Amazon Linux lists the affected kernel packages as Pending Fix. The availability of an upstream patch differs from availability and deployment status across products. Red Hat also has not provided general mitigation measures that can be applied.
  • References include Linux CNA Fixed Versions, Upstream Fix Diff, Amazon Linux Availability, and Red Hat Mitigation Description.

7. What Happens Upon Success

  • Host memory confidentiality is compromised. Vercel acknowledged proof of leaks in production sandboxes but did not confirm the acquisition of specific customer data.
  • In researcher-owned KVM and Firecracker environments, host crashes and code execution with administrator privileges were demonstrated, according to Vercel.
  • Inference: If the host crashes, co-located workloads are also affected. Cross-tenant compromise or credential theft after host control are potential impacts and are not treated as confirmed damage in this incident.

8. Observable Logs

  • Email: No email-origin or email log indicators specific to this issue have been published.
  • Proxy / SWG / DNS: Inference: Standard proxy and DNS logs do not expose packet IHL values or the checksum metadata held in the kernel. Destination records remain auxiliary information.
  • Endpoint / EDR: Inference: Where host audit or EDR records are available, they can help investigate suspicious root processes or persistence outside isolation boundaries. Kernel-level memory leaks do not necessarily trigger process creation.
  • Endpoint / EDR: Inference: Host kernel logs and crash dumps help investigate the cause of crashes, but a crash alone does not prove successful code execution.
  • Identity / IdP: The entry point for this issue is not an authentication service. Since paths not requiring host credentials exist, IdP logs alone cannot track attempts.
  • SaaS / Cloud: Inference: Correlate VM creation and execution entities, guest and host placement, and management records of host reboots and failures. Managed services require provider-side records and investigations.
  • Network: The research used transmitted packet observation and independent application-side reception confirmation to substantiate the leak from the host.
  • Network: Inference: Packet records mapping virtual NIC entry points to host transmission outputs help investigate alterations. However, checksum metadata is separate from the packet payload, and external packet captures alone cannot reconstruct all conditions.

9. Attack Success Determination

Confirmed by Public Information

  • Information theft or session compromise confirmed: Vercel states that host memory leaks were demonstrated in production sandboxes. pwn.ai confirmed a 32-byte leak in its controlled experiments. Vercel said that no reports showed access to customer files, secrets, or application data. Scope: Demonstration of production host memory leaks and 32-byte disclosures in controlled experiments in a researcher-owned environment. Distinct from actual damage by malicious third parties.
  • Subsequent compromise confirmed: pwn.ai reported host kernel writes and root-privileged helper program execution in an owned KVM environment, and Vercel described administrator-privileged code execution in owned KVM and Firecracker environments. This does not mean host code execution was confirmed in Vercel production. Scope: Limited to researcher-owned test environments.

The distinction is between Vercel's demonstration scope and pwn.ai's demonstration in owned environments.

Determination Criteria for Your Organization

Leaks require evidence that transmitted values are host memory rather than guest-derived data, and host execution requires evidence of execution outside isolation. Markers from public research are validation tools used by researchers, not IOCs present in your organization's environment.

10. Investigation Playbook

  • Starting Point for Investigation: Start investigations based on unpatched hosts running untrusted VMs, unexplained host crashes, execution outside isolation, and mismatches in transmitted IPv4 headers.
  • Initial Verification: Check the host's running kernel, vendor patch application status, virtual NIC and TUN/TAP paths, and guests/execution entities placed on the target host.
  • Endpoints and Hosts: Preserve host kernel logs, crash dumps, audit/EDR records, and process/persistence records for the target timeframe. Do not retransmit attack packets in your organization's production environment.
  • Authentication and Cloud: Cross-reference cloud-side VM creators, placement and migration history, and management operations. If direct host investigation is not possible, coordinate with providers regarding investigation scope and patching status.
  • Subsequent Actions: If execution outside isolation is confirmed on the host, expand the investigation to look for access to other workloads, credential use, and outbound data transfers. These are not publicly confirmed damages of this incident.
  • Containment: Inference: Isolate suspicious guests and hosts, and halt the placement of new untrusted workloads. Plan updates, reboots, and relocations based on service impact and evidence preservation, verifying operation on patched hosts.
  • Determination Categories: Assess vulnerable configuration presence, exploit attempts, host memory leaks, host crashes, host code execution, and cross-tenant access separately. Do not treat crashes or IHL anomalies alone as a successful VM escape.

11. Defense and Detection Ideas

  • Single Events: Inference: Unusual IPv4 options or host kernel anomalies serve as investigation triggers, but cannot be used alone for specific detection or confirming leaks.
  • Time-Series Correlation: Inference: Correlate guest transmission records, host transmission packets, simultaneous kernel failures, and process execution outside isolation using host-guest mapping relationships.
  • Hunting: Inference: Prioritize inventorying unpatched host kernels and co-located untrusted VMs. Exclude normal IPv4 option usage and legitimate host management operations.
  • Log Gaps and Limitations: Standard DNS, proxy, and IdP logs do not record csum_start or csum_offset. Public materials contain no completed detection signatures or event IDs specific to this issue, and monitoring cannot replace patching.
  • Priority Countermeasures: Prioritize patching the host kernel and verify patch availability and deployment across products.
  • Priority Countermeasures: Inference: Placement restrictions or reducing guest privileges until patched are auxiliary measures to reduce reachability, but are not universally effective workarounds. The presence of a virtualization boundary alone is not a reason to trust the host's network processing.

12. Facts / Inference / Hypothesis

Facts

  • pwn.ai reported a Linux flaw where guest-derived checksum metadata overwrites validated IPv4 headers. The flawed implementation is in host network processing, not KVM itself.
  • Vercel confirmed host memory leaks in production sandboxes and stated that crashes and code execution were demonstrated in researcher-owned KVM and Firecracker environments. They noted no reports of customer data acquisition.
  • The leak volume in pwn.ai's controlled experiments is 32 bytes. The series of steps leading to host execution successfully completed four independent cold boots in an owned KVM environment.
  • Linux fix commit 6785011f8b16 validates the start position before completing IPv4 checksums. This fix does not mean input validation is complete overall.
  • The Linux CNA rated CVSS v3.1 at 9.3, recording stable patch levels as 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.57, 7.2.11, and mainline 7.3-rc7.

Inference

  • Even if untrusted code is isolated in a VM, flaws in how the host interprets virtual device information can lead to attacks that cross isolation boundaries.
  • Guest-internal logs and standard communication logs alone are insufficient to determine host memory leaks or host execution. Operations require managing host-side patches and maintaining host-guest mapping relationships.

Hypothesis

No additional hypotheses. Unconfirmed items are listed in "Unknowns and Further Investigation."

13. MITRE ATT&CK Mapping

ID Technique Confidence Basis
T1611 Escape to Host high Corresponds to the public demonstration leading from researcher-owned virtualization environments to host root execution. Production host code execution and third-party attack campaigns remain unconfirmed. Research, Definition

14. Unknowns and Further Investigation

  • Detailed allocation control leading to host writes and code execution, and applicability conditions for each hypervisor, are not clarified in Part 1.
  • Reachability across all other virtualization products and configurations, leakage of specific customer data, and actual exploitation by malicious third parties are not substantiated by verified primary sources.
  • Patch package availability and deployment status across distributions and managed services require individual verification.
  • The official publication date and time for the primary source are not set. The publication date of October 15, 2026, is estimated from the article record creation date. Update dates can be confirmed in the original metadata.

15. Impact on SOCs and Organizations

In AI agent infrastructure, CI systems, and development sandboxes running untrusted code, adopting VMs does not mean the host attack surface has been reduced. In this incident, information accompanying guest communications influenced host kernel write positions and crossed isolation boundaries. In operations, it is crucial not only to manage guest update rates but also to track the application of host kernel patches, and to determine which guests and hosts can be linked to failures or suspicious transmissions. Distinguishing between memory leaks confirmed by providers in production and code execution in research environments helps maintain appropriate urgency without overestimating damage.

16. Summary by Target Audience

  • For SOCs: Do not judge communication anomalies or host crashes alone as VM escapes; cross-reference guest/host placement information, transmitted packets, and host-side execution evidence.
  • For Administrators: Verify that the host kernel is patched and that the patched kernel is actually running. Distinguish between stable patch levels and distribution backports/availability.
  • For Users: Managed sandbox users should check provider response status. Updating within guests alone does not verify host-side remediation.

Top comments (0)