Exploit discussion active in current signal (1 latest mentions)
Recommended action window: High priority (within 72h)
NVD description
In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Fix shadow paging use-after-free due to unexpected GFN The shadow MMU computes GFNs for direct shadow pages using sp->gfn plus the SPTE index. This assumption breaks for shadow paging if the guest page tables are modified between VM entries (similar to commit aad885e77496, "KVM: x86/mmu: Drop/zap existing present SPTE even when creating an MMIO SPTE", 2026-03-27). The flow is as follows: - a PDE is installed for a 2MB mapping, and a page in that area is accessed. KVM creates a kvm_mmu_page consisting of 512 4KB pages; the kvm_mmu_page is marked by FNAME(fetch) as direct-mapped because the guest's mapping is a huge page (and thus contiguous). - the PDE mapping is changed from outside the guest. - the guest accesses another page in the same 2MB area. KVM installs a new leaf SPTE and rmap entry; the SPTE uses the "correct" GFN (i.e. based on the new mapping, as changed in the previous step) but that GFN is outside of the [sp->gfn, sp->gfn + 511] range; therefore the rmap entry cannot be found and removed when the kvm_mmu_page is zapped. - the memslot that covers the first 2MB mapping is deleted, and the kvm_mmu_page for the now-invalid GPA is zapped. However, rmap_remove() only looks at the [sp->gfn, sp->gfn + 511] range established in step 1, and fails to find the rmap entry that was recorded by step 3. - any operation that causes an rmap walk for the same page accessed by step 3 then walks a stale rmap and dereferences a freed kvm_mmu_page. This includes dirty logging or MMU notifier invalidations (e.g., from MADV_DONTNEED). The underlying issue is that KVM's walking of shadow PTEs assumes that if a SPTE is present when KVM wants to install a non-leaf SPTE, then the existing kvm_mmu_page must be for the correct gfn. Because the only way for the gfn to be wrong is if KVM messed up and failed to zap a SPTE... which shouldn't happen, but *actually* only happens in response to a guest write. That bug dates back literally forever, as even the first version of KVM assumes that the GFN matches and walks into the "wrong" shadow page. However, that was only an imprecision until 2032a93d66fa ("KVM: MMU: Don't allocate gfns page for direct mmu pages") came along. Fix it by checking for a target gfn mismatch and zapping the existing SPTE. That way the old SP and rmap entries are gone, KVM installs the rmap in the right location, and everyone is happy.
Priority
LOW
Exploitation
NONE
PoC
YES
Patch
AVAILABLE
Momentum
STABLE
If you run products in this scope, you should treat this CVE as relevant to your environment.
1 version affected across 1 product
| Date | Total | Labels |
|---|
| 2026-07-06 | 1 | Disclosure1 |
| 2026-07-07 | 2 | Disclosure1General1 |
| 2026-07-10 | 2 | Patch2 |
@IntCyberDigest This is an older exploit, part of Google's kvmCTF. CVE-2026-46113 is worth a read for some more context on the underlying KVM vulnerability. Creative exploit. https://lists.openwall.net/linux-cve-announce/2026/05/28/17
16 let stará chyba v Linux KVM umožňuje útěk hostovaného VM na hostitele Nově zveřejněná zranitelnost s přezdívkou Januscape, evidovaná jako CVE-2026-53359, ukazuje, jak dlouho se může závažná chyba skrývat v základní infrastruktuře. Bezpečnostní výzkumník Hyunwoo Kim objevil chybu typu use-after-free v kódu shadow MMU hypervizoru KVM v Linuxu — kódu, který sdílejí implementace pro Intel i AMD x86. Podle Kima jde o první veřejně známý únik z hosta na hostitele (guest-to-host escape), který funguje na obou platformách, a samotná chyba se v jádru zřejmě skrývala nepovšimnuta od zhruba roku 2010. Chyba byla původně nahlášena v rámci programu Google kvmCTF, který za prokázané úniky z hosta na hostitele nabízí odměnu až 250 000 dolarů. Technicky problém spočívá v tom, jak KVM spravuje tzv. "shadow pages" (stínové stránky) — interní struktury, kterými si mapuje rozvržení paměti hostovaného VM. Když KVM takovou stránku potřebuje, hledá, zda může znovu použít nějakou existující. Chybná kontrola ale stránky porovnávala pouze podle paměťové adresy (gfn) a ignorovala jejich "roli", takže se mohly zaměnit dva strukturálně odlišné typy stránek. Tato záměna naruší interní evidenci KVM. Ve většině případů jádro nesrovnalost odhalí a raději samo spadne, aby se ochránilo — přesně to dělá veřejně dostupný proof-of-concept: škodlivý host dokáže shodit celý hostitelský server a s ním i všechny ostatní VM na stejném stroji. Ve vzácnějším a nebezpečnějším scénáři je uvolněná stránka přidělena k jinému účelu dřív, než proběhne úklid, což způsobí zápis do paměti, kterou už jádro nevlastní. Podle Kima lze z tohoto omezeného přístupu vybudovat plnohodnotné spuštění kódu na hostiteli, tento exploit však zatím nebyl zveřejněn. Zneužití vyžaduje na straně hosta dvě podmínky: root přístup uvnitř VM (běžný u pronajatých cloudových instancí) a hostitelem povolenou vnořenou virtualizaci (nested virtualization). Důležité je, že i hostitelé, kteří běžně využívají hardwarově akcelerované stránkování (Intel EPT / AMD NPT), se při zapnuté vnořené virtualizaci vracejí ke zranitelné starší cestě shadow MMU, a útok navíc nevyžaduje žádnou součinnost QEMU ani jiné userspace komponenty. Na distribucích, kde je /dev/kvm zapisovatelné pro kohokoliv (např. RHEL), Kim upozorňuje, že stejnou chybu lze zneužít i k lokální eskalaci práv na root. Januscape je již třetí Kimovo odhalení chyby v jádru Linuxu za zhruba dva měsíce, po Dirty Frag (řetězec zápisů do page cache, zveřejněný v květnu) a ITScape, prvním veřejně demonstrovaném úniku z hosta na hostitele na KVM/arm64 (zveřejněný v červnu). Navazuje také na příbuznou, ale odlišnou chybu use-after-free ve shadow MMU, CVE-2026-46113, opravenou v květnu 2026 — tato starší část kódu tak za necelých šedesát dní přinesla už dvě samostatné chyby typu use-after-free. Opravu napsal správce KVM Paolo Bonzini a přidává jediný řádek kontroly, díky němuž se stínová stránka znovu použije pouze tehdy, pokud se shoduje jak její paměťová adresa, tak role. Do hlavní vývojové větve byla začleněna 19. června 2026 jako commit 81ccda30b4e8. Opravené stabilní verze jádra vyšly 4. července 2026 (7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211 a 5.10.260), zatím jim ale NVD nepřiřadila skóre CVSS. Protože backporty distribucí mohou opravu nést pod jiným číslem verze, správci by měli ověřit přítomnost konkrétního commitu, a nespoléhat jen na uname -r. Kdo nemůže záplatovat okamžitě, může riziko zmírnit vypnutím vnořené virtualizace (kvm_intel.nested=0 nebo kvm_amd.nested=0) pro nedůvěryhodné hosty. Chyba Januscape se netýká hostitelů s architekturou ARM64, ta je ale zasažena samostatnou zranitelností ITScape (CVE-2026-46316) na KVM/arm64.
Post summary
The article discloses a serious KVM use‑after‑free vulnerability (Januscape/CVE‑2026‑53359), provides technical details, a PoC reference, and patch information, but no active exploitation or countermeasures beyond the fix.
Wow… an AI agent escaped Google's live kvmCTF host?! CVE-2026-46113, a 14,338-line nested-KVM harness, and a 3-byte VMREAD for the untracked write. "Just sandbox it" got a lot harder. https://pwn.ai/blog/kvmescape
🚨 New Linux kernel KVM/x86 MMU vulnerability: Januscape (CVE-2026-46113). Potential impact includes host DoS, local privilege escalation, and guest-to-host escape. We'll be live tomorrow at 2PM ET with all the details. 🔴 Watch here: https://www.youtube.com/live/DZgjh_K13qY?si=WS0tDF_su44w4ixe
Post summary
A new Linux kernel KVM/x86 MMU vulnerability (CVE-2026-46113) has been announced, detailing potential impacts including host DoS, local privilege escalation, and guest-to-host escape. No PoC, exploit code, or patch information is provided.
👻Third CVE this week, but good news: 𝐂𝐨𝐳𝐲𝐬𝐭𝐚𝐜𝐤 𝐢𝐬𝐧'𝐭 𝐞𝐱𝐩𝐨𝐬𝐞𝐝 𝐛𝐲 𝐝𝐞𝐬𝐢𝐠𝐧 and the fix is the same v1.13.6 upgrade you already know. Details below👇 𝐒𝐞𝐜𝐮𝐫𝐢𝐭𝐲 𝐀𝐝𝐯𝐢𝐬𝐨𝐫𝐲: 𝐂𝐕𝐄-𝟐𝟎𝟐𝟔-𝟒𝟑𝟒𝟗𝟗 ("𝐆𝐡𝐨𝐬𝐭𝐋𝐨𝐜𝐤") — 𝐂𝐨𝐳𝐲𝐬𝐭𝐚𝐜𝐤 𝐄𝐱𝐩𝐨𝐬𝐮𝐫𝐞 𝐀𝐬𝐬𝐞𝐬𝐬𝐦𝐞𝐧𝐭 On July 7, 2026, a critical Linux kernel local privilege escalation — 𝐂𝐕𝐄-𝟐𝟎𝟐𝟔-𝟒𝟑𝟒𝟗𝟗 ("GhostLock") — was disclosed with a working proof-of-concept. It is a stack use-after-free in the kernel real-time mutex (𝚛𝚝𝚖𝚞𝚝𝚎𝚡) priority-inheritance path, reachable from 𝚏𝚞𝚝𝚎𝚡(𝟸): on the proxy-lock rollback taken from 𝚏𝚞𝚝𝚎𝚡_𝚛𝚎𝚚𝚞𝚎𝚞𝚎(), 𝚛𝚎𝚖𝚘𝚟𝚎_𝚠𝚊𝚒𝚝𝚎𝚛() clears 𝚙𝚒_𝚋𝚕𝚘𝚌𝚔𝚎𝚍_𝚘𝚗 on the wrong task, leaving a dangling pointer to a freed kernel stack frame. Introduced in Linux 2.6.39 (2011), it affects every kernel up to v7.1-rc1, needs only 𝙲𝙾𝙽𝙵𝙸𝙶_𝙵𝚄𝚃𝙴𝚇_𝙿𝙸=𝚢 (no capabilities, no user namespaces), and can be escalated into a 𝐜𝐨𝐧𝐭𝐚𝐢𝐧𝐞𝐫 𝐞𝐬𝐜𝐚𝐩𝐞 — an unprivileged local process reaching root on the host kernel. The upstream fix is commit 𝟹𝚋𝚏𝚍𝚌𝟼𝟹𝟿𝟹𝟼𝚍𝚍, shipped in stable kernels 𝟔.𝟏.𝟏𝟕𝟓, 𝟔.𝟔.𝟏𝟒𝟎, 𝟔.𝟏𝟐.𝟖𝟔, 𝟔.𝟏𝟖.𝟐𝟕, 𝐚𝐧𝐝 𝟕.𝟎.𝟒. Reference: https://nvd.nist.gov/vuln/detail/CVE-2026-43499 𝐂𝐨𝐧𝐟𝐢𝐫𝐦𝐞𝐝 𝐧𝐨𝐭 𝐚𝐟𝐟𝐞𝐜𝐭𝐞𝐝 GhostLock is a local escalation: it presupposes the attacker can already run native code on the host kernel's syscall surface. By design, Cozystack gives tenants no way to do that. 𝐌𝐚𝐧𝐚𝐠𝐞𝐝 𝐊𝐮𝐛𝐞𝐫𝐧𝐞𝐭𝐞𝐬 𝐚𝐧𝐝 𝐕𝐢𝐫𝐭𝐮𝐚𝐥𝐌𝐚𝐜𝐡𝐢𝐧𝐞 𝐬𝐞𝐫𝐯𝐢𝐜𝐞𝐬. All tenant workloads execute inside guest virtual machines running on top of unprivileged containers. Tenant code has no direct access to the host kernel syscall surface — a futex sequence issued inside a guest reaches the guest kernel, not the host. 𝐌𝐚𝐧𝐚𝐠𝐞𝐝 𝐝𝐚𝐭𝐚𝐛𝐚𝐬𝐞𝐬 run as non-root, non-superuser users, with no Kubernetes API access and no ability to execute arbitrary code in the server process, so a tenant cannot issue the syscall sequence the exploit requires. 𝐍𝐨 𝐚𝐫𝐛𝐢𝐭𝐫𝐚𝐫𝐲 𝐭𝐞𝐧𝐚𝐧𝐭 𝐜𝐨𝐝𝐞 𝐨𝐧 𝐭𝐡𝐞 𝐦𝐚𝐧𝐚𝐠𝐞𝐦𝐞𝐧𝐭 𝐜𝐥𝐮𝐬𝐭𝐞𝐫. Cozystack exposes only the managed services we provide — there is no surface on which a tenant runs arbitrary native code in a container on a management node. By the design of Cozystack, we currently do not see any viable attack path that would allow a tenant to reach the host kernel surface affected by this vulnerability. 𝐑𝐞𝐜𝐨𝐦𝐦𝐞𝐧𝐝𝐞𝐝 𝐚𝐜𝐭𝐢𝐨𝐧 — 𝐬𝐚𝐦𝐞 𝐚𝐬 𝐉𝐚𝐧𝐮𝐬𝐜𝐚𝐩𝐞: 𝐮𝐩𝐠𝐫𝐚𝐝𝐞 𝐭𝐡𝐞 𝐤𝐞𝐫𝐧𝐞𝐥 The vulnerability is confirmed in current Talos Linux releases, and any future regression in the isolation above could re-expose it — so we recommend applying the kernel fix regardless. GhostLock is fixed in Talos Linux 𝐯𝟏.𝟏𝟑.𝟔 (𝐤𝐞𝐫𝐧𝐞𝐥 𝟔.𝟏𝟖.𝟑𝟖-𝐭𝐚𝐥𝐨𝐬, newer than the first fixed 𝟼.𝟷𝟾.𝟸𝟽). This is the 𝐬𝐚𝐦𝐞 𝐮𝐩𝐠𝐫𝐚𝐝𝐞 we recommended for CVE-2026-53359 ("Januscape") and CVE-2026-46113 — one move to v1.13.6 closes all three. 𝐀𝐥𝐫𝐞𝐚𝐝𝐲 𝐮𝐩𝐠𝐫𝐚𝐝𝐞𝐝 𝐭𝐨 𝐯𝟏.𝟏𝟑.𝟔 𝐟𝐨𝐫 𝐉𝐚𝐧𝐮𝐬𝐜𝐚𝐩𝐞? 𝐘𝐨𝐮 𝐚𝐫𝐞 𝐩𝐫𝐨𝐭𝐞𝐜𝐭𝐞𝐝 — 𝐧𝐨 𝐟𝐮𝐫𝐭𝐡𝐞𝐫 𝐚𝐜𝐭𝐢𝐨𝐧 𝐧𝐞𝐞𝐝𝐞𝐝. 𝐍𝐨𝐭 𝐲𝐞𝐭? Follow the same runbook: build an Image Factory installer with your extensions, upgrade node-by-node to 𝚟𝟷.𝟷𝟹.𝟼, and verify 𝚝𝚊𝚕𝚘𝚜𝚌𝚝𝚕 𝚛𝚎𝚊𝚍 /𝚙𝚛𝚘𝚌/𝚜𝚢𝚜/𝚔𝚎𝚛𝚗𝚎𝚕/𝚘𝚜𝚛𝚎𝚕𝚎𝚊𝚜𝚎 𝚜𝚑𝚘𝚠𝚜 𝟼.𝟷𝟾.𝟹𝟾–𝚝𝚊𝚕𝚘𝚜. Move one node at a time, waiting for etcd quorum and storage health between control-plane nodes. If you cannot upgrade immediately, 𝚔𝚎𝚛𝚗𝚎𝚕.𝚛𝚊𝚗𝚍𝚘𝚖𝚒𝚣𝚎_𝚔𝚜𝚝𝚊𝚌𝚔_𝚘𝚏𝚏𝚜𝚎𝚝=𝟷 (via 𝚖𝚊𝚌𝚑𝚒𝚗𝚎.𝚜𝚢𝚜𝚌𝚝𝚕𝚜) reduces the exploit's reliability as a defense-in-depth measure — not a substitute for the fix. We will update this advisory as fixed releases and further mitigations are confirmed.
Post summary
CVE‑2026‑43499 is a kernel local privilege escalation fixed by upgrading to Talos Linux v1.13.6; a PoC exists but there is no evidence of active exploitation due to Cozystack isolation.
🛠 𝐔𝐩𝐝𝐚𝐭𝐞 𝐨𝐧 𝐂𝐕𝐄-𝟐𝟎𝟐𝟔-𝟓𝟑𝟑𝟓𝟗 ("𝐉𝐚𝐧𝐮𝐬𝐜𝐚𝐩𝐞"): 𝐭𝐡𝐞 𝐩𝐫𝐨𝐩𝐞𝐫 𝐟𝐢𝐱 𝐢𝐬 𝐡𝐞𝐫𝐞 Hi everyone. Our earlier mitigation was a hotfix, a temporary and forced measure. The proper fix is now available, so the hotfix is no longer needed. 𝐓𝐋;𝐃𝐑: Disabling nested virtualization is no longer needed. It was a hotfix, and for some setups it wasn't even possible. The real fix is a kernel bump. If you already applied it, roll it back and upgrade instead. Generic Linux: make sure you're on Linux 6.18.38 or newer (with the fixes). Safe kernel versions across all branches: 6.1.177 · 6.6.144 · 6.12.95 · 6.18.38 · 7.1.3 · 7.2-rc1 For Talos, follow the runbook below👇 💊 𝐅𝐢𝐱𝐢𝐧𝐠 𝐂𝐕𝐄-𝟐𝟎𝟐𝟔-𝟓𝟑𝟑𝟓𝟗 (𝐉𝐚𝐧𝐮𝐬𝐜𝐚𝐩𝐞) + 𝐂𝐕𝐄-𝟐𝟎𝟐𝟔-𝟒𝟔𝟏𝟏𝟑 𝐨𝐧 𝐓𝐚𝐥𝐨𝐬 𝐋𝐢𝐧𝐮𝐱 𝐂𝐨𝐧𝐭𝐞𝐱𝐭 CVE-2026-53359 (Januscape) and CVE-2026-46113 are KVM x86 shadow-paging use-after-free bugs that let a guest VM escape to the host. Both are fixed in Linux 6.18.38, which ships in Talos v1.13.6. Upgrading to it closes both at the kernel level — you do not need to disable nested virtualization. 𝐓𝐡𝐞 𝐜𝐨𝐦𝐦𝐨𝐧𝐥𝐲 𝐬𝐮𝐠𝐠𝐞𝐬𝐭𝐞𝐝 𝐜𝐨𝐧𝐟𝐢𝐠 𝐦𝐢𝐭𝐢𝐠𝐚𝐭𝐢𝐨𝐧: 𝚖𝚊𝚌𝚑𝚒𝚗𝚎.𝚒𝚗𝚜𝚝𝚊𝚕𝚕.𝚎𝚡𝚝𝚛𝚊𝙺𝚎𝚛𝚗𝚎𝚕𝙰𝚛𝚐𝚜: [𝚔𝚟𝚖_𝚒𝚗𝚝𝚎𝚕.𝚗𝚎𝚜𝚝𝚎𝚍=𝟶, 𝚔𝚟𝚖_𝚊𝚖𝚍.𝚗𝚎𝚜𝚝𝚎𝚍=𝟶] — 𝐢𝐬 𝐬𝐢𝐥𝐞𝐧𝐭𝐥𝐲 𝐢𝐠𝐧𝐨𝐫𝐞𝐝 𝐨𝐧 𝐬𝐲𝐬𝐭𝐞𝐦𝐝-𝐛𝐨𝐨𝐭 / 𝐔𝐊𝐈 𝐧𝐨𝐝𝐞𝐬 (the usual bare-metal UEFI case): 𝚔𝚟𝚖_𝚒𝚗𝚝𝚎𝚕/𝚔𝚟𝚖_𝚊𝚖𝚍 are built into the Talos kernel, so 𝚖𝚘𝚍𝚙𝚛𝚘𝚋𝚎.𝚍 and runtime /𝚜𝚢𝚜 writes don’t apply (/𝚜𝚢𝚜/𝚖𝚘𝚍𝚞𝚕𝚎/𝚔𝚟𝚖_𝚒𝚗𝚝𝚎𝚕/𝚙𝚊𝚛𝚊𝚖𝚎𝚝𝚎𝚛𝚜/𝚗𝚎𝚜𝚝𝚎𝚍 is 𝟶𝟺𝟺𝟺); 𝚗𝚎𝚜𝚝𝚎𝚍= is settable only via the kernel command line. On systemd-boot the cmdline is baked into the signed UKI, so 𝚎𝚡𝚝𝚛𝚊𝙺𝚎𝚛𝚗𝚎𝚕𝙰𝚛𝚐𝚜 are dropped (Talos warns 𝚎𝚡𝚝𝚛𝚊 𝚔𝚎𝚛𝚗𝚎𝚕 𝚊𝚛𝚐𝚞𝚖𝚎𝚗𝚝𝚜 𝚊𝚛𝚎 𝚗𝚘𝚝 𝚜𝚞𝚙𝚙𝚘𝚛𝚝𝚎𝚍 𝚠𝚑𝚎𝚗 𝚋𝚘𝚘𝚝𝚒𝚗𝚐 𝚞𝚜𝚒𝚗𝚐 𝚂𝙳𝙱𝚘𝚘𝚝). 𝚐𝚛𝚞𝚋𝚄𝚜𝚎𝚄𝙺𝙸𝙲𝚖𝚍𝚕𝚒𝚗𝚎: 𝚏𝚊𝚕𝚜𝚎 only helps GRUB nodes. So the fix is a kernel bump, not a config knob. 𝐑𝐮𝐧𝐛𝐨𝐨𝐤 1. Build an Image Factory schematic with your extensions If your nodes use system extensions (drbd, zfs, firmware, GPU, ucode), declare them — Image Factory assembles the stock installer plus the official extensions, no custom image build required. 𝚌𝚊𝚝 > 𝚜𝚌𝚑𝚎𝚖𝚊𝚝𝚒𝚌.𝚢𝚊𝚖𝚕 <<'𝚈𝙰𝙼𝙻' 𝚌𝚞𝚜𝚝𝚘𝚖𝚒𝚣𝚊𝚝𝚒𝚘𝚗: 𝚜𝚢𝚜𝚝𝚎𝚖𝙴𝚡𝚝𝚎𝚗𝚜𝚒𝚘𝚗𝚜: 𝚘𝚏𝚏𝚒𝚌𝚒𝚊𝚕𝙴𝚡𝚝𝚎𝚗𝚜𝚒𝚘𝚗𝚜: – 𝚜𝚒𝚍𝚎𝚛𝚘𝚕𝚊𝚋𝚜/𝚍𝚛𝚋𝚍 – 𝚜𝚒𝚍𝚎𝚛𝚘𝚕𝚊𝚋𝚜/𝚣𝚏𝚜 – 𝚜𝚒𝚍𝚎𝚛𝚘𝚕𝚊𝚋𝚜/𝚊𝚖𝚍–𝚞𝚌𝚘𝚍𝚎 – 𝚜𝚒𝚍𝚎𝚛𝚘𝚕𝚊𝚋𝚜/𝚒𝚗𝚝𝚎𝚕–𝚞𝚌𝚘𝚍𝚎 – 𝚜𝚒𝚍𝚎𝚛𝚘𝚕𝚊𝚋𝚜/𝚊𝚖𝚍𝚐𝚙𝚞 – 𝚜𝚒𝚍𝚎𝚛𝚘𝚕𝚊𝚋𝚜/𝚒𝟿𝟷𝟻 – 𝚜𝚒𝚍𝚎𝚛𝚘𝚕𝚊𝚋𝚜/𝚋𝚗𝚡𝟸–𝚋𝚗𝚡𝟸𝚡 – 𝚜𝚒𝚍𝚎𝚛𝚘𝚕𝚊𝚋𝚜/𝚒𝚗𝚝𝚎𝚕–𝚒𝚌𝚎–𝚏𝚒𝚛𝚖𝚠𝚊𝚛𝚎 – 𝚜𝚒𝚍𝚎𝚛𝚘𝚕𝚊𝚋𝚜/𝚚𝚕𝚘𝚐𝚒𝚌–𝚏𝚒𝚛𝚖𝚠𝚊𝚛𝚎 𝚈𝙰𝙼𝙻 𝚌𝚞𝚛𝚕 –𝚜𝚇 𝙿𝙾𝚂𝚃 ––𝚍𝚊𝚝𝚊–𝚋𝚒𝚗𝚊𝚛𝚢 @𝚜𝚌𝚑𝚎𝚖𝚊𝚝𝚒𝚌.𝚢𝚊𝚖𝚕 𝚑𝚝𝚝𝚙𝚜://𝚏𝚊𝚌𝚝𝚘𝚛𝚢.𝚝𝚊𝚕𝚘𝚜.𝚍𝚎𝚟/𝚜𝚌𝚑𝚎𝚖𝚊𝚝𝚒𝚌𝚜 # –> {"𝚒𝚍":"<𝚂𝙲𝙷𝙴𝙼𝙰𝚃𝙸𝙲_𝙸𝙳>"} Trim the extension list to what your cluster actually uses. 𝟐. 𝐔𝐩𝐠𝐫𝐚𝐝𝐞 𝐧𝐨𝐝𝐞-𝐛𝐲-𝐧𝐨𝐝𝐞 𝚝𝚊𝚕𝚘𝚜𝚌𝚝𝚕 –𝚗 <𝙽𝙾𝙳𝙴_𝙸𝙿> 𝚞𝚙𝚐𝚛𝚊𝚍𝚎 \ ––𝚒𝚖𝚊𝚐𝚎 𝚏𝚊𝚌𝚝𝚘𝚛𝚢.𝚝𝚊𝚕𝚘𝚜.𝚍𝚎𝚟/𝚒𝚗𝚜𝚝𝚊𝚕𝚕𝚎𝚛/<𝚂𝙲𝙷𝙴𝙼𝙰𝚃𝙸𝙲_𝙸𝙳>:𝚟𝟷.𝟷𝟹.𝟼 Roll one node at a time; on control-plane nodes wait for etcd and your CSI/storage to be healthy between nodes. Talos only tests migrations between adjacent minors — from an old release, upgrade sequentially through each minor’s latest patch rather than jumping straight. 𝟑. 𝐕𝐞𝐫𝐢𝐟𝐲 𝚝𝚊𝚕𝚘𝚜𝚌𝚝𝚕 –𝚗 <𝙽𝙾𝙳𝙴_𝙸𝙿> 𝚟𝚎𝚛𝚜𝚒𝚘𝚗 # 𝚂𝚎𝚛𝚟𝚎𝚛: 𝚟𝟷.𝟷𝟹.𝟼 𝚝𝚊𝚕𝚘𝚜𝚌𝚝𝚕 –𝚗 <𝙽𝙾𝙳𝙴_𝙸𝙿> 𝚛𝚎𝚊𝚍 /𝚙𝚛𝚘𝚌/𝚜𝚢𝚜/𝚔𝚎𝚛𝚗𝚎𝚕/𝚘𝚜𝚛𝚎𝚕𝚎𝚊𝚜𝚎 # 𝟼.𝟷𝟾.𝟹𝟾–𝚝𝚊𝚕𝚘𝚜 𝚝𝚊𝚕𝚘𝚜𝚌𝚝𝚕 –𝚗 <𝙽𝙾𝙳𝙴_𝙸𝙿> 𝚐𝚎𝚝 𝚎𝚡𝚝𝚎𝚗𝚜𝚒𝚘𝚗𝚜 # 𝚢𝚘𝚞𝚛 𝚎𝚡𝚝𝚎𝚗𝚜𝚒𝚘𝚗𝚜 𝚙𝚛𝚎𝚜𝚎𝚗𝚝 𝚔𝚟𝚖_𝚒𝚗𝚝𝚎𝚕.𝚗𝚎𝚜𝚝𝚎𝚍 may stay 𝚈 — that’s expected; the vulnerable path is fixed in the kernel. Ready installer (Cozystack extension set) Standard Cozystack extensions (drbd, zfs, amd/intel-ucode, amdgpu, i915, bnx2-bnx2x, intel-ice-firmware, qlogic-firmware): 𝚏𝚊𝚌𝚝𝚘𝚛𝚢.𝚝𝚊𝚕𝚘𝚜.𝚍𝚎𝚟/𝚒𝚗𝚜𝚝𝚊𝚕𝚕𝚎𝚛/𝚋𝚎𝟼𝟼𝚏𝚍𝚌𝟾𝚊𝟹𝟾𝚌𝟸𝚏𝟻𝟷𝟽𝚏𝟹𝟹𝚌𝚋𝚊𝟶𝚊𝟼𝚍𝚊𝚊𝟽𝚊𝚋𝟿𝟽𝚏𝚏𝟾𝟽𝚍𝟻𝟷𝚎𝟾𝚌𝚊𝟽𝚍𝟸𝟷𝟼𝟶𝚎𝟺𝟻𝟿𝟷𝟷𝚋𝚊𝟶𝟿𝚌𝚏𝟻:𝚟𝟷.𝟷𝟹.𝟼 𝐑𝐞𝐟𝐞𝐫𝐞𝐧𝐜𝐞𝐬: 𝐂𝐕𝐄-𝟐𝟎𝟐𝟔-𝟓𝟑𝟑𝟓𝟗 (𝐉𝐚𝐧𝐮𝐬𝐜𝐚𝐩𝐞): https://nvd.nist.gov/vuln/detail/CVE-2026-53359 𝐂𝐕𝐄-𝟐𝟎𝟐𝟔-𝟒𝟔𝟏𝟏𝟑: https://nvd.nist.gov/vuln/detail/CVE-2026-46113 𝐓𝐚𝐥𝐨𝐬 𝐛𝐨𝐨𝐭𝐥𝐨𝐚𝐝𝐞𝐫 / 𝐔𝐊𝐈 𝐜𝐦𝐝𝐥𝐢𝐧𝐞: https://docs.siderolabs.com/talos/v1.13/platform-specific-installations/bare-metal-platforms/bootloader 𝐓𝐚𝐥𝐨𝐬 𝐈𝐦𝐚𝐠𝐞 𝐅𝐚𝐜𝐭𝐨𝐫𝐲: https://factory.talos.dev
Post summary
The post announces the final fix for CVE‑2026‑53359 (Januscape) and CVE‑2026‑46113, providing specific kernel versions and upgrade guidance, indicating a patch release rather than new exploitation or a PoC.
Januscape CVE-2026-46113: KVM/x86 Guest-to-Host Escape Explained https://x.com/i/broadcasts/1jGXggRdLlOKZ
Post summary
The tweet announces a discussion about CVE-2026-46113 related to KVM/x86 Guest-to-Host escape, linking to a broadcast, but provides no PoC, exploit, active exploitation, patch, or detailed technical information.
3 of 3 entries
| Part | Vendor | Product | Version | Target SW | Target HW |
|---|---|---|---|---|---|
| OS | linux | linux_kernel | - | - | - |
| OS | linux | linux_kernel | 7.1 | - | - |
| OS | linux | linux_kernel | 7.1 | - | - |