{"id":91,"date":"2026-07-08T14:00:00","date_gmt":"2026-07-08T14:00:00","guid":{"rendered":"https:\/\/backendside.com\/blog\/2026\/07\/08\/januscape-cve-2026-53359-distros-still-no-patched-kernel\/"},"modified":"2026-07-08T16:41:47","modified_gmt":"2026-07-08T16:41:47","slug":"januscape-cve-2026-53359-distros-still-no-patched-kernel","status":"publish","type":"post","link":"https:\/\/backendside.com\/blog\/2026\/07\/08\/januscape-cve-2026-53359-distros-still-no-patched-kernel\/","title":{"rendered":"48 Hours After Januscape, the Big Distros Still Haven’t Shipped a Patched Kernel"},"content":{"rendered":"

On 6 July 2026 the industry got the kind of vulnerability that is supposed to trigger an all-hands response: Januscape (CVE-2026-53359)<\/strong>, 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<\/code> or dnf upgrade<\/code> 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.<\/p>\n

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

This was not a surprise drop<\/h2>\n

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<\/strong> (commit 81ccda30b4e8<\/code>). Public disclosure followed on 6 July<\/strong>. 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.<\/p>\n

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.<\/p>\n

Where the major distros actually stand<\/h2>\n

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

The most embarrassing detail<\/h2>\n

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.<\/strong> 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.<\/p>\n

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.<\/p>\n

And it is worse than a slow single patch — because it is two<\/h2>\n

Here is the part that turns a delay into a genuine hazard. Januscape is not one bug<\/strong>. The complete upstream fix is two<\/em> commits closing two<\/em> CVEs in the same corner of the KVM code:<\/p>\n

    \n
  • CVE-2026-53359<\/strong> — commit 81ccda30b4e8<\/code><\/li>\n
  • CVE-2026-46113<\/strong> — commit 0cb2af2ea66a<\/code><\/li>\n<\/ul>\n

    A kernel that carries only the first commit is still exploitable<\/strong> 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<\/strong>, not just the headline CVE.<\/p>\n

    What you should actually do right now<\/h2>\n

    Frustration aside, waiting on your vendor is not a security posture. While the big distros catch up:<\/p>\n

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

      The bigger point<\/h2>\n

      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.<\/p>\n

      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.<\/p>\n

      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.<\/p>\n","protected":false},"excerpt":{"rendered":"

      Januscape (CVE-2026-53359) is a guest-to-host VM escape that was fixed upstream on 19 June and disclosed publicly on 6 July. Two days later, Ubuntu has shipped nothing, Red Hat is stuck in a testing feed that a downstream rebuild already beat, and Debian stable is still vulnerable. For a VM-escape bug, that is not good enough \u2014 and it is made worse by the fact that Januscape is really two CVEs, not one.<\/p>\n","protected":false},"author":1,"featured_media":95,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3,5],"tags":[],"class_list":["post-91","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-linux","category-security"],"_links":{"self":[{"href":"https:\/\/backendside.com\/blog\/wp-json\/wp\/v2\/posts\/91","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/backendside.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/backendside.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/backendside.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/backendside.com\/blog\/wp-json\/wp\/v2\/comments?post=91"}],"version-history":[{"count":1,"href":"https:\/\/backendside.com\/blog\/wp-json\/wp\/v2\/posts\/91\/revisions"}],"predecessor-version":[{"id":96,"href":"https:\/\/backendside.com\/blog\/wp-json\/wp\/v2\/posts\/91\/revisions\/96"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/backendside.com\/blog\/wp-json\/wp\/v2\/media\/95"}],"wp:attachment":[{"href":"https:\/\/backendside.com\/blog\/wp-json\/wp\/v2\/media?parent=91"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/backendside.com\/blog\/wp-json\/wp\/v2\/categories?post=91"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/backendside.com\/blog\/wp-json\/wp\/v2\/tags?post=91"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}