Home / Guides / PwnEscape

CVE-2026-99999 explained: PwnEscape and the Linux host patch

A Linux networking flaw crosses the guest-to-host boundary in the published research. Cloud operators should verify the host patch evidence before closing remediation.

Last reviewed: · 5 min read

PWNAI's PwnEscape research describes CVE-2026-99999, a Linux networking flaw where guest-controlled checksum metadata can alter an already-validated IPv4 header. The Linux CNA record identifies a local virtual-device path, not ordinary Internet traffic. Vercel distinguishes production memory disclosure from crash and code execution on researcher-owned systems. Sorami has not independently reproduced the vulnerability.

Key takeaways

  • The Linux CNA rates this 9.3 Critical, with a local attack vector.
  • Vercel distinguishes production memory disclosure from researcher-owned system code execution.
  • The upstream patch guards IPv4 headers before deferred checksum completion.
  • The CNA's branch-specific fixes do not establish distribution package remediation.

What did PWNAI and Vercel report?

PWNAI reports that malformed checksum metadata can change an IPv4 header after the kernel has validated it. Its research follows the resulting fragmentation path and a bounded host-memory disclosure. PWNAI separately describes host control on its own systems. These are the original researcher's findings, not Sorami experiments.

Vercel reports that host-memory disclosure was demonstrated against production sandboxes. Vercel places the host crash and administrator code-execution demonstrations on researcher-owned KVM and Firecracker machines matching its configuration. Vercel also says no reports showed access to customer files, secrets or application data. That statement should not be read as denying the separately reported host-memory disclosure.

The Linux CNA published the record on 15 October 2026 UTC and assigns CVSS v3.1 9.3 Critical. The NVD record was marked Received when checked on 16 October. Its displayed score comes from the CNA, not an independent NVD assessment.

What does the checksum flaw mean in plain language?

PWNAI explains that checksum offload lets Linux defer a packet-integrity calculation. Metadata tells the kernel where that later calculation should write its result. The flaw lets untrusted metadata direct that write into an IPv4 header which earlier processing already accepted. Later fragmentation can then trust the changed header.

The CNA scenario starts with a malicious microVM supplying virtio-net checksum metadata. Its virtual-machine monitor passes the frame to a host TAP interface. The affected Linux host processing completes the checksum during IPv4 fragmentation. The CNA says the guest needs no host credentials or direct host TAP access. This is not an arbitrary Internet receive-path exploit.

Why does this matter for Australian cloud teams?

The CNA scenario makes the Linux host kernel relevant, even when each workload has its own guest kernel. The question for a sandbox operator is whether guest-controlled metadata reaches the affected host processing. A guest image version alone does not answer that host-side question.

The accepted Linux patch checks that checksum processing starts beyond the IPv4 header before completing the checksum. Its commit message calls the change defence in depth and says broader input validation needs more work. That wording does not establish that unrelated checksum or network-policy risks are resolved.

Which upstream versions contain the fix?

The Linux CNA version data lists introduction in Linux 2.6.27 and these branch-specific fixed releases: 5.10.272; 5.15.223; 6.1.190; 6.6.159; 6.12.113; 6.18.57; 7.2.11; 7.3-rc7. These are separate release lines, not one continuous vulnerable range.

The upstream fix is commit 6785011f8b16abf40b1e9d8b2e332232b3e68822. No distribution package mapping was verified for this guide. A lower-looking distribution version may contain a backport; a version-string comparison alone is not evidence either way.

Sorami's view

Prioritise evidence about the host you actually run. For self-managed sandbox hosts, ask the platform owner to connect the running kernel to a supplier advisory and fix status. For a managed service, ask the provider for its applicability and remediation statement. Avoid treating a patched guest image as proof about the host.

Keep the original report's evidence boundaries in your incident notes. A production disclosure and a lab code-execution result are different claims. Our cloud security review can help organise configuration and supplier evidence. This guide is an attributed advisory, not a Sorami discovery or reproduction.

What should operators check now?

Use this evidence checklist to review applicability and remediation with your platform owner.

  1. Identify who operates the Linux host and its virtual-network path.
  2. Record the running host kernel and installed package build.
  3. Request a supplier advisory explicitly mapping CVE-2026-99999 to that package.
  4. Confirm whether a backport or upstream fix covers the deployed branch.
  5. Record required reboot or live-patch activation evidence.
  6. Retain the supplier's applicability statement for managed sandbox services.

Frequently asked questions

What is CVE-2026-99999?

The Linux CNA describes an IPv4 checksum-metadata validation flaw. PWNAI calls its research PwnEscape and explains how deferred checksum work can alter a header after validation. The affected component is Linux host networking, not KVM instruction emulation.

Can CVE-2026-99999 be exploited from the Internet?

The Linux CNA describes a local guest-to-host virtual-device path, not an arbitrary Internet receive path. Its scenario needs control of virtio-net checksum metadata and a host path that performs the affected processing. Sending ordinary web requests is not the documented trigger.

Which Linux kernel versions fix PwnEscape?

The Linux CNA lists branch-specific upstream fixes, shown above. That list is not a distribution package advisory. Ask your operating-system supplier to map this CVE to the installed package and running kernel, including any backported fix and activation requirements.

Was host code execution demonstrated in Vercel production?

Vercel reports host-memory disclosure in production sandboxes. It places the crash and code-execution demonstrations on researcher-owned matching systems. Vercel says no reports demonstrated access to customer files, secrets or application data. Sorami has not independently reproduced the vulnerability.

Next step

Need help reviewing host and supplier evidence? Scope a cloud security review around your sandbox infrastructure and patch records. Contact us to discuss scope.

Compare cloud security reviews and penetration tests. Read what a penetration test report should contain for evidence expectations. Browse all Sorami guides.

Sources

Primary records and original reporting checked on 16 October 2026.