{"uuid": "fcd5fcc2-3d3f-4c01-ae42-dc477b014fab", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-53359", "type": "published-proof-of-concept", "source": "https://t.me/aenix_io/420", "content": "\ud83d\udea8\u00a0Security Advisory \u2014 CVE-2026-53359\u00a0(\"Januscape\"): KVM guest-to-host escape\n\n\u00b7 Severity:\u00a0High\n\u00b7 Status:\u00a0Mitigation required now\n\nWhat happened\n\nOn 2026-07-06 a Linux kernel vulnerability, CVE-2026-53359\u00a0(\"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.\n\nThe 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.\n\nWho is affected\n\nCozystack installations that run virtualization or tenant Kubernetes clusters \u2014 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.\n\nThe risk\n\nThe 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:\n\n\u00b7 crash the node kernel, taking down every co-tenant VM on that node (denial of service), or\n\n\u00b7 with a working exploit, run code on the node and compromise the cluster.\n\nKubeVirt's sandboxing (unprivileged containers, seccomp, SELinux) does not stop this \u2014 the bug is in the host kernel and is reached through the normal KVM interface every VM must use.\n\nRecommended mitigation: disable nested virtualization\n\nCozystack VMs do not need nested virtualization. Disabling it removes the attack surface entirely, regardless of kernel version.\n\nTalos (most clusters)\n\nAdd to your Talos machine config, under machine.install:\n\n  install:\n    # Talos >= 1.12 only: pin grubUseUKICmdline false so the args are applied\n    # (otherwise they are silently ignored on UEFI/UKI systems).\n    grubUseUKICmdline: false\n    extraKernelArgs:\n    - kvm_intel.nested=0\n    - kvm_amd.nested=0\n\nBoth lines are safe on Intel and AMD \u2014 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.\n\nApply it in two steps \u2014 talm apply, then\u00a0talm 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\u00a0alone does not rewrite the boot config). You can upgrade to the same Talos version you are already on \u2014 the point is to re-run the installer with the new arguments:\n\n# 1. Push the updated machine config to the node\ntalm apply -f nodes/.yaml\n\n# 2. Re-run the installer so the kernel args land in the boot config (this reboots the node)\ntalm upgrade -f nodes/.yaml\n\u26a0\ufe0f\u00a0This reboots the node.\u00a0Roll it out one node at a time, waiting for each node to become Ready\u00a0(and for etcd quorum to recover on control-plane nodes) before moving to the next.\n\nGeneric Linux hosts (non-Talos)\n\nCreate /etc/modprobe.d/cozystack-kvm-nested.conf:\n\nundefined\noptions kvm_intel nested=0\noptions kvm_amd nested=0\nThen reboot the node (or reload the\u00a0kvm\u00a0module) for it to take effect.\n\nAutomation\n\nWe 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:\n\n\u2192 https://github.com/cozystack/ccp/pull/17\n\nYou can use the\u00a0cozystack:talos-bootstrap\u00a0and cozystack:cluster-upgrade\u00a0skills to apply and verify the change automatically.\n\nAfter a fixed Talos ships\nOnce 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.", "creation_timestamp": "2026-07-30T00:00:31.318827Z"}