A VM Could Not Contain It: How a Deferred Checksum Became CVE-2026-99999, PwnEscape

Running untrusted code in a virtual machine remains a useful security boundary. But every host interface that the guest can reach must also withstand untrusted input.

CVE-2026-99999, disclosed in October 2026 and named PwnEscape by its researchers, makes that qualification concrete. The vulnerable component was Linux networking. A checksum operation deferred for performance could change an IPv4 header after earlier processing had already validated it, undermining the guest-to-host boundary.

The evidence needs careful wording: Vercel confirmed host-memory disclosure in production sandboxes. Host crashes and complete host execution were demonstrated on researcher-owned KVM and Firecracker environments. This article reviews public sources and the patch; it does not claim an exploit was run against production systems.

Figure 1. An original illustration for this article. The vulnerable component is the Linux networking stack; the VM boundary describes the isolation that the research crossed.

1. Serious does not mean an arbitrary internet packet gives everyone root

As checked on October 19, 2026, the official CVE record is published, with Linux as the assigning organization. Its title is ipv4: validate checksum_start before completing checksum. The record was first published on October 15 and updated on October 19.

It carries this CVSS 3.1 vector and a base score of 9.3:

CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

AV:L means a local attack vector. In a cloud sandbox, the attacker can already be a legitimate tenant running their own code inside a guest. The next step is to influence the host beyond the isolation boundary. S:C indicates that the impact can cross a security authority boundary.

Read PR:N in that context, too. It does not establish that every restricted container can generate the required inputs. Reachability depends on virtual networking, available interfaces, privileges, kernel configuration and the actual execution environment.

Figure 2. Actual browser screenshot of the official CVE record, captured October 19, 2026; cropped and compressed only.

Operators of Linux hosts running untrusted VMs, CI jobs or agent code sandboxes should establish their exposure promptly. Someone visiting an ordinary website does not automatically possess the guest-to-host path demonstrated in this research.

A severity score is also not a compromise detector. At the time of this review, NVD still labeled the entry Received, and the displayed score came from the record provider. It would be inaccurate to describe that as completed independent NVD analysis.

2. What the million-dollar challenge actually established

Vercel announced its million-dollar Sandbox challenge on August 18. That amount was the overall prize pool, not the reward paid for this particular vulnerability.

Paulos Yibelo and the pwn.ai research team investigated a broader question than whether the hypervisor itself had a bug: what could an untrusted guest influence elsewhere in the host operating system? Virtual networking provided the relevant path.

Figure 3. Actual browser screenshot of the original PwnEscape research, captured October 19, 2026.

The provider report and the researcher report support different, complementary claims:

The researchers reported a bounded disclosure of 32 bytes per active case. Later, in their owned environment, they demonstrated selected 64-byte kernel writes and a controlled host-execution chain across four cold boots. Each step required additional work. A small disclosure does not automatically become universal command execution.

Figure 4. Actual browser screenshot from Vercel’s challenge report, captured October 19, 2026. Read the environment qualifications in the table and source alongside the screenshot.

There is a date detail that can otherwise look contradictory. Vercel published its report on October 14, when its text still described CVE coordination and fixes as pending. The official CVE record followed on October 15. A statement that was current in the earlier report must not override newer publication status.

3. Imagine a school mailroom

There are three workers. An inspector checks the label on a parcel. A packing worker adds a final verification number. A sorting machine reads the label and sends the parcel onward.

To keep the line moving, the inspector allows the verification number to be calculated later. A sticky note says, “Start calculating here, and write the result there.”

Now suppose the sender can influence that note. Instead of pointing to the intended verification field, it points into the parcel label. The packing worker follows the instruction and changes a label the inspector has already approved. The sorting machine then trusts the changed label, although nobody approved that new interpretation.

Figure 5. Original diagram. Virtual networking is part of the host attack surface, even when the vulnerable source file is outside the hypervisor.

In Linux, the parcel is the packet, the label is the IPv4 header, and the sticky note is checksum metadata. The worker is a device or software helper that completes the checksum.

The important idea is ordering. A successful check is useful only if the meaning of the checked data remains valid until its later consumers use it. A subsequent legitimate operation can break that assumption without touching the original check itself.

4. Why CHECKSUM_PARTIAL describes a future write

Linux can carry a packet in CHECKSUM_PARTIAL state, leaving checksum completion to a later stage. This is normal transmit-side functionality and a useful optimization.

Two fields describe the operation:

csum_start   where checksum accumulation starts
csum_offset  distance from that start to the result field

result write location = csum_start + csum_offset

These fields are more than passive annotations. They authorize an actual write into packet memory later.

Figure 6. Actual browser screenshot of the Linux Checksum Offloads documentation, captured October 19, 2026.

There is also a coordinate problem. At ingress, a packet may still include Ethernet or additional link-layer headers. Later processing can remove or skip those headers. A check relative to the beginning of that earlier view does not necessarily prove that the write remains beyond the IPv4 header in the current view.

Think of an instruction to stamp page three after two packaging pages have been removed. The physical paper has not magically moved, but the reference point has changed. In the kernel, the allocation can stay put while the current data view and the relevant header boundary differ.

The research describes precisely this kind of mismatch between early metadata validation and later consumers. Historical IPv4 fragmentation and related paths could call skb_checksum_help() without the necessary constraint against the current IPv4 header. Malformed metadata could therefore direct checksum completion into header bytes already used for security-relevant decisions.

Figure 7. Original illustration of processing order and trust. It is an analogy, not an exact packet layout.

A checksum is not a cryptographic signature, either. It helps detect transmission errors; it does not authenticate the sender or make an untrusted write location trustworthy.

5. A 20-byte header becomes a 60-byte interpretation

IPv4 has an Internet Header Length field, IHL, measured in units of four bytes. In the controlled research example, the first byte could change from 0x45 to 0x4f.

The high nibble still identifies IPv4. The low nibble changes the interpreted header length:

Earlier: IHL = 5,  header length = 20 bytes
Later:   IHL = 15, header length = 60 bytes

Figure 8. Original illustration based on the researchers’ published controlled example.

Earlier code had processed a 20-byte header. A later consumer used the mutated length as if a 60-byte interpretation had been validated. Under the relevant packet geometry, fragmentation and memory conditions, that mismatch could lead to out-of-bounds reads and other memory-safety consequences.

This resembles a time-of-check/time-of-use problem, but it need not involve competing threads or a difficult scheduling race. The steps can execute deterministically. The deferred write between validation and later use is enough to undermine the earlier assumption.

Disclosure is one consequence; controlled writes and execution require additional conditions. This article explains the mechanism and defensive verification rather than providing malformed-packet construction or a guest-to-host exploit chain.

6. The patch moves a guard in front of the write

The accepted mainline fix is:

6785011f8b16abf40b1e9d8b2e332232b3e68822
ipv4: validate checksum_start before completing checksum

It adds a helper in include/net/ip.h with this central check:

if (unlikely(skb->csum_start <
             skb->network_header + ip_hdrlen(skb)))
    return -EINVAL;

Figure 9. Actual code-page screenshot from the mainline Linux fix, captured October 19, 2026.

In ordinary language: the checksum start must not be inside the IPv4 header. Since the output offset is nonnegative, the result write cannot move backward into that header either.

Let N be the network-header start, H the header length, C the checksum start and O the result offset:

C >= N + H
O >= 0
Therefore W = C + O >= N + H

Figure 10. Original illustration. Protecting the IPv4 header and validating all transport-layer semantics are different claims.

The commit changes six files and guards five relevant consumers: IPv4 fragmentation, bridge connection tracking, Netfilter queue processing, the CHECKSUM target and XFRM output.

The commit message explicitly describes defense in depth and says more complete input validation requires additional work. It is reasonable to describe this as an important constraint on the demonstrated path. It would be too broad to say that every security question involving the virtio checksum interface has now been settled.

7. Upstream fixed versions are not distribution package verdicts

At the time of review, the official CVE record listed these upstream baselines:

This table helps interpret the upstream record. It is not a universal scanner that can classify every distribution by comparing uname -r against one number.

Distributions can backport a security fix while retaining an earlier upstream version in their naming scheme. Conversely, a newer-looking version is not a substitute for evidence that a particular build includes the patch.

Ubuntu 26.04 needs an especially careful qualification. On October 19, the official linux / 26.04 LTS resolute row still said Needs evaluation, without a fixed package version for that row. Ubuntu’s page also showed Medium priority and Critical CVSS severity. Those fields answer different questions and do not cancel each other out.

Figure 11. Actual browser screenshot of the Ubuntu security page, captured October 19, 2026. Vendor status may change after publication.

Stay on the supported distribution and vendor kernel track, then identify the matching advisory, fixed package or equivalent patch evidence. Replacing a production kernel merely to make its number larger than a table introduces a separate compatibility decision.

8. Which layer should Windows, Ubuntu and macOS users inspect?

This CVE names Linux. It does not establish the same flaw in the native Windows kernel or Darwin. Nor does the table claim that every listed virtualization product has a demonstrated exploitable configuration. It identifies responsibility for checking the relevant layer.

Inside a container, uname -r usually reports the shared Linux kernel. Updating an application image can fix application packages, but it does not replace that shared kernel. Identify the owner of the kernel that actually processes the vulnerable path.

9. Three native scripts, with honest automation boundaries

Download the offline local toolkit, or obtain the Windows PowerShell script, Ubuntu Bash script and macOS Zsh script separately. A SHA-256 manifest checks download consistency.

The scripts use native system tools. They need no Python installation, online vulnerability scanner or additional SaaS. A single default command performs local inventory and writes JSON without uploading it, starting unknown VMs or running an exploit.

Optional updates use existing operating-system channels: configured APT repositories on Ubuntu and Microsoft’s WSL update mechanism on Windows. Those operations require access to the appropriate update source. Offline environments can still run the audit and use their established administrative process to distribute approved packages.

The key output is deliberately conservative: VENDOR_CONFIRMATION_REQUIRED. Ubuntu can update supported installed kernel metapackages, and Windows can request a WSL update. macOS has no single native command that reliably upgrades every possible Linux backend, so its script inventories recognizable products and leaves product-specific updating to the documented vendor process.

Method A: a person starts the script; the script performs the work

Download, inspect and extract the scripts. On Windows 11:

powershell -NoProfile -ExecutionPolicy Bypass -File .\pwnescape-windows.ps1

That execution policy applies to the newly launched process, not a permanent system policy change. For an authorized WSL update, use an elevated PowerShell:

powershell -NoProfile -ExecutionPolicy Bypass -File .\pwnescape-windows.ps1 -UpdateWSL

Activation still needs attention. After saving all WSL work in a maintenance window, add -RestartWSL if shutdown is authorized. That option stops every WSL workload. It does not update unrelated Docker Desktop or other VM backends.

On Ubuntu 26.04, audit first and optionally update:

bash pwnescape-ubuntu.sh --out audit-before.json
sudo bash pwnescape-ubuntu.sh --apply --out audit-after-update.json

The update mode requires Ubuntu 26.04 and a known non-container execution environment. It identifies supported installed kernel metapackages and updates through APT. It adds no repositories, removes no packages and performs no automatic reboot. It refuses updates in WSL, containers and unrecognized kernel tracks rather than installing into the wrong layer.

On macOS 27:

zsh pwnescape-macos.zsh --out audit-macos.json

The script records native OS versions and recognizable Docker Desktop, OrbStack, Lima and Colima installation clues. It does not collect VM names, accounts, network addresses or environment dumps. A narrow inventory finding no recognized app is not proof that no other Linux VM exists.

Exit code 2 means inventory completed but patch evidence remains unresolved. Code 1 means an execution or argument error; code 0 is used for help. An unresolved audit must not become a green security verdict, and its report should not be discarded merely because the exit code is nonzero.

Method B: let a local agent configure and run the workflow

Place the agent instructions beside the scripts and give a local agent this task:

Read AGENT-INSTRUCTIONS.txt and the script for this platform first.
Run the default offline audit and keep the report local.
Distinguish the native OS, Linux guests and the owning host kernel.
Find the matching vendor advisory, fixed build or patch evidence.
Keep missing evidence unresolved.
After I authorize maintenance, use the supported official update path.
Confirm the maintenance window before stopping workloads or rebooting.
After activation, repeat the audit and verify the running kernel and service.
Report confirmed facts, changes, pending activation and remaining unknowns.

The instructions allow automatic platform selection, limited fact collection and result preparation. They preserve maintenance authorization for disruptive work. An agent should not test production by attempting an escape or guess that an unfamiliar vendor build is safe.

The validation limits are part of the deliverable: Bash and Zsh syntax were checked, the default macOS audit ran on a real Mac, and the default Linux audit ran in a Linux environment. Help, invalid-option and wrong-platform refusal paths were also checked. The PowerShell script received static review; no Windows 11 test machine was available. The Ubuntu 26.04 update path was not executed against a production host. This is not a claim that three-platform remediation was tested end to end.

10. Check who is actually standing at the door

Installing a new kernel is like delivering a new guard’s uniform to the storeroom. The guard currently working at the entrance may still be the old one.

Figure 12. Original illustration. An enabled livepatch service also needs explicit coverage of this CVE before it counts as remediation evidence.

Close the maintenance with three checks. The vendor identifies the package or build as fixed. The kernel actually handling traffic has activated that build or a confirmed equivalent fix. Normal VM, network, DNS and application behavior still works afterward.

uname -r contributes runtime identity, but backported distribution fixes still need package and advisory evidence. A package-manager success message proves a transaction completed, not that a specific CVE was fixed and activated.

While evidence or a maintenance window is pending, consider restricting new untrusted jobs, reducing unnecessary device and network capabilities, or placing higher-risk workloads on resources already confirmed patched. These actions reduce exposure; they do not substitute for patch verification.

Avoid presenting “disable every offload” as a universal remedy. It changes performance and packet paths, and software fallback can still involve checksum completion. Without product-specific validation, one switch cannot establish that every relevant entry path is closed.

Figure 13. Original illustration. Each step needs evidence that matches the environment being maintained.

11. Questions that deserve direct answers

I do not use Vercel. Should I care?

Evaluate the actual environment. The defect is upstream Linux code, not a Vercel-only configuration issue. Self-managed platforms running untrusted guests deserve attention, but that does not establish successful escape against every cloud provider.

Is updating Ubuntu inside the guest enough?

Not when the vulnerable processing occurs in the outer host networking stack. Replacing an apartment door does not repair the building entrance. Identify which kernel owns the relevant path before deciding where to update.

Nothing crashed and the logs are quiet. Are we safe?

That is insufficient evidence. Availability and confidentiality are different properties, and disclosure need not cause an obvious outage. The reverse inference is also invalid: an ordinary networking failure does not prove exploitation of this CVE.

Why does Ubuntu say Medium when CVSS says Critical?

The base severity and the distribution’s prioritization answer different operational questions. Configuration, reachability and vendor assessment affect scheduling. Read both the priority explanation and the specific kernel status instead of choosing whichever label supports a preferred conclusion.

Why does the script still say unresolved after an update?

Because the update result proves only that the requested package operation completed. At publication, Ubuntu had not supplied a fixed version for the cited row. Once a vendor supplies the necessary evidence, match it to the actual running build before closing the issue.

If AI helped find this, can an agent own security by itself?

The researchers describe AI-assisted source analysis and research organization, alongside human direction, controlled experiments and independent review. Suggesting an attractive hypothesis and proving a real boundary crossing remain separate tasks.

The practical review question to take away is concrete: after data participates in a security decision, can a later deferred write, asynchronous task or representation change silently alter its meaning? Follow that question through real call paths, whether the object is a network packet, a queued message or an uploaded file.

Sources and review date

These primary sources were checked on October 19, 2026. Recheck vendor advisories before performing maintenance because remediation status can change.

1. Official CVE-2026-99999 record: publication status, vector, affected code and upstream baselines.
2. NVD entry: processing status and provider-supplied scoring.
3. pwn.ai’s PwnEscape research: mechanism, controlled demonstrations and evidence limits.
4. Vercel’s Sandbox challenge findings: production disclosure and researcher-owned demonstrations.
5. Accepted Linux mainline fix: the actual code change and defense-in-depth scope.
6. Linux Checksum Offloads: metadata and completion semantics.
7. Ubuntu’s official CVE page: distribution priority and kernel status.
8. Microsoft’s basic WSL commands: supported update, shutdown and version commands.