Vghost: kernel fix dated 3 August, demos 12 October, and 2 of 5 tested distributions still without a fix

70 days, and 2 of 5: what the dates and the trackers show

The kernel patch for Vghost, CVE-2026-74580, is dated 3 August 2026. Tencent Zhuque Lab's write-up, which carries, according to The Hacker News, working demonstrations of a root exploit and of a guest-to-host attack, is dated 12 October. That is 70 days (derived). Of the five distribution images the researchers say they took from a local user to root, three have a fix on the vendor's own page on the evening of 14 October (Amazon Linux 2023, Azure Linux 3.0 and Oracle Linux with its UEK kernel), and two do not: Ubuntu 26.04, where the fixed kernel is listed as pending, and Red Hat Enterprise Linux 9.8, whose RHEL 9 kernel Red Hat's data lists as affected. That is 2 of 5 (derived), as read between 19:05 and 19:31 BST on 14 October.

This is the checkable part, and it is narrower than the headlines around it. The Hacker News reports no public sign of exploitation. The CISA Known Exploited Vulnerabilities catalogue (release 2026.10.13, 1,741 entries) does not list the CVE, and FIRST's EPSS put it at 0.126 per cent (percentile 2.1) on 14 October. Those are a missing report and a prediction, not an observation that nobody has tried. The write-up has been public for two days and a proof-of-concept repository is linked from the researchers' own mailing-list post; this briefing does not link to either and describes neither beyond what a defender needs.

What the record does not establish:

• Any exploitation, by anyone, outside the researchers' lab.
• How many hosts expose a vhost device to unprivileged users. The researchers report what five images did, not what any estate looks like.
• Whether container runtimes hand the device nodes to containers by default. No source for this CVE tests a runtime. Docker's own documentation says a container is by default not allowed to access any devices, and that a privileged container is given all of them.
• Whether "found by AI" describes the finding or only the checking. Tencent's own documents word it three ways, and none says how many human hours went in.
• Whether any cloud provider's hypervisor fleet was affected. Only Tencent Cloud says anything about guest-to-host risk, and it is the finder's own company.

The clock: 3 days to a patch, 18 to a CVE record, 70 to the write-up

The dates below come from the headers of the fix commit, the CVE record, the stable release changelog, the Linux tags on the GitHub mirror of the kernel tree and the timeline printed in the Zhuque Lab write-up. The kernel.org web front end answered with a bot check, so the commit text was read on the GitHub mirror and in the 6.18.45 changelog, and that check was not bypassed.

Dated events for CVE-2026-74580, 2017 to 14 October 2026. Sources: commit headers and tags, CVE record, vendor pages, the Zhuque Lab write-up timeline.

Date	What happened	Source
28 Feb 2017	A commit adds the cache of address mappings, merged for Linux 4.11 (tag 1 May 2017 UTC).	Commit header, tag
3 Oct 2020	A commit moves address checking to a later step, Linux 5.9 (tag 11 Oct 2020).	Commit header, tag
31 Jul 2026	Write-up timeline: the missing cache reset identified, arbitrary read and write reproduced.	Zhuque Lab write-up
3 Aug 2026	Fix patch dated, written by an author with a Tencent address. A second developer committed it on 4 August.	Fix commit
9 Aug 2026	Linux 7.2-rc7 is tagged and contains the fix. 7.2-rc6, tagged 2 August, does not.	Kernel tags
16 Aug 2026	Linux 7.2 released, the first fixed mainline version.	CVE record, tags
19 Aug 2026	Linux 6.18.45 is dated, the first stable release read here that carries the fix.	Stable changelog
21 Aug 2026	CVE record published by the kernel's CNA. Red Hat's public date is the same day.	CVE record, Red Hat
24 Aug 2026	Researchers say full local root was verified on five distributions.	Zhuque Lab write-up
31 Aug 2026	Amazon Linux 2 and 2023 kernel fixes released.	Amazon page
4 Sep 2026	First Oracle Linux UEK errata.	Oracle page
20 Sep 2026	Tencent Cloud publishes a security notice about the flaw.	Tencent Cloud
6 Oct 2026	Ubuntu 22.04 fix released in USN-8875-1.	Ubuntu data
12 Oct 2026	Zhuque Lab write-up published. Red Hat's RHEL 7 Extended Lifecycle Support fix is dated the same day.	Write-up, Red Hat data
14 Oct 2026	The researchers post to the oss-security list, and The Hacker News publishes. The CVE record gains the list post as a reference.	oss-security, CVE record

The arithmetic (derived): 3 days from the lab's own identification to the dated patch, 18 days from the patch to the CVE record, 52 days from the CVE record to the write-up, and 70 days from the patch to the write-up. Tencent Cloud's notice came 48 days after the patch and 22 days before the write-up. The lab says it verified the full root chain on five distributions 49 days before it published. The fix was in the public kernel tree, with a commit message that explains which cache, which calls and why a check is skipped, no later than 9 August, and the CVE record did not exist until 21 August. The NCSC's update guidance warns that vendors may publish advisories for some vulnerabilities and quietly update others. Here the update came first and the label second.

One wording point. The Hacker News says the lab "released a fix on August 3". The patch header shows it was written that day, the second developer's commit is dated 4 August, and the write-up's own timeline says the fix entered mainline on 3 August. The kernel tags show mainline contained it by 9 August and not on 2 August. So 3 August is the date on the patch, which is why this briefing says "dated".

What the flaw is: two routes into one stale cache

vhost is the part of the Linux kernel that speeds up networking and other input and output for virtual machines. Per the CVE record and the commit message, it keeps a small cache that records which memory region behind each virtual ring has already been validated, and a cache hit is taken as proof that the check has been done. The cache is cleared on several events, but not when the ring's address or size is changed while the queue is live. With a device-level address translation layer attached, those changes are accepted without a check and the check is left for later, so a stale entry keeps vouching for an address it no longer covers. The kernel then copies data to or from that address without a bounds check. The researchers describe the result as reading and writing memory the caller was never given.

Route 1 is the local one. The CVE record's own scenario text says exploitation needs the ability to use a vhost device node, and names "standard libvirt/QEMU kvm-group account" as the typical owner. Route 2 is the guest one. The researchers' post says it needs a guest using a virtual IOMMU with platform access and a ring-reset feature, and the write-up adds that vhost must run in device-IOTLB mode. The Tencent Cloud notice words its three conditions slightly differently (a virtual IOMMU, platform access, and the kernel vhost backend); all of them agree on the first two. Neither the post nor the write-up says how many real hosts run that configuration.

The researchers call the host route deterministic: no race, no memory grooming, no retuning for a new kernel layout. That is their description and was not tested here. They also say their exploit was given a matching symbol map for each of the five targets and needs only long-lived symbols; how an attacker would get the equivalent on a given host is outside what any source covers. The guest route is narrower by design: three stated conditions, all of which must hold on the same virtual machine.

This is a different bug class from the one in an earlier briefing on an ARM64 KVM escape, which only hosts that enabled nested mode exposed. Here the gate on route 1 is a file permission, and on most of the images tested it was open.

Nearly a decade: what 4.11 to 7.2 covers, and what it does not

The Hacker News and the write-up both say the flaw spans nearly a decade of kernels. The CVE record marks Linux affected from 4.11, unaffected from 7.2, and gives a first fixed version in eight lines: 5.10.265, 5.15.216, 6.1.183, 6.6.152, 6.12.104, 6.18.45, 7.1.9 and 7.2. From the 4.11 tag (1 May 2017 UTC) to the 7.2 tag (16 August 2026) is 3,394 days, 9.29 years (derived). Inside that span sit 52 mainline release series, 4.11 up to and including 7.1 (derived). The record gives a first fixed version for seven of those series, in the stable lines above, and none for the other 45 (derived). On 14 October kernel.org's release list shows one mainline line, one stable line and six longterm lines, 5.10 to 6.18, so no series below 5.10 is on the list of maintained branches, and an upstream fix for them is not to be expected (inference).

The markers behind "nearly a decade", with the span from each to the dated fix on 3 August 2026 (derived from tag and commit dates on the GitHub mirror of the kernel tree).

Marker	Date	Span to the dated fix (derived)
Cache commit, the record's start point	28 Feb 2017	9.43 years
Linux 4.11 tag	1 May 2017	9.26 years
Deferred-check commit, the second change	3 Oct 2020	5.83 years
Linux 5.9 tag	11 Oct 2020	5.81 years, 62.8 per cent of the 4.11 span
Linux 7.2 tag, first fixed mainline	16 Aug 2026	13 days after the dated patch

The start point is the commit named in the fix's "Fixes" line, the 2017 commit that added the cache. The commit message and the write-up both say the defect needs a second change, the 2020 commit that accepts the new addresses without checking them, and the write-up says the vulnerable path is unchanged from 5.9. The Hacker News says the flaw sat there for about nine years because it took two reasonable changes to create it. On the dates, the second of the two is 5.81 years old at the fix. The 2020 commit asked for backporting to stable lines from 4.14, so older longterm lines may have picked up the second change when it was backported (inference; the record does not say which). The record does not say whether kernels from 4.11 to 5.8 can be exploited by another route, and this briefing does not claim they cannot.

A version range is also not a verdict on a distribution kernel. Red Hat's data lists a fix for Red Hat Enterprise Linux 7 Extended Lifecycle Support, kernel 3.10.0-1160.167.1.el7 (RHSA-2026:81349, 12 October 2026), a kernel whose base number is older than 4.11. Red Hat would not have shipped it if the code were absent (inference). The upstream range says where the flaw began upstream. Whether a given vendor kernel has it, or has the fix, is a question about its package revision.

"Found by AI": what Tencent's own documents say, and where they differ

Tencent Zhuque Lab is the security research group of a company that sells cloud services (Tencent Cloud), a server operating system (TencentOS Server, listed in the Tencent Cloud notice) and its own AI models (Hunyuan). A result that showcases its pipeline and its model is also marketing for them. That is no reason to doubt the bug, which the kernel's own CVE record confirms. It does mean the AI claim is the lab's claim about its own product, and it is worded differently in each place it appears.

What each Tencent-side document, and The Hacker News, say about the AI role in CVE-2026-74580, and what each leaves out. All read on 14 October 2026.

Source	What it says	What it leaves out
Write-up, summary	Corvus AI "discovered" the flaw "in 2 hours", and Hunyuan's Hy4-preview was integrated into the exploit verification and patch validation loop.	What the two hours measure, from what starting point, how many candidates the pipeline raised, how many were false, how many human hours.
Write-up, workflow section	Hy4-preview was used in two stages, dynamic exploit verification and patch regression analysis, and the pipeline "autonomously drove" the cross-distribution reproduction and patch verification loop to completion.	Whether a person chose the subsystem to study, what "autonomously" covers, and any check of the benchmark chart for the lab's own model.
Researchers' mailing-list post	Corvus AI "assisted with source analysis, reproduction, exploit development, and cross-platform validation".	"Assisted" is a smaller word than "discovered". Which part a person did is not said.
Fix commit trailer	Assisted-by: tencentos-corvus-ai:kimi-k3, with a Tencent-address author and a second developer signing off.	Names a model, kimi-k3, that the write-up's workflow section does not mention. The trailer does not say which step it did.
The Hacker News	Found "with help from" Corvus AI, "machine-assisted research, not an attack run by AI", under a headline that says AI-found.	THN's wording follows the commit trailer, not the write-up's "discovered".

Three readings fit all five rows. The pipeline found the defect and people checked it. People pointed the pipeline at vhost and it did the reading. Or the pipeline did the verification and a person found the pattern. The record does not choose between them, so "AI-found" is, on the evidence, a label for where the lab says its tooling sat, not a measurement of how much a model did.

How the finding was checked, per the lab: by running its own exploit on five distribution images (24 August in its timeline), after the fix and the CVE record, and by a patch regression step that it says it ran with the same pipeline. The sources read report no independent reproduction of the root chain or the guest route. Vendors have since listed or shipped fixes, which shows the defect is accepted; whether any vendor reproduced the demonstrations is not stated.

The label also says nothing about severity. Seven raters score the same flaw between 6.4 and 8.8 (next section), and the differences in their vectors are about scope and privileges, not about who found it. The NCSC's frontier AI blog says many of the benefits and risks it discusses are delivered by AI systems that combine models with tools, workflows and human oversight, rather than by raw model capability, and its patch wave blog of 1 May 2026 tells organisations to expect more updates, faster. The practical reading is to plan for more fixes of this kind, not for a different kind of flaw. Whether the two-hour figure is repeatable is not established.

One flaw, seven scores: 6.4 to 8.8

Each score below was recomputed from the vector its publisher printed, using the CVSS 3.1 formulas, and all seven match (derived). The spread is 2.4 points. Six of the seven are at or above 7.0, the line the Cyber Essentials requirements use for "high risk" (below). Only Microsoft's 6.4 is under it.

Ratings for CVE-2026-74580 as read on 14 October 2026, from the CVE record, NVD, and each vendor's page or data feed. Attribute each score to its publisher.

Rater	Rating and score	What differs in the vector
Kernel CNA (CVE record, copied by NVD)	High, 8.8	Scope changed, integrity high. Its scenario text names the guest-to-host case.
NVD itself	No score of its own	Status "Received"; shows the CNA's 8.8 as a secondary score.
Red Hat data feed	Important, 7.3	Scope unchanged, integrity low.
Red Hat customer portal page	8.7	Scope changed, integrity low. The page and the feed disagree on the same afternoon.
Amazon Linux	Important, 7.8	Scope unchanged.
SUSE	Important, 7.8	Scope unchanged. The page shows the CNA's 8.8 beside it.
Oracle Linux	Moderate, 7.3, marked preliminary	Scope unchanged, integrity low.
Microsoft, Azure Linux 3.0	Moderate, 6.4	Attack complexity high and privileges high.
Ubuntu	Priority medium	Carries the CNA's 8.8 beside a medium priority.
Debian, Alpine	No rating	Debian's page gives none; Alpine's shows NVD severity unknown.

The Hacker News is right that the raters disagree on how high. The disagreement is mostly two switches. Scope: does the guest-to-host write cross a trust boundary (the CNA says yes; Red Hat's feed, Amazon, SUSE and Oracle say no)? Privilege: is a vhost device node reachable by an ordinary user? Microsoft's vector assumes high privileges and high complexity, while the researchers report that on the Azure Linux 3.0 image they tested, the node was open to any user and the chain reached root. Those statements are about different things, a vendor's scoring default and one test image, and the record does not say which describes a given host.

The friendly names: "local", "AI-found", "high, not critical", "fixed version"

A comforting label is not a control. Each of these does the work of a decision in the coverage, and each can be checked against the record.

Labels in the coverage of CVE-2026-74580 against what the primary records show.

Label	What it suggests	What the record shows
"Local" (attack vector L)	Someone has to be at the keyboard.	It means able to reach a device node. The CNA's scenario names a kvm-group account and "an authorized malicious VM tenant". The researchers report the node open to any user on four of five images. On a shared host, a build runner or a Kubernetes node, local means anyone who can run a job.
"AI-found"	A new class of flaw, or a more dangerous one.	A cache not cleared when two values change, created by two ordinary commits. The label changes neither the score nor the fix.
"High, not critical"	Can wait for the next maintenance window.	Root on a shared host, and a write out of a guest into the host's VM-manager process. At or above 7.0, the Cyber Essentials 14-day clock applies.
"Fixed in 6.1.183"	Check the kernel version with a command and move on.	Distribution kernels keep their base number and backport. Red Hat fixed a 3.10 kernel, and Amazon's fix of 31 August postdates the 6.1.180 kernel the researchers tested.
"No sign of exploitation"	Nobody is using it.	Nobody has reported it, two days after a write-up and with a proof-of-concept repository linked from the researchers' post. Not seen is not the same as not tried.
"Container" or "VM" as isolation	The boundary holds.	The NCSC says kernel-enforced separation usually only suits services where customers cannot run executable code. This flaw is in the kernel component that serves virtual machines and devices, so the guest route crosses that boundary on the stated configuration.
"kvm group"	An ordinary group.	The researchers say to treat membership in it as privileged while the kernel is vulnerable. On Ubuntu 26.04 it was the only gate.

Where the distributions stand: 11 of 26 releases have no fix on the pages read

Placed from each vendor's own tracker, data feed or advisory page between 19:05 and 19:31 BST on 14 October 2026. Alpine's tracker lists the CVE but its table of vulnerable and fixed packages is empty, so Alpine releases are placed from the package version in its public package tree (read on a GitHub mirror because GitLab refused the request, a check that was not bypassed) and marked derived. A distribution fix usually keeps the old version number, so the package revision is the thing to compare. The method is the one used for the table of tested environments in the Ghostscript briefing.

The five images the researchers tested, against the vendor pages read on 14 October 2026. Node settings and kernels are the researchers' statements.

Image tested, and its kernel	Device node, per the researchers	Vendor page, 14 October
Ubuntu 26.04 LTS, 7.0.0-28-generic	kvm group only	Not fixed: pending 7.0.0-39.39.
RHEL 9.8, 5.14.0-687.5.3.el9_8	World access	Not fixed: RHEL 9 kernel listed Affected.
Amazon Linux 2023, 6.1.180-225.360	World access	Fixed 31 Aug (ALAS2023-2026-2107), after the test image.
Azure Linux 3.0, 6.6.150.1-1.azl3	World access	Fixed in 6.6.152.1-1, per Microsoft's update guide.
Oracle Linux 10.2, 6.12.0-204.92.4.2.el10uek	World access	UEK fixes: ELSA-2026-500248 (4 Sep) and ELSA-2026-500374 (7 Oct).

Twenty-six distribution releases placed from their trackers on 14 October 2026. Fixed means a fixed package is published on the vendor's page. Not fixed means the page shows needed, pending, in progress or affected.

Release	State as read	Evidence on the page
Debian 11 bullseye	Undetermined	Not listed on the tracker page.
Debian 12 bookworm	Fixed	Security archive 6.1.187-1 (DLA-4777-1). The main archive still shows 6.1.176-1 as vulnerable.
Debian 13 trixie	Fixed	6.12.105-1 (DSA-6466-1); security 6.12.111-1.
Ubuntu 18.04	Not fixed	Listed as needed.
Ubuntu 20.04	Not fixed	Listed as needed.
Ubuntu 22.04	Fixed	5.15.0-198.208, USN-8875-1, 6 Oct.
Ubuntu 24.04	Not fixed	Pending 6.8.0-148.148.
Ubuntu 26.04	Not fixed	Pending 7.0.0-39.39.
RHEL 7 (extended support)	Fixed	3.10.0-1160.167.1.el7, RHSA-2026:81349, 12 Oct.
RHEL 8	Not fixed	Listed Affected.
RHEL 9	Not fixed	Listed Affected. The 9.6 Extended Update Support stream has a fix, 5.14.0-570.138.1.el9_6, 2 Sep.
RHEL 10	Not fixed	Listed Affected.
SLES 12 SP5 (LTSS)	Not fixed	Listed Affected.
SLES 15 SP6 (LTSS)	Not fixed	Listed Affected.
SLES 15 SP7	Not fixed	In progress; packages listed in QA.
SLES 16.0	Not fixed	In progress.
Amazon Linux 2	Fixed	ALAS2-2026-3881, 31 Aug. The page's navigation labels this release EOS.
Amazon Linux 2023	Fixed	ALAS2023-2026-2107, 31 Aug.
Oracle Linux 8 (UEK)	Fixed	ELSA-2026-500249, 4 Sep. The page lists no errata for the Red Hat compatible kernel.
Oracle Linux 9 (UEK)	Fixed	ELSA-2026-500248, 4 Sep.
Oracle Linux 10 (UEK)	Fixed	ELSA-2026-500248, 4 Sep.
Azure Linux 3.0	Fixed	6.6.152.1-1, per Microsoft.
Alpine 3.21	Fixed by version (derived)	Package 6.12.112; first fixed in that series is 6.12.104.
Alpine 3.22	Fixed by version (derived)	Package 6.12.112.
Alpine 3.23	Fixed by version (derived)	Package 6.18.56; first fixed in that series is 6.18.45.
Alpine 3.24	Fixed by version (derived)	Package 6.18.56.

Counting from the trackers (derived): of 26 releases, 10 show a fix on the vendor's own page, 4 (Alpine 3.21 to 3.24) are fixed by package version only, 11 show no released fix (Ubuntu 18.04, 20.04, 24.04 and 26.04; RHEL 8, 9 and 10; SLES 12 SP5, 15 SP6, 15 SP7 and 16.0), and 1 is undetermined (Debian 11, which is not on the tracker page). So 11 of 26, or 42.3 per cent, have no released fix (derived). Three vendor families have at least one such release: Ubuntu, Red Hat and SUSE.

Two cautions on the table. First, The Hacker News says Red Hat has shipped fixes. Red Hat's data feed lists them only for RHEL 7 Extended Lifecycle Support and RHEL 9.6 Extended Update Support, and shows the main RHEL 8, 9 and 10 kernels as affected, with the RHEL 9 real-time kernel marked as a deferred fix. Second, SUSE's page says it no longer fixes every kernel CVE and declares some bug classes will-not-fix; for this one it shows an overall state of pending and an advisory of 13 October (SUSE-SU-2026:4640-1) that covers some products, including Real Time 15 SP7. A tracker can lag its vendor's build system, so absence of a fix on a page is a reason to ask, not proof that none exists.

Cloud and hypervisor statements: what exists

The question a tenant needs answered is what a cloud provider says about its own hypervisor hosts. Most providers say nothing about this CVE, and what exists is mostly about guest operating systems. Read directly:

Provider statements found for CVE-2026-74580, read 14 October 2026.

Provider	What the page says	What it does not say
Tencent Cloud	Notice of 20 September, in Chinese, rates the risk high, lists affected operating systems, gives the three guest-escape conditions to look for in a virtual machine's launch settings, and says its cloud virtual machines were checked and carry no VM-escape risk. It also says no temporary mitigation exists for that route.	What was checked, by whom, or how. It is the finder's own company stating that its own service is not exposed.
Microsoft	The [update guide](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-74580) lists the Azure Linux 3.0 kernel as fixed in 6.6.152.1-1, Moderate, 6.4, first published 23 August.	Anything about Azure's hypervisor fleet. The entry concerns the Linux distribution.
Amazon	[Amazon Linux Security Center](https://explore.alas.aws.amazon.com/CVE-2026-74580.html): kernel and live-patch advisories for Amazon Linux 2 and 2023, all dated 31 August, Important, 7.8. The AWS [security bulletins page](https://aws.amazon.com/security/security-bulletins/) read had no entry for the CVE.	Anything about EC2's hypervisor layer.
Google Cloud	The Cloud SQL for PostgreSQL 15 [maintenance changelog](https://docs.cloud.google.com/sql/docs/postgres/maintenance-changelog/postgres-15) lists the CVE among operating system patches in a release dated 29 September. The [bulletins page](https://docs.cloud.google.com/support/bulletins) read had no entry for it.	Anything about Compute Engine or GKE nodes.
Proxmox VE	A staff reply on the project's [forum](https://forum.proxmox.com/threads/cve-2026-74580-v-ghost-%E2%80%93-affected-proxmox-ve-versions.187037/) says the fix has been in its 7.0 kernel since a changelog dated 22 August (7.0.14-14).	Other kernel tracks. It is a forum reply, not an advisory.

No statement establishes that a hyperscaler's hypervisor fleet was affected or unaffected. The Tencent Cloud line is the only one that addresses the guest route, and it is the vendor's own claim about its own service. Whether any provider uses kernel vhost with a virtual IOMMU for tenant guests is not stated by any source read, so a provider's silence cannot be read as a yes or a no.

Stated and not stated: the record, line by line

What the sources state about CVE-2026-74580, and what they do not.

Question	Stated	Not stated
Exploitation	No public sign (The Hacker News). Not in the CISA KEV catalogue, release 2026.10.13. EPSS 0.126 per cent.	Any telemetry or hunt result. Anything about use after the write-up (12 October) and the proof-of-concept link (14 October).
Who can reach the host route	Node open to any user on 4 of 5 tested images, kvm group on Ubuntu 26.04 (researchers). Privileges low in the CNA's vector.	The share of production hosts that expose a node. Other distributions, hardened images, or virtualisation platforms. Container runtime defaults.
Who can reach the guest route	Three conditions: virtual IOMMU, platform access, device-IOTLB mode. Tencent Cloud says its virtual machines are not exposed.	How many hosts run that configuration, or whether virtual machine managers other than QEMU are in play.
The AI role	Three wordings (discovered, assisted, an Assisted-by trailer) and two model names.	Human hours, the scope of the two hours, false positives, cost, which step each model did.
Affected range	From 4.11 per the CNA, with the second commit in 5.9. First fixed versions for eight lines.	Exploitability of 4.11 to 5.8, or fixes for lines below 5.10.
Fix coverage	Fix dates for Amazon, Oracle, Red Hat (two streams), Ubuntu 22.04, Azure Linux, Proxmox and SUSE Real Time.	Debian 11, Alpine in its tracker, Oracle's Red Hat compatible kernel, dates for the Debian advisories, and what each vendor's backport contains.
Severity	Seven scores from 6.4 to 8.8.	Any agreed score. NVD has not analysed it.

UK: the 14-day clock, the NCSC on separation, and shared hosts

Cyber Essentials. The current technical requirements are version 3.3, dated April 2026, effective from 27 April 2026 according to the NCSC's Cyber Essentials resources page. The requirements document says all software on in-scope devices must be licensed and supported and updated, including vulnerability fixes, within 14 days of release where the vendor describes the fix as critical or high risk, where it addresses a vulnerability with a CVSS v3 base score of 7 or above, or where no severity is given. It defines software to include operating systems and says that if an update covers any critical or high risk issue, the whole update must be installed within 14 days. That matters here because kernel updates arrive as bundles: the Ubuntu notice that carries this fix lists 951 CVEs in Ubuntu's data (derived count of the list). The text does not say whose score applies. On the seven read, six are at or above 7 and one is below, so the assessor, not this briefing, has the last word. It also says nothing about the case where no update has been released, which describes Ubuntu 24.04 and 26.04, RHEL 8, 9 and 10 and the SLES releases in the table as read.

The 14-day Cyber Essentials window and the NCSC's 5 and 7 day timescales counted from each fix release date read, as of 14 October 2026 (derived).

Fix release	Cyber Essentials 14th day	NCSC 5th and 7th day
Upstream 6.18.45, 19 Aug	2 Sep, 42 days past	24 Aug and 26 Aug
Amazon Linux, 31 Aug	14 Sep, 30 days past	5 Sep and 7 Sep
RHEL 9.6 EUS, 2 Sep	16 Sep, 28 days past	7 Sep and 9 Sep
Oracle Linux UEK, 4 Sep	18 Sep, 26 days past	9 Sep and 11 Sep
Ubuntu 22.04, 6 Oct	20 Oct, 6 days left	11 Oct and 13 Oct, both past
RHEL 7 ELS, 12 Oct	26 Oct, 12 days left	17 Oct and 19 Oct
SUSE Real Time 15 SP7, 13 Oct	27 Oct, 13 days left	18 Oct and 20 Oct

For managed or cloud services the same document says the applicant is always responsible for the controls, and that for infrastructure as a service security update management is typically shared between the customer and the cloud provider, and for platform as a service likewise. A virtual server's guest kernel is the customer's to patch; the provider's host kernel is the provider's, and the requirements ask the customer to hold a contractual commitment for any control the provider implements on its behalf.

NCSC patching. The NCSC's vulnerability management guidance, version 2.1, reviewed on 1 May 2026, gives best-practice timescales for all updates regardless of severity: 5 days for internet-facing services and software, 7 days for operating systems and applications, 14 days for internal or air-gapped systems. Against the 7-day figure for operating systems, the Ubuntu 22.04 fix of 6 October fell due on 13 October (derived). The same page says the most reliable way to automate is to replace the running image or code with the updated version, which fits virtual machine and container fleets. The triage step says that where no update is available you need a process to triage and prioritise, and that a temporary vendor workaround should be time-bounded and tracked. The patch wave blog asks organisations to enable automatic hot patching where it is available; Amazon's live-patch advisories of 31 August are an example. No NCSC publication on this CVE was found in a search of the NCSC's pages, which is a limited check.

Separation between customers. The NCSC's cloud security principle 3, version 2.1, reviewed on 7 June 2023, says that for customers who can run custom executable code you should look for hardware-backed separation with a small attack surface, usually virtualisation with a hypervisor, and that separation enforced by the kernel usually only suits services where customers cannot run executable code, which includes some containerisation. It adds that the separation between customers is only effective if the provider has an effective vulnerability management plan. Vghost sits in the kernel component that serves virtual machines and device access, so it bears on both halves: a container that has been handed the device is inside the kernel-enforced half, and a guest on the stated configuration is in the hardware-backed half with a route across it. The principle asks you to know which separation mechanisms a service uses; this is a case where the answer decides your exposure.

The ICO and UK GDPR. Article 32 of the UK GDPR requires controllers and processors to implement appropriate technical and organisational measures for a level of security appropriate to the risk, including a process for regularly testing, assessing and evaluating their effectiveness (Article 32). The ICO's data security guide adds periodic checks that measures remain appropriate and up to date, and says a controller must choose a processor that gives sufficient guarantees about its security measures and have a contract requiring Article 32 measures. The ICO page carries a banner that its guidance is under review because of the Data (Use and Access) Act. The ICO has said nothing about this flaw. That a controller which ran personal data on shared Linux hosts, knew of a root-capable flaw with a published fix, and did nothing would struggle to call its measures appropriate is this briefing's inference, not an ICO statement.

What to do, in order

The question that exposes the gap

The coverage offers three comfortable answers: it is local, it was found by AI, and it is rated high, not critical. Each is a label for a different question. The record underneath says the fix was in the public tree 70 days before the demos, that two of the five images the researchers broke had no released fix on 14 October, and that on four of the five the only gate was a file mode. Whether you are exposed depends on who can open one device node on your hosts, and on whether any guest can make the host open it for them. Does anyone in your organisation know which of your hosts let an unprivileged user, or a tenant's guest, reach the kernel's fast path for virtual machines?

Key facts