LXD、MicroCloud 存在 CVSS 10 分漏洞，可冒充受信客户端

Canonical已发布修复，解决了LXD和MicroCloud中一个最高危级别的身份验证漏洞。攻击者无需接触受信客户端的私钥，即可冒充该客户端。该漏洞编号为CVE-2026-112816，CVSS评分为10.0，问题出在服务器评估双向TLS握手中证书链的方式上：攻击者只需在自己的证书后附上受信客户端的公开证书（按设计，公开证书本就不是机密），服务器就会把他当作该客户端放行。据The Hacker News报道，若冒充的是特权账户，攻击者可能获得“宿主机的root权限”，进而控制整个集群及其上运行的所有虚拟机。

前提条件很关键，至于10.0分是否合适，我稍后再谈。攻击者需要具备两个条件：能够访问LXD或MicroCloud的HTTPS API网络，并掌握服务器已信任的某个客户端的公开证书。无需钓鱼，无需窃取密钥，也无需暴力破解。这有点像证书链层面的“尾随”：你靠自己的双腿走进去，而门卫检查的却是你身后那个人的工牌。

证书链信任校验是如何失效的

LXD和MicroCloud使用双向TLS验证远程客户端。客户端出示证书，若该证书存在于服务器的信任库中（即服务器愿意接受的身份列表），服务器便予以信任。到这里都是常规做法。问题出在服务器究竟检查了哪些证书与该信任库进行比对。

在TLS中，握手过程能以密码学方式证明客户端只持有链中第一张证书（即叶子证书）对应的私钥。叶子证书之后的所有证书，都只是客户端自行选择发送的数据。存在漏洞的LXD代码会将证书链中每一张证书都与信任库进行比对，因此攻击者可以生成自己的密钥对，把受信客户端的公开证书附加在自己的叶子证书之后，并在第二张证书上匹配信任库。服务器从未验证攻击者是否持有该受信证书对应的私钥，因为TLS本就不是这样工作的。

# What the attacker presents
chain = [attacker_leaf, trusted_client_public_cert]
# What TLS proves: private key for attacker_leaf ONLY
# What the vulnerable server did:
for cert in chain:
if cert in trust_store:
authenticate_as(cert)   # matches trusted_client_public_cert -> session as trusted client

通过认证后，攻击者将继承被冒充客户端的全部权限：集群操作、虚拟机访问，若该账户是管理员，还包括主机级root权限。公开证书本应可以公开共享，它们会在握手过程中传递、被记录，也存在于配置备份中。若在没有证明私钥持有权的情况下将其视为身份凭证，就彻底打破了mTLS的安全模型。

时间线：从社区分支到Canonical修复

值得肯定的是，该漏洞并非由Canonical发现。LXD的社区分支Incus项目发现并报告了此问题，随后在Incus 7.6.0中连同另外17个安全问题一并修复。Canonical确认LXD同样受影响，因为它沿用了同一段代码路径。分支关系是把双刃剑：共享代码意味着共享漏洞，谁先审计，谁就是在帮所有人的忙。

10月30日，CVE-2026-112816的CVE记录附上了CISA的评估：目前尚未发现该漏洞被利用，也未被列入CISA的已知被利用漏洞目录（KEV）。目前也没有公开可用的有效利用代码。截至今日的情况是：攻击原理已被完整记录，修复补丁已公开，但尚未发现真实环境中的滥用。从“公开披露”到“武器化”之间的时间窗口，正是防御方决定是及时打补丁，还是事后解释为何没有打补丁的关键时期。

Canonical的修复版snap包括：LXD 6.10.1（6/stable）、5.21.9（5.21/stable）、5.0.11（5.0/stable）和4.0.15（4.0/stable），以及MicroCloud 3.4.1（3/stable）和2.1.5（2/stable）。CVE记录列出的受影响版本为LXD 4.0.14、5.0.10、5.21.8和6.9，每个版本直到其后续的点版本发布之前均存在漏洞。需要注意的是：Canonical在公告发布时指出，LXD修复版的点版本仍在从候选通道向稳定通道推送，因此仅刷新并不能保证已获得修复，请务必核实实际安装的版本。Ubuntu档案库中的LXD deb包被标注为不受影响或未提供，此处的关键载体是snap包。

CVSS 10.0合适吗？既对也不对

支持10.0分的理由是：这是一个完整的身份验证绕过，无需用户交互，复杂度低，影响最终可达主机root权限。其利用原理极为简单，只要有人曾把证书链粘贴进PEM文件，就具备所需的全部技能。

反对的理由是：两个前提条件确实大幅缩小了影响范围。独立运行的LXD服务器默认不暴露API，它只监听本地Unix套接字，除非管理员明确设置core.https_address。而且攻击者需要受信客户端的公开证书，这种证书虽非机密，但也不会在公网上广泛传播。最突出的风险来自MicroCloud：Canonical表示，若攻击者能够在成员加入集群时截获其公开证书，就能以该成员身份登录。集群引导流量恰恰常会经过管理网络，因此“公开但难以获取”就变成了“一旦截获，便可永久重放”。

我的判断是：如果你的LXD API可以从专用管理网段之外访问，就应将此视为必须立即打补丁的紧急事项。如果只能通过套接字访问，那打补丁更多是出于安全规范，而非恐慌。10.0分描述的是漏洞本身，而你的网络拓扑决定了你的实际风险。

无变通方案：打补丁或隔离监听端口

Canonical的公告未提供LXD的临时配置变通方案，Incus项目对自身代码库也直言不讳：不存在配置层面的修复方法，唯一的临时措施是限制对监听端口的网络访问。这说明漏洞位于验证逻辑本身，而非某个可以调节的配置项。对于snap安装方式，修复只需两条命令加一次版本检查：

sudo snap refresh lxd
sudo snap refresh microcloud
snap list lxd microcloud   # confirm you actually got the fixed point release

顺便，请诚实回答以下暴露面问题：

• 在每台主机上运行lxc config get core.https_address。若返回值为空，说明仅使用本地套接字，该主机无法被远程利用。
• 如果API必须保持网络可达，请将其限制在管理VLAN内，或通过防火墙白名单管控，直到修复版snap在你所用版本通道的稳定通道上线。
• 对于MicroCloud，应将集群加入流量视为敏感数据：能够截获加入成员公开证书的路径上的观察者，已经满足了此次攻击的一半条件。
• Incus用户应升级至7.6.0，该版本一次性修复了此漏洞及另外17个安全问题。
• 打补丁后，请检查信任库条目和集群成员列表，核实是否存在你无法识别的身份。如果有人在修复前已潜入，这是一项低成本的保险措施。

若被冒充的账户具有特权，Canonical表示，攻击者可能获得“宿主机的root访问权限”。

更广泛的教训在身份验证代码中反复出现，从GitLab CVSS 10分正则表达式RCE到本次漏洞皆是如此：一项看似彻底的检查（如校验证书链中的每一张证书），可能比范围更窄的检查更危险，因为它会让人对一个错误的假设产生虚假的信心。TLS只能证明叶子证书的私钥持有权，除此之外别无其他。任何基于证书链深处证书的信任决定，都需要自己的证明，而这里恰恰缺失了这一证明。Incus发现了它，Canonical修复了它，现在剩下的唯一问题是：你的更新能否赶在别人的利用之前落地。