cozystack · Andrei Kvapil (kvaps) · Jul 9, 2026 · Jul 9, 2026 · Jul 9, 2026 · Jul 9, 2026
@@ -3,7 +3,7 @@ title: "Security Advisory — CVE-2026-53359 (\"Januscape\"): KVM Guest-to-Host
 slug: security-advisory-cve-2026-53359-januscape-kvm-guest-to-host-escape
 date: 2026-07-08
 author: "Cozystack Team"
-description: "CVE-2026-53359 (\"Januscape\") is a KVM guest-to-host escape affecting all current Talos kernels. Cozystack clusters that run VMs or tenant Kubernetes should disable nested virtualization now."
+description: "CVE-2026-53359 (\"Januscape\") is a KVM guest-to-host escape. It is fixed in the kernel: Talos v1.13.6 ships Linux 6.18.38, which carries the patches for this and the related CVE-2026-46113. Upgrade — nested virtualization stays available."
 images:
   - "cve-2026-53359-banner.png"
 article_types:
@@ -15,13 +15,17 @@ topics:
 
 {{< figure src="cve-2026-53359-banner.png" alt="Security advisory banner — CVE-2026-53359 Januscape KVM guest-to-host escape" width="720" >}}
 
-**Severity:** High for clusters running virtualization. **Status:** No fixed Talos release yet — mitigation required now.
+**Update, 2026-07-09.** Talos v1.13.6 has shipped with the fixed kernel. This advisory originally recommended disabling KVM nested virtualization, because at the time no fixed Talos release existed. That recommendation is superseded: upgrade to Talos v1.13.6 or newer and keep nested virtualization enabled. Disabling it remains a stop-gap for clusters that cannot upgrade yet.
+
+**Severity:** High for clusters running virtualization. **Status:** Fixed in Talos v1.13.6 (Linux 6.18.38), released 2026-07-09.
 
 ## What happened
 
 On 2026-07-06 a Linux kernel vulnerability, **CVE-2026-53359** ("Januscape"), was publicly disclosed together with a working exploit. It is a use-after-free in the KVM/x86 shadow MMU that lets a **guest VM break out to its host** (the cluster node) or crash the node's kernel. It affects both Intel and AMD CPUs and has been latent in the kernel since 2010.
 
-The upstream fix shipped in stable kernels (6.18.38, 6.12.95, 6.6.144, 6.1.177, 7.1.3) on 2026-07-04, but **Talos Linux has not yet released an image with the fixed kernel.** Every current Talos version still runs a vulnerable kernel.
+The upstream fix shipped in stable kernels (6.18.38, 6.12.95, 6.6.144, 6.1.177, 7.1.3) on 2026-07-04. **Talos v1.13.6**, released on 2026-07-09, is the first Talos release to carry it.
+
+CVE-2026-53359 has a sibling: **CVE-2026-46113**, the same class of use-after-free in the same code path, fixed by a separate upstream patch. A kernel is only fully fixed once it carries both — in the 6.18 series that means 6.18.38 or newer (CVE-2026-46113 landed in 6.18.30), in the 6.12 series 6.12.95 or newer (it landed in 6.12.88). No release on the Talos 1.10, 1.11 or 1.12 lines carries both: the newest of each ships Linux 6.12.63, 6.12.62 and 6.18.35 respectively, and there is no fixed release planned for those lines.
 
 ## Who is affected
 
@@ -36,9 +40,19 @@ The exploit needs two things a tenant already has: root inside their own VM, and
 
 KubeVirt's sandboxing (unprivileged containers, seccomp, SELinux) does **not** stop this — the bug is in the host kernel and is reached through the normal KVM interface every VM must use.
 
-## Recommended mitigation: disable nested virtualization
+## Recommended fix: upgrade Talos
+
+Upgrade nodes to **Talos v1.13.6** or newer. The bug is fixed in the kernel, so nested virtualization stays enabled and workloads that rely on it keep working.
+
+Only the 1.13 line has a fixed release. A cluster on Talos 1.10, 1.11 or 1.12 has to move to the 1.13 line to reach the fix; for Cozystack clusters that means upgrading to a release that installs from it.
 
-Cozystack VMs do not need nested virtualization. Disabling it removes the attack surface entirely, regardless of kernel version.
+Hosts that do not run Talos need a kernel carrying both patches — take your distribution's kernel update.
+
+**Warning: upgrading reboots the node.** Roll it out **one node at a time**, waiting for each node to become `Ready` (and for etcd quorum to recover on control-plane nodes) before moving to the next.
+
+## If you cannot upgrade yet: disable nested virtualization
+
+The published exploit reaches the bug through nested virtualization exposed to the guest. Disabling it closes that entry point. This is a stop-gap, not a fix — the kernel bug is still there — and it takes the feature away from any workload that needs it.
 
 ### Talos (most clusters)
 
@@ -47,15 +61,20 @@ Add to your Talos machine config, under `machine.install`:
 ```yaml
 machine:
   install:
-    # Talos >= 1.12 only: pin grubUseUKICmdline false so the args are applied
-    # (otherwise they are silently ignored on UEFI/UKI systems).
+    # Talos >= 1.12 only: `talosctl gen config` writes this as true, and Talos
+    # refuses a config that carries both it and extraKernelArgs. The field does
+    # not exist before 1.12, and it has no effect on systemd-boot nodes.
     grubUseUKICmdline: false
     extraKernelArgs:
     - kvm_intel.nested=0
     - kvm_amd.nested=0
 ```
 
-Both lines are safe on Intel and AMD — the one that does not match your CPU is ignored. On Talos **older than 1.12** the `grubUseUKICmdline` field does not exist and `extraKernelArgs` is ignored on UEFI/UKI nodes; there the args must be baked into the boot image via Image Factory.
+Both lines are safe on Intel and AMD — the one that does not match your CPU is ignored.
+
+Two caveats, and they fail differently. On Talos 1.12 and newer, omitting `grubUseUKICmdline: false` does not quietly drop the arguments — Talos rejects the whole config with `install.extraKernelArgs and install.grubUseUKICmdline can't be used together`. Before 1.12 the field does not exist and is not needed.
+
+**The second caveat is the quiet one.** These arguments only take effect on GRUB-booted nodes. A fresh UEFI install of Talos 1.10 or newer boots through systemd-boot, where the kernel command line lives inside the Unified Kernel Image; there Talos accepts the arguments and then ignores them, reporting nothing, and `grubUseUKICmdline` does not help because there is no GRUB. Clusters upgraded into 1.10 keep their existing GRUB bootloader and are unaffected. On systemd-boot nodes the arguments have to be baked into the boot assets via Image Factory or Imager. After applying either way, confirm on the node with `cat /proc/cmdline` rather than assuming it took.
 
 **Apply it in two steps — `talm apply`, then `talm upgrade`.** First push the updated machine config to the node, then re-run the Talos installer so the kernel arguments are written into the boot configuration (a plain `talm apply` alone does not rewrite the boot config). You can upgrade to the *same* Talos version you are already on — the point is to re-run the installer with the new arguments:
 
@@ -67,29 +86,19 @@ talm apply -f nodes/<node>.yaml
 talm upgrade -f nodes/<node>.yaml
 ```
 
-**Warning: this reboots the node.** Roll it out **one node at a time**, waiting for each node to become `Ready` (and for etcd quorum to recover on control-plane nodes) before moving to the next.
+**Warning: `talm upgrade` reboots the node.** Roll it out one node at a time, as above.
 
 ### Generic Linux hosts (non-Talos)
 
 Create `/etc/modprobe.d/cozystack-kvm-nested.conf`:
 
-```
+```text
 options kvm_intel nested=0
 options kvm_amd nested=0
 ```
 
 Then reboot the node (or reload the `kvm` module) for it to take effect.
 
-## Automation
-
-We have updated our Cozystack Claude Code skills to prescribe and verify this mitigation during bootstrap and upgrades, so the setting is placed under `machine.install` and persists across future Talos upgrades: [cozystack/ccp#17](https://github.com/cozystack/ccp/pull/17).
-
-You can use the `cozystack:talos-bootstrap` and `cozystack:cluster-upgrade` skills to apply and verify the change automatically.
-
-## After a fixed Talos ships
-
-Once Talos releases an image with the patched kernel (6.18.38 or newer), upgrade normally. You may keep nested virtualization disabled as a hardening measure, or re-enable it (remove the two arguments) if a specific workload requires it. We will notify you when a fixed Talos release is available.
-
 ## Join the community
 
 * GitHub: [cozystack/cozystack](https://github.com/cozystack/cozystack)

@@ -102,8 +102,12 @@ talos-bootstrap --help
         - 10.96.0.0/16
     ```
 
+    {{% alert title="Update Talos to v1.13.6 or newer (CVE-2026-53359)" color="warning" %}}
+[CVE-2026-53359](/blog/2026/07/security-advisory-cve-2026-53359-januscape-kvm-guest-to-host-escape/) ("Januscape") and CVE-2026-46113 are related use-after-free bugs in the KVM x86 shadow MMU that let a guest VM escape to its host. Both are fixed in the kernel, and Talos v1.13.6 is the first release that carries both fixes — it ships Linux 6.18.38. If the image tag above resolves to an earlier release, set it to `v1.13.6` or newer. Nested virtualization stays enabled: the kernel fix removes the bug itself, so workloads that rely on nested virtualization keep working.
+    {{% /alert %}}
+
     {{% alert title="Do not change op: on these entries" color="warning" %}}
-    Talos rejects `op: create` for any file outside `/var`, returning the error `create operation not allowed outside of /var` — the only exception is the special-cased `/etc/cri/conf.d/20-customization.part`. Because `/etc/lvm/lvm.conf` already exists on the node, it must use `op: overwrite`. Changing the op (or pointing `create` at another `/etc` path) fails the `WriteUserFiles` boot step: the node pauses and enters a reboot loop, and `talosctl bootstrap` reports only `bootstrap is not available yet` with no obvious cause.
+Talos rejects `op: create` for any file outside `/var`, returning the error `create operation not allowed outside of /var` — the only exception is the special-cased `/etc/cri/conf.d/20-customization.part`. Because `/etc/lvm/lvm.conf` already exists on the node, it must use `op: overwrite`. Changing the op (or pointing `create` at another `/etc` path) fails the `WriteUserFiles` boot step: the node pauses and enters a reboot loop, and `talosctl bootstrap` reports only `bootstrap is not available yet` with no obvious cause.
     {{% /alert %}}
 
 1.  Make another configuration patch file `patch-controlplane.yaml` with settings exclusive to control plane nodes:

@@ -126,8 +126,12 @@ Discovered open port 50000/tcp on 192.168.123.13
         - 10.96.0.0/16
     ```
 
+    {{% alert title="Update Talos to v1.13.6 or newer (CVE-2026-53359)" color="warning" %}}
+[CVE-2026-53359](/blog/2026/07/security-advisory-cve-2026-53359-januscape-kvm-guest-to-host-escape/) ("Januscape") and CVE-2026-46113 are related use-after-free bugs in the KVM x86 shadow MMU that let a guest VM escape to its host. Both are fixed in the kernel, and Talos v1.13.6 is the first release that carries both fixes — it ships Linux 6.18.38. If the image tag above resolves to an earlier release, set it to `v1.13.6` or newer. Nested virtualization stays enabled: the kernel fix removes the bug itself, so workloads that rely on nested virtualization keep working.
+    {{% /alert %}}
+
     {{% alert title="Do not change op: on these entries" color="warning" %}}
-    Talos rejects `op: create` for any file outside `/var`, returning the error `create operation not allowed outside of /var` — the only exception is the special-cased `/etc/cri/conf.d/20-customization.part`. Because `/etc/lvm/lvm.conf` already exists on the node, it must use `op: overwrite`. Changing the op (or pointing `create` at another `/etc` path) fails the `WriteUserFiles` boot step: the node pauses and enters a reboot loop, and `talosctl bootstrap` reports only `bootstrap is not available yet` with no obvious cause.
+Talos rejects `op: create` for any file outside `/var`, returning the error `create operation not allowed outside of /var` — the only exception is the special-cased `/etc/cri/conf.d/20-customization.part`. Because `/etc/lvm/lvm.conf` already exists on the node, it must use `op: overwrite`. Changing the op (or pointing `create` at another `/etc` path) fails the `WriteUserFiles` boot step: the node pauses and enters a reboot loop, and `talosctl bootstrap` reports only `bootstrap is not available yet` with no obvious cause.
     {{% /alert %}}
 
 1.  Make another configuration patch file `patch-controlplane.yaml` with settings exclusive to control plane nodes:

@@ -106,6 +106,12 @@ talos-bootstrap --help
         - 10.96.0.0/16
     ```
 
+    {{% alert title="No Talos release before v1.13.6 fixes CVE-2026-53359" color="warning" %}}
+[CVE-2026-53359](/blog/2026/07/security-advisory-cve-2026-53359-januscape-kvm-guest-to-host-escape/) ("Januscape") and CVE-2026-46113 are related use-after-free bugs in the KVM x86 shadow MMU that let a guest VM escape to its host. Both fixes live in the kernel, and Talos v1.13.6 is the first release that carries them: every release of the 1.10, 1.11 and 1.12 lines is missing at least one, whichever of them this Cozystack version installs. The complete fix is Talos v1.13.6 or newer: upgrade to a Cozystack release that installs from the Talos 1.13 line, then set the Talos image tag to `v1.13.6` or newer.
+
+If you cannot upgrade and you run untrusted guests, disabling KVM nested virtualization (`kvm_intel.nested=0`, `kvm_amd.nested=0`) removes the entry point the published exploit relies on. Treat it as a stop-gap rather than a fix, and mind where it applies. On Talos 1.12 and newer, `machine.install.extraKernelArgs` also needs `machine.install.grubUseUKICmdline: false` next to it: `talosctl gen config` writes that field as `true`, and Talos rejects a config carrying both with `install.extraKernelArgs and install.grubUseUKICmdline can't be used together`. On Talos 1.10 and 1.11 the field does not exist and is not needed. That rejection is loud; the remaining failure is not. Even once the config is accepted, the arguments only reach a GRUB-booted node: a fresh UEFI install of Talos 1.10 or newer boots through systemd-boot, where the kernel command line lives inside the Unified Kernel Image, and there Talos takes the arguments without complaint and ignores them. On those nodes the arguments have to be baked into the boot assets with [Image Factory or Imager](https://www.talos.dev/v1.12/talos-guides/install/boot-assets/). Either way, check `/proc/cmdline` on the node afterwards rather than assuming the mitigation took.
+    {{% /alert %}}
+
 1.  Make another configuration patch file `patch-controlplane.yaml` with settings exclusive to control plane nodes:
 
     ```yaml

@@ -130,6 +130,12 @@ Discovered open port 50000/tcp on 192.168.123.13
         - 10.96.0.0/16
     ```
 
+    {{% alert title="No Talos release before v1.13.6 fixes CVE-2026-53359" color="warning" %}}
+[CVE-2026-53359](/blog/2026/07/security-advisory-cve-2026-53359-januscape-kvm-guest-to-host-escape/) ("Januscape") and CVE-2026-46113 are related use-after-free bugs in the KVM x86 shadow MMU that let a guest VM escape to its host. Both fixes live in the kernel, and Talos v1.13.6 is the first release that carries them: every release of the 1.10, 1.11 and 1.12 lines is missing at least one, whichever of them this Cozystack version installs. The complete fix is Talos v1.13.6 or newer: upgrade to a Cozystack release that installs from the Talos 1.13 line, then set the Talos image tag to `v1.13.6` or newer.
+
+If you cannot upgrade and you run untrusted guests, disabling KVM nested virtualization (`kvm_intel.nested=0`, `kvm_amd.nested=0`) removes the entry point the published exploit relies on. Treat it as a stop-gap rather than a fix, and mind where it applies. On Talos 1.12 and newer, `machine.install.extraKernelArgs` also needs `machine.install.grubUseUKICmdline: false` next to it: `talosctl gen config` writes that field as `true`, and Talos rejects a config carrying both with `install.extraKernelArgs and install.grubUseUKICmdline can't be used together`. On Talos 1.10 and 1.11 the field does not exist and is not needed. That rejection is loud; the remaining failure is not. Even once the config is accepted, the arguments only reach a GRUB-booted node: a fresh UEFI install of Talos 1.10 or newer boots through systemd-boot, where the kernel command line lives inside the Unified Kernel Image, and there Talos takes the arguments without complaint and ignores them. On those nodes the arguments have to be baked into the boot assets with [Image Factory or Imager](https://www.talos.dev/v1.12/talos-guides/install/boot-assets/). Either way, check `/proc/cmdline` on the node afterwards rather than assuming the mitigation took.
+    {{% /alert %}}
+
 1.  Make another configuration patch file `patch-controlplane.yaml` with settings exclusive to control plane nodes:
 
     Note that VIP address is used for `machine.network.interfaces[0].vip.ip`:

@@ -102,6 +102,12 @@ talos-bootstrap --help
         - 10.96.0.0/16
     ```
 
+    {{% alert title="No Talos release before v1.13.6 fixes CVE-2026-53359" color="warning" %}}
+[CVE-2026-53359](/blog/2026/07/security-advisory-cve-2026-53359-januscape-kvm-guest-to-host-escape/) ("Januscape") and CVE-2026-46113 are related use-after-free bugs in the KVM x86 shadow MMU that let a guest VM escape to its host. Both fixes live in the kernel, and Talos v1.13.6 is the first release that carries them: every release of the 1.10, 1.11 and 1.12 lines is missing at least one, whichever of them this Cozystack version installs. The complete fix is Talos v1.13.6 or newer: upgrade to a Cozystack release that installs from the Talos 1.13 line, then set the Talos image tag to `v1.13.6` or newer.
+
+If you cannot upgrade and you run untrusted guests, disabling KVM nested virtualization (`kvm_intel.nested=0`, `kvm_amd.nested=0`) removes the entry point the published exploit relies on. Treat it as a stop-gap rather than a fix, and mind where it applies. On Talos 1.12 and newer, `machine.install.extraKernelArgs` also needs `machine.install.grubUseUKICmdline: false` next to it: `talosctl gen config` writes that field as `true`, and Talos rejects a config carrying both with `install.extraKernelArgs and install.grubUseUKICmdline can't be used together`. On Talos 1.10 and 1.11 the field does not exist and is not needed. That rejection is loud; the remaining failure is not. Even once the config is accepted, the arguments only reach a GRUB-booted node: a fresh UEFI install of Talos 1.10 or newer boots through systemd-boot, where the kernel command line lives inside the Unified Kernel Image, and there Talos takes the arguments without complaint and ignores them. On those nodes the arguments have to be baked into the boot assets with [Image Factory or Imager](https://www.talos.dev/v1.12/talos-guides/install/boot-assets/). Either way, check `/proc/cmdline` on the node afterwards rather than assuming the mitigation took.
+    {{% /alert %}}
+
 1.  Make another configuration patch file `patch-controlplane.yaml` with settings exclusive to control plane nodes:
 
     ```yaml