文章总结： 2026年7月6日公开的CVE-2026-53359（Januscape）是KVM虚拟化逃逸漏洞，存在于嵌套虚拟化的影子页表记账逻辑中，因未核对翻译页角色导致释放后使用。该漏洞潜伏约16年，是5月补丁未修干净的死角。公开PoC仅实现拒绝服务，研究者称可完整逃逸但未公开。建议运维人员确认修复补丁81ccda30b4e8，或关闭嵌套虚拟化参数，并检查/dev/kvm权限。 综合评分： 86 文章分类： 漏洞分析,应急响应,安全运营

一个潜伏16年的KVM漏洞，如何让虚拟机「越狱」

原创

mayfly mayfly

独眼情报

2026年7月7日 10:39 湖北

在小说阅读器读本章

去阅读

如果你的服务器、你租用的云主机，或者你的业务最终跑在别人物理机上的一台虚拟机里——这件事值得你花几分钟看完。

❝

https://github.com/V4bel/Januscape

2026年7月6日，禁止期结束后，安全研究员 Hyunwoo Kim 公开了一个编号 CVE-2026-53359、代号「Januscape」的 KVM（Kernel-based Virtual Machine，基于内核的虚拟机）虚拟化逃逸漏洞。KVM 是几乎所有主流云平台——包括 Google Cloud、AWS——用来让一台物理机同时安全运行多个互不信任的虚拟机的核心技术。这个漏洞的性质很直接：一台本该被牢牢关在自己「房间」里的虚拟机，仅凭自己内部的操作，就可能让宿主机的内核崩溃；研究者手里还握着一套没有公开的完整方法，据称能让攻击者直接拿到宿主机的最高权限。

更值得留意的是两点：这个漏洞已经在 Linux 内核里存在了大约16年；它还恰好是今年5月一次「没修干净」的补丁留下的死角。

这到底是个什么问题

虚拟机需要一份地址翻译表，把自己以为在用的内存地址，对应到物理机上真正的内存地址。现代 CPU 大多有硬件帮着做这件事（Intel 的 EPT、AMD 的 NPT），但只要虚拟机自己里面又套了一层虚拟机——也就是「嵌套虚拟化」，常见于云厂商内部测试、安全沙箱、CI（持续集成）流水线——KVM 就不得不退回到一套完全靠软件维护的翻译方式，业内称为「影子页表」（shadow MMU）。

这套软件翻译表由一个个「翻译页」拼成。每个翻译页不仅有编号（对应虚拟机里的哪块内存），还有「角色」：它此刻是在给一整块2MB大页做翻译，还是被拆开、专门给某一级页表做翻译，这是两种不同的用途，不能混用。

问题出在 KVM 判断「这个位置的翻译页还能不能接着用」的那一步代码里：过去的逻辑只核对了编号对不对，没有核对角色对不对。于是就可能出现编号相同、角色却已经变了的情况——本该分配一个新翻译页，却被当成还能沿用旧的。角色一旦认错，后续的内存回收和记账就全乱了：一块已经被释放、转做他用的内存，还会被内核当成「仍在使用中的翻译页」去读写，这正是「释放后使用」（use-after-free）类漏洞的典型形态。

触发这条乱子最简单的后果，是让内核自己的完整性检查发现「账对不上」后主动崩溃——这是拒绝服务（DoS），公开的概念验证代码（PoC）走的就是这条路。Kim 表示还有一套更精细的完整利用方法，需要精确控制被释放内存重新被谁占用，才能在宿主机上直接执行代码、拿到 root 权限；但这套方法他没有公开，按原文说法是「计划在遥远的未来发布」。也就是说，目前公开可复现的只是「让宿主机崩溃」，「拿下宿主机」这一步停留在研究者的一面之词，没有第三方验证。

这不是这段代码今年第一次出问题。5月28日，同一段「影子翻译表」记账逻辑里的另一个漏洞（CVE-2026-46113）被修复——据威胁情报聚合平台 Mallory 报道，发现者是亚马逊研究员 Alexander Bulekov 与 Fred Griffoul，经模糊测试发现。那次修的是「编号对不上」的情形：虚拟机从外部改了页表映射、又删除了对应内存槽后，回收翻译页时可能漏记。但那次补丁只核对了编号，没有核对角色——Januscape 恰好是「编号核对上了、角色却没核对」的那一半漏洞，像是修好了地址写错的信件，却漏掉了收件人姓名认错的那一批。两个漏洞前后相隔两个月，出在同一段维护了十几年的遗留代码里，说明这段代码眼下正被不止一路研究者盯上。

6月19日，修复补丁（在复用判断里加上「角色也必须对上」这一条件）合入 Linux 主线，随后按标准流程走了一遍发行版禁运期：7月4日拿到 CVE 编号，7月6日禁运期结束、完整技术细节公开。截至发稿，NVD（美国国家漏洞数据库）尚未给出官方 CVSS 评分；Red Hat 自己的公告给出了基础分7分，作为对照，前一个相关漏洞 CVE-2026-46113 曾被单独评为8.8分——两个数字都不能直接套用到 Januscape 头上，只能说明这类漏洞的评分眼下并不统一。

已经有人在利用了吗

目前没有查到在野利用的报告。真正「实战」过这个漏洞的，是 Kim 本人——他把 Januscape 作为一次零日提交进了 Google 的 kvmCTF 漏洞奖励计划。kvmCTF 由 Google 于2024年6月上线，专门奖励能在其 KVM 沙箱环境里演示零日漏洞的研究者，最高奖励是完全虚拟机逃逸的25万美元，拒绝服务级别对应2万美元；不过 Kim 这次具体拿到哪一档，公开信息里没有说明。这个项目的规则本身也值得一提：它明确不奖励已经公开过的漏洞，只奖励真正的零日，而且要求研究者先配合上游发布补丁才能公开细节——这在客观上推动了这次「先修复、再披露」的处理顺序。

Januscape 是 Kim 大约两个月内公开的第三个 Linux 内核漏洞。5月，他披露了 Dirty Frag（CVE-2026-43284／CVE-2026-43500），一条页缓存写入漏洞链，能在多数主流 Linux 发行版上稳定拿到 root，报道将其归入 Dirty Pipe、Copy Fail（CVE-2026-31431，本站此前分析过）同一漏洞谱系；6月，他公开了 ITScape（CVE-2026-46316），首个公开演示的 KVM/arm64 虚拟机逃逸漏洞，利用的是虚拟中断控制器里的竞态与双重释放漏洞。四条线放在一起看更清楚：

| 代号 | 编号 | 时间 | 问题类型 | 影响范围 | 公开可复现程度 | | — | — | — | — | — | — | | （无代号） | CVE-2026-46113 | 2026年5月 | shadow MMU 记账遗漏（编号对不上） | Intel/AMD x86 | 未公开 PoC | | Dirty Frag | CVE-2026-43284／CVE-2026-43500 | 2026年5月 | 页缓存写入漏洞链 | 主流 Linux 发行版 | 可稳定获取 root | | ITScape | CVE-2026-46316 | 2026年6月 | vGIC-ITS 竞态＋双重释放 | ARM64 架构 KVM 宿主机 | 公开 PoC 可演示宿主机代码执行 | | Januscape | CVE-2026-53359 | 2026年7月 | shadow MMU 记账遗漏（角色对不上） | Intel/AMD x86 | 公开 PoC 仅限拒绝服务，完整逃逸未公开 |

目前的公开反应集中在安全研究和运维社区：多家海外安全资讯站已经跟进，海外 VPS（虚拟专用服务器）托管社区论坛上也有管理员在讨论自己的机器要不要担心——普遍结论是只有主动开启了嵌套虚拟化才会中招。截至发稿，没有检索到中文安全媒体或国内云厂商的公开表态。

你该怎么办

先看这件事跟你有多大关系：真正需要现在就动手的，是运行 x86 KVM、接受不受信任虚拟机、并且开启了嵌套虚拟化的宿主机——这主要指公有云和部分 VPS 服务商、企业内部用 KVM／oVirt／Proxmox／Red Hat Virtualization 搭建的私有云，以及一些用嵌套虚拟化做安全沙箱或 CI 流水线的场景。如果你只是在某个云平台上租了一台虚拟机、自己没有主动开启嵌套虚拟化，这件事更多是该去确认你的云厂商有没有打补丁，而不是需要你自己动手。

如果你确实运维 KVM 宿主机：

1. 确认宿主内核是否包含修复补丁 81ccda30b4e8。各发行版的补丁常常是反向移植的，版本号不一定和上游对得上，要去看具体更新日志，不能只看内核版本号；
2. 暂时无法升级时，可以先关闭嵌套虚拟化（参数为 kvm_intel.nested=0 或 kvm_amd.nested=0），能直接堵住这条攻击路径；
3. 检查 /dev/kvm 这个设备文件的权限——RHEL 一类发行版上它默认全局可写，配合这个漏洞，本地的普通用户也能借此提权到 root，这个风险和「虚拟机逃逸」是两回事，但同样值得堵上；
4. 如果之前部署过 Kim 披露的另一个漏洞 ITScape（影响 ARM64 架构）还没打补丁，建议一并处理。

国内读者更实际的问题是：阿里云、腾讯云、华为云受不受影响？公开信息给不出确切答案。这几家云厂商的虚拟化技术栈这些年都经历过自研化改造——比如阿里云从早年基于 KVM，演进到自己的软硬融合架构——具体到今天，它们的宿主机在多大程度上还会走到这条「影子翻译表」代码路径，只有厂商自己清楚。如果你用的实例规格允许自己开启嵌套虚拟化，更稳妥的做法是直接查一下对方的安全公告或提交工单确认，而不是自行猜测。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：独眼情报 mayfly mayfly《一个潜伏16年的KVM漏洞，如何让虚拟机「越狱」》