feat(blog): add CVE-2026-53359 (Januscape) security advisory

content/en/blog/2026-07-07-security-advisory-cve-2026-53359-januscape-kvm-guest-to-host-escape/index.md

@@ -0,0 +1,99 @@
+---
+title: "Security Advisory — CVE-2026-53359 (\"Januscape\"): KVM Guest-to-Host Escape"
+slug: security-advisory-cve-2026-53359-januscape-kvm-guest-to-host-escape
+date: 2026-07-07
+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."
+images:
+  - "cve-2026-53359-banner.png"
+article_types:
+  - announcement
+topics:
+  - security
+  - virtualization
+---
+
+{{< 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.
+
+## 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.
+
+## Who is affected
+
+Cozystack installations that run **virtualization or tenant Kubernetes clusters** — tenant Kubernetes nodes are KubeVirt VMs, so they count. If you run only containerized workloads and never create VMs or tenant clusters, your exposure is much lower.
+
+## The risk
+
+The exploit needs two things a tenant already has: root inside their own VM, and nested virtualization exposed to the guest (on by default). A malicious tenant could then:
+
+- crash the node kernel, taking down every co-tenant VM on that node (denial of service), or
+- with a working exploit, run code on the node and compromise the cluster.
+
+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
+
+Cozystack VMs do not need nested virtualization. Disabling it removes the attack surface entirely, regardless of kernel version.
+
+### Talos (most clusters)
+
+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).
+    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.
+
+**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:
+
+```bash
+# 1. Push the updated machine config to the node
+talm apply -f nodes/<node>.yaml
+
+# 2. Re-run the installer so the kernel args land in the boot config (this reboots the node)
+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.
+
+### Generic Linux hosts (non-Talos)
+
+Create `/etc/modprobe.d/cozystack-kvm-nested.conf`:
+
+```
+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)
+* Telegram: [@cozystack](https://t.me/cozystack)
+* Slack: [#cozystack](https://kubernetes.slack.com/archives/C06L3CPRVN1) on the Kubernetes workspace ([invite](https://slack.kubernetes.io))
+* [Subscribe to our community meetings calendar](https://zoom-lfx.platform.linuxfoundation.org/meetings/cozystack)
+* [Add meetings to your calendar](https://webcal.prod.itx.linuxfoundation.org/lfx/lfsixxnFWxbvsyEuC2)