PwnEscape (CVE-2026-99999): fixed upstream in 7 kernel series; Red Hat, Ubuntu, SUSE listed no fix on 19 October

Seven stable kernels carry the fix; three of seven distributors read list none

On Thursday 15 October 2026 the Linux kernel project released seven stable kernels that contain a fix for CVE-2026-99999: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.57 and 7.2.11. The changelogs on kernel.org (6.12.113 is linked as an example; the release list gives the dates) carry the same commit in each, copied from one mainline commit that is in 7.3-rc7 and in Linux 7.3, released on 18 October. The kernel project's own CVE authority published the record at 12:19 UTC that day, 2 minutes 54 seconds after the last of the seven release commits (derived from the changelog timestamps).

Four days later, on the morning of Monday 19 October, the CVE pages of three of the seven distributors read for this briefing listed no fixed kernel. Red Hat's security data lists 11 of 11 product rows as "Affected" and its statement says "fixes are being pursued". Ubuntu's data marks 7 of the 8 releases it lists for its kernel package as "needed", the eighth being 14.04, which is "ignored" as past standard support. SUSE's page marks 167 of 167 product rows "Affected" under an overall state of "Pending". Debian, Amazon Linux, Oracle Linux (for its own Unbreakable Enterprise Kernel) and Azure Linux show a fixed kernel. Three of seven is 42.9 per cent (derived).

What that count does not establish matters as much. It is the state of seven web pages between 07:55 and 08:30 BST on one Monday, not a measure of how fast any distributor works, and a page can trail a build. It does not say that any host has been attacked: CISA's Known Exploited Vulnerabilities catalogue (the JSON feed), version 2026.10.16 with 1,748 entries, has no entry for this CVE, and CISA's own entry on the CVE record rates exploitation "none". It does not say that every Linux server is exposed: the sources describe a path that a guest virtual machine reaches through its virtual network card, so the hosts at risk are the ones that run other people's code, or code that is not trusted. And it does not tell a reader whether their own kernel is fixed, because distributors backport fixes and a version number does not show it.

Two labels in the press coverage hide the gap. The Register calls the flaw a "9.3-rated critical". That is the CVSS 3.1 score set by the kernel's CNA (the body that assigned the CVE number); Red Hat, SUSE, Oracle and Amazon Linux each publish 8.8, and Ubuntu sets its own priority at "medium". The same article says the fix is working its way into major distributions, naming Debian, RHEL and Ubuntu. On the pages read, Debian has it and RHEL and Ubuntu do not yet. The researcher's own "KVM escape" label points at the wrong layer, as the next section shows. This briefing separates what the primary records establish from what the write-up and the press say, and ends with an ordered list of actions for hosts that run untrusted guests.

What the flaw is, at the level a defender needs

The CVE record's title is the kernel commit's title: "ipv4: validate checksum_start before completing checksum". The description, written by the kernel project, says that if a packet with bad checksum metadata gets into the IPv4 stack, the kernel's checksum-completion step "can corrupt the network header and cause a bunch of mischief". It credits one named researcher with the discovery and says others have reproduced it independently (the record spells the word "reporoduced"). It calls the change "a defence in depth measure" and adds: "A more complete validation at input is forthcoming, but needs more work."

The record's CVSS rationale, written by the same CNA, says which path it has in mind. A guest virtual machine supplies crafted checksum metadata with an outgoing frame through its virtual network card (virtio-net). The virtual machine monitor writes the frame to a TAP device on the host, and the host's IPv4 code then handles it. In the rationale's words, "this is a guest/local virtual-device path, not an Internet receive path". No host credentials are needed, it says, because the privileged monitor "merely forwards guest output". The attack vector is therefore Local, not Network, and a remote attacker with no foothold in a guest is not the concern.

The flaw is in the host's Linux networking code, not in KVM's own code. The researcher's write-up says in a figure caption that "the vulnerable component is the host networking stack". SOC Prime's summary says it "does not originate in KVM, Firecracker, or a specific cloud platform". AWS's bulletin calls it an issue in the "virtio-net/TAP networking path" that affects KVM-based hypervisors. The practical consequence is that a team which tracks only hypervisor advisories, or which has decided to change hypervisor, has not addressed a bug that lives in the host kernel underneath whichever hypervisor is used. Edera, which sells a Xen-based isolation product, argues from the same facts that a hypervisor living inside the host kernel widens the blast radius. Its commercial interest in that argument is plain.

The sources do not agree on how far the flaw has been shown to go, and the differences are the useful part.

What each source says the impact is, and what it leaves out. Quoted wording is from the page named; read 19 October 2026.

Source	Impact it states	Not stated
Kernel CNA, CVSS rationale in the CVE record	Host leak, crash and code-execution variants "were reproduced with crafted packets"	Whose machines, how often, or on which host configuration
Red Hat, CVE page	Potentially "arbitrary code execution on the host", a crash, or "information disclosure of sensitive memory"	That any of it has happened on a Red Hat product
AWS bulletin 2026-137-AWS	Corrupted host kernel memory that "could result in disclosure of host memory or a denial of service"	Code execution is not mentioned
Vercel, post of 14 October	A host memory leak shown on its production sandboxes; a host crash and commands run as host administrator on the researcher's own machines	Vercel says no report showed anyone accessing customer data in Vercel Sandbox
Researcher's write-up	32 bytes of host memory per case, a host crash, and a bounded chain to a host-root helper on machines the researcher owns	It is not "a claim of root command execution in any vendor's production environment". The second part is unpublished

Five labels that do the work of a control

A label is a summary written by someone with a purpose. None of the five below is wrong, and each can be read as an answer to a question it does not answer.

Labels in the coverage and what the records behind them show. Sources as named in the sections that follow.

Label	What it suggests	What the record shows
KVM escape	A hypervisor bug for the hypervisor's maintainers to fix	A bug in the host's Linux IPv4 handling that guest traffic reaches. The researcher's own figure calls the host networking stack the vulnerable component
9.3 critical	The number to rank patching by	8.8 at four vendors, "medium" at Ubuntu, no NVD score yet, and all of them above the Cyber Essentials line of 7
Fixed upstream	Your kernel has the fix	Seven stable lines and mainline have it. Three of seven distributors read list no fixed kernel, and a version number does not show a backport
AWS is not affected	The cloud is not affected	AWS says its managed compute (Amazon EC2, AWS Lambda and AWS Fargate) is not. Self-managed KVM and Firecracker hosts are named as affected, and no page read speaks for Google Cloud or for Azure's hypervisor
Defence in depth	A complete fix	The commit says it is one, and says broader validation at input "is forthcoming". No source read says that work has landed

What a reader can check is narrower and more useful: the running kernel build on each host that runs untrusted guests, the date it was verified, and a named owner for that host. The rest of this briefing is about getting to those three facts.

One flaw, many scores: where 9.3 and 8.8 come from

The CVE record carries one score, and it is the CNA's: CVSS 3.1 base 9.3 with the vector AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. NVD, the US national vulnerability database, holds the record at status "Received", has not scored it, and shows the CNA's score as a secondary entry. Recomputing the base score from that vector gives 9.3 (derived). Red Hat, SUSE, Oracle and Amazon Linux each publish the same vector with Privileges Required set to Low instead of None, which recomputes to 8.8 (derived). The gap is 0.5 (derived), and that one metric is the whole of it.

The pages read do not explain why the vendors chose Low. AWS's bulletin is the nearest: it describes an actor "with privileged access inside a guest virtual machine", while the CNA's rationale says a tenant workload that can transmit through its virtual network interface needs no host credentials. Both can be true, because Privileges Required concerns the attacker's position on the vulnerable system and the two readings put the guest's own privileges on different sides of that line (inference). Red Hat's page itself notes that "the two assessments differ on the privileges-required metric" and calls its own metrics "preliminary and subject to review".

Scores and ratings for CVE-2026-99999 as read on 19 October 2026. Derived means this site's arithmetic.

Source	Score or label	Basis or note
Kernel CNA, CVE.org record (published 15 Oct, updated 17 Oct)	CVSS 3.1: 9.3, Critical	PR:N. The only score on the record itself
NVD (API read 19 Oct, 06:56 UTC)	No NVD score; status Received	Last modified 16 Oct. Shows the CNA's 9.3 as a secondary entry
CISA-ADP, in the CVE record (16 Oct)	SSVC: exploitation none, automatable no, technical impact total	Not a CVSS score
Red Hat	CVSS 3.1: 8.8, Important	PR:L. Marked "preliminary" and "draft" in its data
SUSE	CVSS 3.1: 8.8. CVSS 4.0: 9.3. "Important"	SUSE's own vectors, PR:L. State "Pending"
Oracle Linux	CVSS 3.1: 8.8, Important	PR:L. Marked preliminary
Amazon Linux and AWS	CVSS 3.1: 8.8, Important. AWS: "Important (requires attention)"	Amazon Linux CVE page, seven advisories, bulletin 2026-137-AWS
Ubuntu	Priority "medium"	Ubuntu's own priority. Its data repeats the CNA's 9.3
Microsoft (Azure Linux)	9.3	Vector source given as "Linux", the CNA
ENISA vulnerability database	9.3	A copy of the CNA's score
FIRST EPSS (18 Oct)	0.211 per cent, percentile 10.6	30-day exploitation probability, a model not a severity score

None of this changes the order of work. Cyber Essentials v3.3 sets its 14-day rule at a CVSS v3 base score of 7 or above, or where the vendor calls the fix critical or high risk, so 9.3 and 8.8 fall on the same side. Ubuntu's "medium" is a statement about Ubuntu's own queue, not a reason to wait. The NCSC's triage guidance says a severity rating is an input and that the organisation must weigh business impact and risk, and it names flaws "that would have the largest negative impact if successfully exploited (such as those present in critical shared infrastructure)" as a priority. A host that runs other people's code is that kind of infrastructure.

FIRST's EPSS model put the probability of exploitation in the next 30 days at 0.211 per cent on 18 October (percentile 10.6, from 0.00211 and 0.10646). FIRST describes EPSS as a machine-learning model that draws on observed exploitation. This value was computed three days after the write-up was reposted on the oss-security list (derived) and says nothing about one capable attacker who already has a guest on a host. It is a reason to avoid panic and not a reason to defer.

What is fixed, and where

Upstream first. The CVE record lists the fix as eight commits: one mainline commit and seven stable backports. It says the flaw was introduced in kernel 2.6.27, and the commit message's Fixes lines name two earlier changes, one in the TUN driver and one for packet sockets. Each of the seven stable changelogs on kernel.org carries the backport and names the mainline commit as "upstream". The four short changelogs were read in full. The three of over half a megabyte were searched for that commit and for the release commit.

First fixed release per kernel line, from the CVE record, kernel.org's release list and each stable changelog. Release commit times are UTC, 15 October 2026 unless stated.

Kernel line	First fixed release	Release commit (UTC)	Backport commit
5.10	5.10.272	12:13	a464d950
5.15	5.15.223	12:14	0fab003e
6.1	6.1.190	12:15	94524b7b
6.6	6.6.159	12:16	a65f69e0
6.12	6.12.113	09:56	32a8b0ad
6.18	6.18.57	09:58	f3e835af
7.2	7.2.11	10:00	c3e33464
Mainline	7.3-rc7 (tagged 12 Oct, 03:04). Also in 7.3 (tagged 18 Oct, 23:14)	Committed 8 Oct, 18:03	6785011f

The seven backports copy one mainline commit, 6785011f. It changes six files, adding 44 lines and removing 12 (derived from its file list). It was authored on 7 October, committed to the networking tree on 8 October at 18:03 UTC, and pulled into mainline in the networking pull for 7.3-rc7, merged on 9 October at 04:40 UTC, according to the GitHub mirror of the mainline tree. (kernel.org's own git pages answered with a bot check and were not bypassed.) The researcher's write-up, and SOC Prime's summary of it, say the merge was on 14 October. The mirror shows 9 October and the 7.3-rc7 tag on 12 October, so this briefing uses 9 October and does not use 14 October.

The record names a fixed version only for the seven lines kernel.org lists as stable or long-term, plus mainline. It names none for lines that distributors still ship. Amazon Linux 2 runs 4.14 and 5.4 kernels, and Ubuntu's page says the upstream fix has reached 6.8, 6.17 and 7.0 series that kernel.org no longer lists. A reader on any other line needs the vendor's own page, not the CVE record.

Matching on version numbers misleads in both directions. The CVE.org record's CPE block lists eight version ranges, all starting at 2.6.27 and ending at each fixed release in turn. A scanner that matched a kernel against those ranges alone would flag 6.12.113, a fixed kernel, against three of the eight, and every kernel below 7.3-rc7 against the last (derived, calc.py). That is an inference about scanner behaviour, not a test of any scanner. The range AWS gives, "4.4 through 6.18", is a different bounding of the same flaw, scoped to the kernels Amazon ships. The safe test is a vendor changelog or advisory that names CVE-2026-99999 for the exact package, then the running kernel after reboot.

What each distributor's own page said on the morning of 19 October 2026, fixed first. The last column is what the page does not say.

Distributor and page read	State on 19 October	Not stated
Debian, security tracker	Fixed: bookworm (security) 6.1.190-1, trixie (security) 6.12.113-1, forky and sid 7.2.11-1. Origins named: DLA-4841-1 and DSA-6568-1	Advisory dates. The Debian list pages answered with a challenge and were not read
Amazon Linux, CVE page, seven advisories and AWS bulletin	Fixed: Amazon Linux 2 kernels 4.14, 5.4, 5.10 and 5.15, and Amazon Linux 2023 kernels 6.1, 6.12 and 6.18. All seven advisories updated 15 Oct	When the fix entered each package. Two advisories show a 1 October release date but were updated on 15 October
Oracle Linux, CVE page	Fixed for UEK: ELSA-2026-500397, 500398 and 500399, all 16 Oct, for Oracle Linux 7 to 10	The Red Hat Compatible Kernel: no erratum is listed
Microsoft, CSAF record for Azure Linux 3.0	Vendor fix named: kernel 6.6.159.1-1.azl3. First published 16 Oct	Anything outside Azure Linux, including Azure's hypervisor
Red Hat, CVE page and security data	No fixed kernel. 11 of 11 rows "Affected": RHEL 6 to 10 (kernel-rt on 7 to 9), RHEL for NVIDIA 26, OpenShift 4. "Fixes are being pursued"	A date. Mitigation: none meeting Red Hat's criteria
Ubuntu, CVE data	No fixed kernel. 7 of 8 releases "needed", 14.04 "ignored". Priority "medium". No notice	A date
SUSE, CVE page	No fixed kernel. 167 of 167 rows "Affected", state "Pending", no security announcement cross-referenced	A date. The page carries a general note that SUSE no longer fixes every kernel CVE

The fix itself is a guard added in five places, and the commit calls itself defence in depth. Whether the "more complete validation at input" the commit message calls forthcoming has landed is not stated by any source read. A patched host is therefore patched against this CVE's guard, and the CVE record does not promise more.

The diagram puts the dates on one scale. Solid dots are dates read in a primary record. Hollow dots rest on the researcher's account or on press coverage.

Which configurations are exposed: stated and not stated

Exposure is the question most readers need answered and the one the sources answer least. The table sets out what is stated, by whom, and what is left open. An absence from a vendor page is not a statement that a product is safe.

Exposure as the sources state it, and the gaps. Wording in quotation marks is from the page named.

Topic	Stated, and by whom	Not stated
Host type	KVM-based hypervisors on unpatched kernels. AWS names customers who self-manage virtual machines using virtio-net and KVM, "including those using virtual machine monitors such as Firecracker"	QEMU, Cloud Hypervisor, libvirt-managed hosts, Proxmox and Nutanix are not mentioned on any page read
Path	A guest's virtio-net frame forwarded by the monitor to a TAP device and handled by the host's IPv4 code, "not an Internet receive path" (kernel CNA). Red Hat: a local attacker or an untrusted guest "able to transmit such packets into an affected host"	Whether other ways of attaching a guest's network reach the same code. The write-up says other methods exist and the part read does not list them
Attacker position	A tenant workload that can transmit through its virtual network interface (kernel CNA). "Privileged access inside a guest" (AWS)	Whether an unprivileged process in a guest is enough: the CNA scores None and four vendors score Low
Where the fix goes	Six files across IPv4 output, bridge connection tracking, netfilter queueing, the CHECKSUM target and IPsec output (the commit's file list)	Which of those a given host reaches. No source maps them to configurations
Local users, no VM	Red Hat: "a local attacker". The write-up says reviewers also considered TUN and AF_PACKET cases without a VM	Whether those are reachable on a given distribution's default configuration
Managed cloud	AWS: Amazon EC2, AWS Lambda and AWS Fargate "are not affected" and need no action	Google Cloud: no bulletin on its bulletins page, newest GCP-2026-068 of 14 October. Azure's hypervisor. Oracle Cloud. The Register says Google is "probably in the clear", with no source
Which kernel to patch	The host's. AWS: apply the updated packages "to their host systems and reboot". SOC Prime: updating only guest kernels does not remove the host path	Live patching or live migration as a way to avoid downtime: no vendor page read mentions either for this flaw
Workarounds	None. AWS: "There are no workarounds for this issue". Red Hat lists no mitigation that meets its criteria	A configuration that closes the path while a kernel is awaited

The platform case is the clearest. Vercel says its sandboxes run each customer's code in a Firecracker microVM with its own guest kernel on bare-metal EC2 hosts, and its post says the memory leak was shown on production sandboxes. A platform of that shape is exactly the kind of host the CNA's rationale describes. The earlier briefing on an ARM64 KVM escape is a different bug with a different exposure: that one needed nested virtualisation switched on at boot. No record read makes nested virtualisation a condition here, which is why the stated and not-stated columns matter.

Exploitation and the write-up: what each source says

No primary source read says this flaw is being exploited. That is different from saying it is not.

What each source says about exploitation, with its date. Secondary sources are marked.

Source and date	What it says	What it does not settle
CISA KEV catalogue, version 2026.10.16 (16 Oct, 17:15 UTC)	1,748 entries, none for CVE-2026-99999	Anything after 16 October. KEV lists only exploitation already observed
CISA-ADP entry in the CVE record (16 Oct, 15:49 UTC)	SSVC: exploitation none, automatable no, technical impact total	A snapshot that CISA can update
Red Hat CVE page (changed 18 Oct)	Its statement says Red Hat "tracks this flaw as a KEV active-exploit case". The same page's data field for a known exploit is false	What Red Hat means. The catalogue read has no entry. Red Hat Product Security should be asked
AWS bulletin (15 Oct)	Describes the issue and the fixes. Does not mention exploitation	Anything outside AWS's own services
Vercel (14 Oct)	Demonstrations by the researcher. No report showed anyone accessing customer data	Whether anyone else has tried
SOC Prime (16 Oct, secondary)	No public evidence of malicious exploitation, no KEV entry, no campaign indicators	A detection vendor's reading of public information
FIRST EPSS (18 Oct)	0.211 per cent probability of exploitation in 30 days	A targeted attacker who already has a guest
Researcher's write-up	Expects "exploits in weaker configurations to arrive in weeks, and exploits working in default hypervisor configurations to arrive in under a month"	A forecast from a firm whose site offers penetration tests, not evidence of use

The Red Hat line deserves a plain reading. Red Hat's prose statement says it tracks the flaw as a "KEV active-exploit case". The structured field on the same page says no exploit is known, CISA's catalogue has no entry, and CISA's own SSVC entry says exploitation "none". Nothing read explains the prose. It is not a statement that exploitation has been observed, and it is not nothing: it is an unexplained sentence from a vendor whose product rows are all marked Affected, and the question belongs with Red Hat.

Where the research is public. The researcher's firm, pwn.ai, published a long write-up on its own site, and a third party posted its text to the oss-security mailing list on 15 October at 19:25 UTC, saying the existence of the flaw had been disclosed "a few days ago on Twitter". The write-up describes, in more depth than this briefing repeats, a host-memory disclosure and a lab chain on machines the researcher owns. It says a second part will cover the step from disclosure to host control, and that the first part keeps back the allocator-sensitive chain. SOC Prime calls a proof of concept "effectively available" through the write-up. Whether a ready-to-run exploit exists anywhere is not established by anything read. This briefing gives no technical detail of the method and does not link the write-up.

The dates are worth setting side by side (derived, calc.py). The researcher says the private report to the kernel's security contacts went in on 4 September and that public patch submissions followed between 19 and 22 September. The commit's "Closes" line points to a netdev message whose identifier carries 22 September. If so, the class of bug was on a public mailing list 23 days before the CVE, and the fix reached stable kernels 41 days after the private report. On 6 October The Register reported the researcher's claim, citing a bug-bounty award and a Vercel executive's statement that a KVM zero-day had been confirmed. The fix commit was authored the next day. Vercel's 14 October post said fixes were under private review and that it was disclosing the existence of the flaw "because it was separately disclosed in public". These dates come from the researcher's account and from kernel pages that sit behind a bot check and could not be read, so the early ones are marked as the researcher's on the diagram.

Two claims in the write-up are the researcher's and are attributed as such. It calls the flaw "an entirely new class of attacks in Linux networking", while also saying that its building blocks "are known" and that the lesson "is not evidence by itself that unrelated protocols, operating systems, or products are vulnerable". The Register repeats the first and not the second. And the write-up says its harness used GPT-5.6 Sol as "the primary reasoning engine", that it found the primitive "within three days", and that the work cost "under 700$ of API tokens". OpenAI sells the model named, and nothing read tests those statements. For a defender they matter only as one researcher's account of how fast a deferred-trust flaw can surface.

UK: what the guidance says, as read

The NCSC's all-site feed, whose latest item was dated 15 October 2026, carried nothing on this CVE or on KVM when read. The NCSC's site search needs JavaScript and was not searched. An absence from a feed is not a statement. The guidance below is general guidance, read from the pages themselves, and none of it was written for this flaw: the NCSC's update by default, active exploitation and triage pages, its separation principle, and the Cyber Essentials requirements v3.3. The last column is this briefing's reading.

UK guidance and law as read from the primary pages on 19 October 2026. The last column is this briefing's reading, not the publisher's.

Instrument, as read	What it says	Reading for this flaw
Cyber Essentials requirements for IT infrastructure v3.3 (April 2026), Security Update Management	Software in scope must be updated, fixes included, within 14 days of release where the vendor calls the fix critical or high risk or the CVSS v3 base score is 7 or above. Cloud services cannot be excluded from scope, and the applicant is always responsible for the controls	9.3 and 8.8 are both at or above 7. The clock runs from release: 26 October for Amazon Linux 2023 (12 Oct), 29 October for the kernel.org releases (15 Oct), 30 October for Oracle UEK and Azure Linux (16 Oct) (derived). Red Hat, Ubuntu and SUSE have no release to count from
NCSC vulnerability management: put in place a policy to update by default	Install updates as soon as possible, ideally automatically. Timescales: internet-facing services 5 days, internal or air-gapped 14 days	A host that runs untrusted guests fits neither row cleanly. Using the shorter is an inference, not NCSC wording
NCSC: responding to active exploitation	The compressed timelines of under 24, 48 or 72 hours start from "Has the vulnerability been added to the CISA KEV?". KEV reports only exploitation that has already occurred. Where proof-of-concept code exists and harm could be high, remediate sooner than business as usual	KEV is no and SSVC says none, so the compressed table is not triggered on the record read. A public technical write-up and the researcher's forecast are the NCSC's "sooner" case. Re-check KEV daily
NCSC: carry out assessments by triaging and prioritising	A severity rating is an input. Prioritise flaws with the largest impact, such as those in critical shared infrastructure. Record the date a fix is due and time-bound any temporary mitigation	Record the decision per host class. Where no vendor fix exists, put the date and an owner in the risk register
NCSC cloud security principle 3 and the separation guidance	Separation between customers "will only be effective if the service provider has an effective vulnerability management plan". To run custom code, look for hardware-backed separation and a small attack surface. Private clouds need the same technically enforced separation	The flaw sits in the host kernel's network path that hypervisor separation relies on. The NCSC's test of "the complexity of the security-enforcing interface" applies to everything a guest can reach, not only the hypervisor (inference)
NCSC cloud security principle 5.1, vulnerability management	A provider should commit to applying updates "within a defined timescale that is relative to the release of the update", and faster than individual organisations	Ask each supplier for that timescale and for the date it patched this flaw
Cyber Assessment Framework 4.0, B4.d and B4.a	B4.d, Achieved: announced vulnerabilities in all software and systems supporting the essential function are tracked, prioritised and mitigated promptly. B4.a: the function should not be impacted by the exploitation of any single vulnerability	For virtualised essential functions: evidence of tracking this CVE per host, and of segregation if one host falls
UK GDPR Article 32 and the ICO's data security guide	Controllers and processors must implement measures "appropriate to the risk", including ongoing confidentiality, integrity, availability and resilience. The ICO says to choose a processor with "sufficient guarantees about its security measures", and that its guide is under review after the Data (Use and Access) Act	No breach is reported in any source read, so nothing here triggers a notification. The Article 32 question is whether a provider hosting personal data on shared hosts can show it patched
NIS Regulations 2018, regulations 10 and 12	Operators of essential services, and relevant digital service providers including cloud computing services, must take appropriate and proportionate measures. A relevant digital service provider must notify the Information Commission of incidents with a substantial impact	A cloud provider in scope that runs KVM hosts has a regulatory reason to patch. The regulations set no number of days

Two UK points sit outside the table. First, Cyber Essentials counts days from release by the vendor of the update, so a customer of a distributor with no fix yet cannot be late, but can be exposed: the standard measures the clock, not the risk (inference). Second, the NCSC's cloud guidance treats a provider's patching timescale as something a customer should ask for and see evidence of. This flaw is a live test of whether a supplier can answer.

What to do, in the order worth doing

The list is for hosts that run guests, which means virtualisation hosts, microVM and sandbox platforms, build and CI runners, malware-analysis and AI-agent sandboxes. It is written at the level a defender needs: nothing in it requires knowing how the flaw is triggered.

What could not be verified

• Exploitation. None is established. Red Hat's prose line about a "KEV active-exploit case" is unexplained.
• A ready-to-run exploit. Whether one exists is not established. The write-up is public and detailed. The host-control part was unpublished when read.
• The researcher's early dates. The 20 August report, the 4 September private report to the kernel's security contacts, the 7 September reproduction and the 19 to 22 September netdev submissions are the researcher's. kernel.org git and lore.kernel.org answered non-browser requests with a bot check, which was not bypassed. The 22 September date rests on the dated message identifier in the commit's Closes line.
• The mainline merge date. 14 October in the write-up and in SOC Prime's summary, 9 October on the GitHub mirror of the mainline tree. This briefing uses the mirror.
• Debian advisory dates. The tracker names DLA-4841-1 and DSA-6568-1, but the Debian list pages answered with a challenge and were not read.
• AlmaLinux and Rocky Linux. Not read: the AlmaLinux errata site needs JavaScript and the Rocky API returned an unfiltered list. Rebuilds of Red Hat's kernel follow Red Hat, which has no fix.
• Google Cloud, Azure's hypervisor and Oracle Cloud. No statement found. Google Cloud's bulletins page and the GKE bulletins page had no entry. Microsoft's record covers Azure Linux only.
• Other projects and products. The Firecracker and Cloud Hypervisor advisory and release pages, the QEMU security process page, Proxmox's announcements forum and Nutanix's public advisories page did not mention the flaw. That is not a statement that they are unaffected.
• The NCSC. Only its all-site feed was checked, because site search needs JavaScript.
• EPSS. One daily value, 18 October. It will change.
• How the sources were read. Everything was fetched with curl or Python's urllib using a browser user agent. The CVE.org record was read through the CVE Services API behind the cve.org page, NVD through its API, Red Hat through its page and security-data API, Ubuntu through its CVE JSON, and Microsoft through its CSAF record. No form was filled in, no account was used, and nothing behind a bot check was bypassed.

The question that exposes the gap

A fix released upstream on a Thursday, a CVE published within three minutes, two scores for one flaw, and three distributors without a fixed kernel on the Monday: every sentence is true, and none of them says whether your hosts are safe. So ask the one question that does. For each host that runs other people's code: which kernel build is it running today, who checked, and on what date?

Key facts