Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessUnprivileged process in sandbox
-
DeliveryCraft packet with bad checksum_start
-
ExploitSubmit to local IPv4 stack
-
Executionskb_checksum_help corrupts network header
-
PersistCorrupt adjacent kernel memory
-
ImpactEscape sandbox, execute as host kernel
Vulnerability Assessment
| Exploitation Conditions | Requires a local attacker - realistically an unprivileged process inside a sandbox, container, or guest VM - able to inject a packet carrying malformed checksum metadata (an out-of-range skb checksum_start) into the host IPv4 stack, causing skb_checksum_help to write past/into the network header. Exploitation is bounded by: local access only (AV:L, no remote network path indicated); the target host must run an unpatched affected kernel (fixed by the referenced stable commits); and the attacker needs a way to supply packets with attacker-controlled checksum metadata, which is the enabling primitive in sandboxed/multi-tenant environments. Single-tenant systems with no untrusted local or sandboxed workloads are materially less exposed. |
| Impact | Signals point to a genuinely high-priority memory-corruption flaw, but with an important vector nuance. The provided CVSS 3.1 vector (AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, 9.3) describes a local, low-complexity, unauthenticated attack that crosses a scope boundary with full confidentiality, integrity and availability impact - consistent with a kernel heap/network-header corruption usable for sandbox or container escape. Note the apparent tension worth verifying: the description is framed around 'a packet with bad checksum metadata' entering the IPv4 stack, which sounds network-facing, yet the vector is AV:L; this is reconcilable because the malformed checksum_start metadata is realistically produced by a LOCAL process (e.g. an unprivileged task inside a sandbox/container/VM crafting packets), which matches the referenced Vercel Sandbox and pwn.ai 'Pwnescape' write-ups - but defenders should confirm whether any remote/guest-to-host path exists. No EPSS score was supplied, so exploitation probability cannot be quantified. There is no CISA KEV listing and no explicit POC flag in the input, so exploitation status is 'no public exploit identified at time of analysis'; however, two reference URLs (pwn.ai/blog/Pwnescape and the Vercel $1M sandbox-challenge blog) strongly suggest public exploitation research exists and should be reviewed to re-rate this. Patches are confirmed available (multiple git.kernel.org stable commits). Net: treat as a real priority for any system running untrusted local/sandboxed workloads on affected kernels; lower urgency for single-tenant hosts with no untrusted local code. |
| Exploit ScenarioDerived | An unprivileged process inside a sandbox, container, or VM crafts a packet with malformed checksum metadata (an invalid skb checksum_start) and submits it into the local IPv4 stack. When skb_checksum_help processes it, the bad offset corrupts the network header and adjacent kernel memory, which an attacker can shape into a sandbox/container escape with host-kernel code execution. Reference write-ups (pwn.ai 'Pwnescape', Vercel sandbox challenge) indicate exploitation research for this class, though no POC was explicitly flagged in the input. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 15, 2026
Memory corruption in the Linux kernel IPv4 receive path lets a local attacker who can inject a packet with malformed checksum metadata (an out-of-range skb checksum_start) into the host IPv4 stack cause skb_checksum_help to write into and corrupt the network header, yielding high-integrity and high-confidentiality impact with a changed security scope (CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, 9.3). The flaw is realistically reachable by an unprivileged process inside a sandbox, container, or guest VM that can supply attacker-controlled checksum metadata to the host kernel, making multi-tenant and sandboxed environments the primary exposure; single-tenant systems with no untrusted local or sandboxed workloads are materially less exposed. Exploitation requires local access only (no remote network path indicated), and intelligence available at the time of analysis shows no confirmed active exploitation (no CISA KEV) - though linked references to sandbox-escape research (pwn.ai's 'Pwnescape' and Vercel's $1M sandbox challenge findings) indicate the underlying primitive is being actively studied.
RemediationAI
Vendor-released patch: apply the upstream stable-tree fixes referenced by this CVE - the backports at the eight git.kernel.org/stable commit URLs listed above (a464d950f31c89565cbaae038cc60db04fe01956, 0fab003ef4698e0628060a45a48f14b43ba2a40a, 94524b7b32691de2e2ce162c04d6cbc9106e5cbf, a65f69e0f38ffbed1b128029e09097436416dc8b, 32a8b0adaa18e52aaa0b246b5ffe683075354dbb, f3e835af6226f1dd12160cbd696081e9b6155de0, c3e33464746166264334641dc850a36eef7e6326, and 6785011f8b16abf40b1e9d8b2e332232b3e68822) by updating to the corresponding patched kernel build for each affected stable series, and note that upstream describes these as defence-in-depth checks with a fuller input-path validation still being worked on, so expect follow-up commits. Until the kernel is updated, the most effective compensating control is to remove the local attacker's ability to introduce packets with attacker-controlled checksum metadata: run untrusted workloads in strictly isolated network namespaces with no route to the host or other tenants' stacks, and apply seccomp/AppArmor/SELinux policy that denies CAP_NET_RAW and AF_PACKET socket creation inside sandboxes and containers - the trade-off is that legitimate low-level networking, packet-capture, and some service-mesh/overlay agents inside those containers will break and must be allow-listed explicitly. Disabling or firewalling unneeded tunnelling, forwarding, and encapsulation features (which are the most common sources of externally supplied skb checksum metadata) reduces the reachable surface, at the cost of losing those network functions; fully network-isolating untrusted VMs and containers from host IPv4 processing, or deferring scheduling of untrusted multi-tenant workloads onto this kernel, is a heavier but reliable containment option. Monitor the linked research writeups (https://pwn.ai/blog/Pwnescape and https://vercel.com/blog/findings-from-the-1-million-dollar-vercel-sandbox-challenge) for published exploitation detail that may sharpen prioritisation, and treat the vendor commits as the authoritative fix source since no separate CVE-org advisory page is present in the reference set.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The affected component is the Linux kernel IPv4 networking stack, specifically the path that completes packet checksums via skb_checksum_help. Each skb carries metadata describing where the checksum-protected region begins (checksum_start) and how far it extends (checksum_offset); when that metadata is malformed - here, a checksum_start that falls outside the bounds the helper expects - skb_checksum_help performs its read/modify/write pass relative to an invalid offset and can write over the network header, corrupting packet state and, depending on downstream handling, kernel memory. Because skb_checksum_help is a generic helper invoked across receive/forward/encapsulation paths, the corruption is not confined to a single protocol handler, which is why the CVSS vector carries a Changed scope (S:C) and high C/I/A subscores. The upstream commit message explicitly frames the added checksum_start validation as a defence-in-depth measure layered on top of an input-path fix that is still in progress ('A more complete validation at input is forthcoming, but needs more work'), meaning the root cause class is improper input validation of attacker-influenced network metadata enabling an out-of-bounds/excessive write (in CWE terms, CWE-20 / CWE-787 family) rather than the generic 'Information Disclosure' label applied by the source tags - a tag that materially understates the memory-corruption and integrity impact captured by the assessed vector. CPE data (cpe:2.3:a:linux:linux:*:*:*:*:*:*:*:*) confirms the Linux kernel itself as the affected product, and the AV:L/PR:N combination means no prior privileges or credentials are needed, but a local execution context on the target host is.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Triggered by a locally supplied crafted packet (AV:L, AC:L, PR:N) that corrupts kernel memory across the sandbox/host boundary (S:C) yielding full kernel compromise (C:H/I:H/A:H).
Primary rating from Vendor (Linux).
CVSS VectorVendor: Linux
Lifecycle Timeline
2DescriptionCVE.org
In the Linux kernel, the following vulnerability has been resolved:
ipv4: validate checksum_start before completing checksum
If a packet with bad checksum metadata gets into the ipv4 stack, skb_checksum_help can corrupt the network header and cause a bunch of mischief.
This was discovered and reported by Paulos, and has been reporoduced by others independently since.
We really shouldn't allow such packets in, but as a defence in depth measure, let's also check before we complete the checksum.
A more complete validation at input is forthcoming, but needs more work.
Articles & Coverage 1
Technical POC Analysis
Bug class: inferred CWE-787 Out-of-bounds Write, enabled by insufficient validation of input checksum metadata.
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
A critical memory-corruption flaw in the Linux kernel IPv4 receive path (CVE-2026-99999) allows an unprivileged local process in a container, sandbox, or guest VM to corrupt host kernel memory, potentially escaping isolation and compromising confidentiality and integrity across tenant boundaries. Multi-tenant and sandboxed environments are the primary exposure; single-tenant systems without untrusted local workloads are materially less exposed. No vendor-released patch identified at time of analysis and no public exploit identified at time of analysis, but leadership should treat this as a severe risk to shared infrastructure.
No vendor-released patch identified at time of analysis. Interim mitigations: isolate multi-tenant and sandboxed workloads, restrict untrusted local processes from supplying attacker-controlled checksum metadata to the host IPv4 stack, enforce strong container/VM/sandbox isolation, and monitor for container-escape or kernel memory corruption indicators.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
EUVD-2026-102044
NVD
CVE.org
EPSS
Vulnrichment
VulDB
GitHub PoC
Exploit-DB