11 月 3 日，Xen 项目发布 XSA-523 安全公告，修掉两个能跨虚机读写内存的缺陷：CVE-2026-102703 与 CVE-2026-102704。一台被攻陷的客户虚机可以借此读取、篡改同一宿主机上其他虚机的内存，包括默认拥有全部管理权限的 dom0。Xen 4.6 及以后的所有版本都受影响，4.5 及更早不受影响。公告的措辞很硬：补丁已发，但没有已知的缓解措施。
事件概述
两个漏洞位于 Xen 的 grant copy 机制，也就是虚机之间复制数据的那套接口。每个虚机通过 grant table 告诉 Xen 自己哪些内存页允许别人访问，Xen 负责校验权限。为了省掉同一内存页内批量复制的重复开销，Xen 会复用已经做过的权限检查；问题就出在这里——在某些情况下本该重新校验的时候没有校验，恶意 guest 于是能读写不属于自己的内存。
发现过程本身是个信号。Xen 项目把发现者记为 AI 公司 Anthropic，用的是 Claude 模型；随后由 Ada Logics 的 Stephan Lipp 验证，CodeAnt AI 安全研究团队独立报告了同一问题。这是继 Linux 内核 CVE-2026-98432 之后，AI 模型在底层基础设施代码里挖出可利用缺陷的又一个案例。
影响评估
XCP-ng 的维护方 Vates 把影响评为 Critical，并直白地写道：单台被攻陷的 guest 可以跳出隔离、接管整个宿主机。这句话的分量在于，虚拟化的隔离边界就是云多租户模式的全部信任基础——这条边一破，同一台物理机上的所有租户共享同一个信任域。
公告没有说明利用需要在 guest 内具备什么权限，也没有提到在野利用。但跨虚机内存读写在理论上足以直接取走同宿主机上其他租户的密钥、会话令牌和运行时凭据，属于「不出事则已，出事没法解释」的类型。
对自建云和 IDC 转云的团队来说，还有一个现实约束：这类漏洞的修复成本不在打补丁，而在重启。一台宿主机上跑的虚机越多、SLA 越紧，窗口越难排。这也意味着从公告发布到全量修复之间的窗口期，往往以周计，而不是以小时计。
各家修复进度
- Xen 源码：公告附带 xen-unstable 至 4.19.x、4.18.x 至 4.17.x 的补丁
- Xen 4.6 至 4.16：没有补丁。4.16 的安全支持早在 2024 年 12 月 2 日结束，这条线只能升级大版本或迁移
- XCP-ng 8.3：
xen-4.17.7-4.2.xcpng8.3，11 月 3 日发布，宿主机必须重启 - Qubes OS 4.3：dom0 内的 Xen 包升至
4.19.6-3，dom0 要重启；使用 Anti Evil Maid 的用户必须重新封装口令，因为新二进制改变了 PCR18 与 PCR19 - Debian：截至 11 月 4 日，bookworm、trixie、forky 的 xen 包仍标记为受影响，sid 已修复
修复建议
没有缓解措施，实际只有两条路：打补丁重启，或者把不可信 guest 迁走。对云服务商和私有云运维来说，重启意味着业务窗口，建议按宿主机分批滚动，先把承载外部租户的节点做掉，内部管理集群放在第二批。
打完补丁还有一件容易被跳过的检查：XSA-523 与 7 月 28 日披露的 XSA-500 是两回事，后者同样是 grant copy 缺陷，但补丁不通用。从 XSA-500 升级过来的环境，别以为已经修过。公告里明确写了这是独立的一组补丁。
监控侧建议把「宿主机内是否存在异常 grant table 操作」加进基线，并检查 dom0 的 xl dmesg 与 hypervisor 日志有无异常。多租户环境下，一旦确认宿主机被跨租户访问过，标准动作是轮换该宿主机上所有虚机内的高价值凭据，而不只是打补丁。