On 6 July 2026 the industry got the kind of vulnerability that is supposed to trigger an all-hands response: Januscape (CVE-2026-53359), a guest-to-host escape in KVM that works on both Intel and AMD, sitting in the Linux kernel for sixteen years. Forty-eight hours later, if you run Ubuntu, Debian stable, or Red Hat Enterprise Linux, you still cannot apt upgrade or dnf upgrade your way to a fixed kernel from your vendor’s main channel. That is not a good look, and it deserves to be said plainly.

We covered what Januscape is and how to mitigate it in a separate post. This one is about the response — or the lack of one.

This was not a surprise drop

The usual defence when a distro is slow is “they only just found out.” That does not apply here. The upstream fix landed in the mainline kernel on 19 June 2026 (commit 81ccda30b4e8). Public disclosure followed on 6 July. That is more than two weeks in which every major vendor’s security team could see the patch, understand the severity, and stage a backport — followed by two more days of public, sky-is-falling pressure.

A use-after-free that lets a guest escape onto the host is close to a worst-case bug for anyone running multi-tenant virtualization. The people most exposed — cloud providers, hosting companies, anyone renting out VMs — are exactly the people who cannot simply “disable nested virtualization and move on.” They needed a kernel. Two days after disclosure, the biggest names still had not handed them one.

Where the major distros actually stand

Here is the state of play as reported on 7–8 July 2026. Always confirm against your vendor’s live advisory before you act — this is a moving target — but the pattern is not flattering.

Distribution / channel Status (48h after disclosure)
Mainline / kernel.org stable ✅ Fixed — 6.1.177, 6.6.144, 6.12.95, 6.18.38, 7.1.3
Ubuntu (all releases) ❌ Vulnerable — no USN, no released kernel; livepatches still in testing
Red Hat Enterprise Linux ⚠️ Pending — fixes in a testing feed, nothing in the main channel
AlmaLinux 10 (RHEL rebuild) ✅ Fixed — patched kernel already in the main feed
Debian trixie / sid ✅ Fixed — 6.12.95-1 / 7.1.3-1
Debian bookworm (old stable line) ❌ Vulnerable — still on 6.1.176-1, no fixed build in security
Proxmox VE ❌ No fixed kernel yet — mitigation is to disable nested KVM

The most embarrassing detail

Look at the Red Hat line, then look at the AlmaLinux line. AlmaLinux — a free, community rebuild of RHEL — shipped a patched kernel to its main feed before Red Hat did. A downstream project whose entire job is to recompile Red Hat’s sources beat the vendor those sources come from. If a volunteer-driven rebuild can turn a public commit into a released, installable kernel inside the window, the “enterprise-grade QA takes time” explanation gets a lot harder to accept.

Debian’s split is instructive too. Its testing and unstable lines picked up the fix (6.12.95-1 and 7.1.3-1), while the conservative bookworm line — the one a lot of production servers actually run — was still shipping a vulnerable 6.1.176-1. The users who most value Debian’s stability are the ones left waiting the longest.

And it is worse than a slow single patch — because it is two

Here is the part that turns a delay into a genuine hazard. Januscape is not one bug. The complete upstream fix is two commits closing two CVEs in the same corner of the KVM code:

  • CVE-2026-53359 — commit 81ccda30b4e8
  • CVE-2026-46113 — commit 0cb2af2ea66a

A kernel that carries only the first commit is still exploitable through the second. And because most administrators verify remediation by looking up a single CVE ID, it is entirely possible to check “CVE-2026-53359 — fixed,” tick the box, and remain vulnerable. A rushed, partial backport that lands one commit and not the other is arguably worse than shipping nothing, because it manufactures false confidence. When the eventual vendor kernels do land, confirm both commits are present, not just the headline CVE.

What you should actually do right now

Frustration aside, waiting on your vendor is not a security posture. While the big distros catch up:

  • Disable nested virtualization on any host that does not need it — it removes the trigger condition. Set kvm_intel nested=0 (or kvm_amd nested=0) and reload the module or reboot.
  • Isolate untrusted guests. The attacker here is the guest. Multi-tenant and customer-facing hosts are the priority; do not run untrusted workloads on an unpatched hypervisor.
  • Consider a livepatch service or a mainline/vendor testing kernel if your risk justifies it — but validate it in staging first, and make sure it closes both CVEs.
  • Live-migrate guests off a node so you can patch and reboot it without downtime, the moment a fixed kernel is available for your distro.
  • Track your vendor’s advisory page, not a news headline — and re-check, because “pending” today can become “released” tomorrow.

The bigger point

Distributions ask for — and largely deserve — trust. The bargain is that when something catches fire, the people packaging your kernel move fast on your behalf. Januscape is the exact scenario that bargain exists for: a critical, weaponized, publicly-known VM escape with an upstream fix already in hand. Two weeks of lead time before disclosure, then forty-eight hours of open alarm, and the answer from the largest vendors was a testing feed and an empty changelog.

The kernel developers did their job — the fix was written, reviewed and merged. Community rebuilds and Debian’s fast lanes did theirs. The gap is in the last mile: turning a known-good commit into a released, installable kernel for the paying enterprise customers who are most exposed. On a bug this severe, “soon” is not an SLA. Ship the kernel.

Patch-status details reflect public reporting on 7–8 July 2026 and change quickly. Verify against your distribution’s official security advisory before making remediation decisions. This post is commentary on release timing, not a claim about any vendor’s internal process.