LXD 与 Incus 的 mTLS 身份验证绕过（CVE-2026-112816）

TL;DR

• Canonical LXD、MicroCloud 和 Incus 的 HTTPS API 存在一个缺陷，让网络攻击者无需目标客户端的私钥就能以任何受信任客户端的身份通过身份验证。该缺陷由 Incus 项目报告，Canonical 确认 LXD 和 MicroCloud 受影响，并于 2026 年 10 月 28 日发布安全通告。
• 受影响且未修复的守护进程，在攻击者能够访问 HTTPS API 并获取受信任身份的公开证书时才会暴露。Incus 在 TLS 握手中提供服务器证书；MicroCloud 通告描述的是截获正在加入集群的成员证书。不需要身份验证、权限或用户交互。
• Canonical 的 CVE 记录将其评为 Critical，CVSS v4.0 10.0。截至 2026 年 11 月 1 日，没有已知利用，也不在 CISA 的 KEV 目录中。所引用的厂商通告没有提供公开概念验证的链接。
• 使用 sudo snap refresh lxd 和 sudo snap refresh microcloud 更新 LXD 和 MicroCloud，并将 Incus 升级到 7.6.0。限制谁能访问 HTTPS 监听器只是临时措施，不是修复。

我受影响吗？

以下条件全部成立时，您处于暴露状态：

• 正在运行下表受影响范围内的守护进程：LXD、MicroCloud 或 Incus。
• 其 HTTPS API 监听在攻击者可访问的网络地址上。根据其 endpoints 源码，独立的 LXD 守护进程默认只提供本地 Unix 套接字，只有在配置了网络地址后才绑定网络监听器；集群和远程客户端需要网络 API。
• 攻击者能够获得某个受信任身份的公开证书。服务器证书在每次 TLS 握手中都会返回，因此最直接的攻击路径完全不需要事先访问。

Incus 通告指出该缺陷模式自首个版本起就存在，因此 7.6.0 之前的 Incus 安装均受影响。

Canonical 以 snap 形式分发 LXD 和 MicroCloud；Ubuntu 软件源中没有受影响的 LXD 软件包，Ubuntu 自己的追踪页面将该问题评为 Medium。上表所列修复版本是 Canonical 通告给出的 snap 版本。

检查您运行的内容以及网络 API 是否开启：

snap list lxd
lxc version
lxc config get core.https_address
lxc config get cluster.https_address
snap list microcloud

请检查 API 和集群监听器的地址：API 地址为空不代表没有集群监听器。Incus 使用相同的配置键：

incus version
incus config get core.https_address
incus config get cluster.https_address

如何修复？

将每个 LXD 和 MicroCloud 守护进程更新到所在渠道的修复版本，并将 Incus 升级到 7.6.0：

1. 刷新 snap：sudo snap refresh lxd 和 sudo snap refresh microcloud。
2. 确认守护进程确实运行修复版本：snap list lxd 加 lxc version。Canonical 指出，发布通告时所有 LXD 点版本正处于从 candidate 到 stable 的渐进推出中，因此刷新后请重新检查，不要默认修复已到达。
3. 通过其软件包渠道将 Incus 更新到 7.6.0。根据其发布公告，该版本还修复了另外 17 个安全问题。

没有通过配置实现的规避方案。建议的临时措施是将 HTTPS 监听器的网络访问限制为受信任主机，Incus 通告建议在更新到位前这样做。其局限很明显：缺陷仍留在守护进程中，任何不受信任的监听器访问路径都会让漏洞保持开放。

根本原因是什么？

信任检查把客户端发送的每张证书都与信任库比较。TLS 握手只能证明客户端持有链中第一张证书的私钥，链的其余部分完全由客户端控制。LXD 和 Incus 的 HTTPS 监听器使用 Go 的 tls.RequestClientCert 请求客户端证书，该选项请求证书链但不验证它。

Incus 守护进程在 7.6.0 之前的 cmd/incusd/daemon.go 的 Authenticate 中带有该缺陷最清晰的形式：

    // Allow internal cluster traffic by checking against the trusted certficates.
    if r.TLS != nil {
        for _, i := range r.TLS.PeerCertificates {
            trusted, fingerprint := localUtil.CheckTrustState(*i, trustedCerts[certificate.TypeServer], d.endpoints.NetworkCert(), false)
            if trusted {
                return true, fingerprint, "cluster", nil, nil
            }
        }
    }

遍历 r.TLS.PeerCertificates 的相同循环同样用于普通客户端证书和 metrics 证书，其中 i 依次是每张被提交的证书。r.TLS.PeerCertificates 是客户端按自己选择的顺序交出的全部证书。CheckTrustState 将一张证书与信任库条目比较，因此这个循环把客户端拼装的证书链变成了候选身份列表。

将受信任身份的公开证书作为附加链元素加入，攻击者就会以该身份通过身份验证。叶子证书证明攻击者是谁；附加证书决定服务器相信攻击者是谁。

如何被利用？

攻击只需要一次 TLS 连接和一张公开证书：

1. 攻击者获取某个受信任身份的公开证书。服务器证书可从与守护进程的任意一次 TLS 握手中提取，因此无需事先访问。客户端证书可被任何受信任客户端通过 certificates API 读取，或从该客户端连接过的任何服务器收集。
2. 攻击者用自己的证书和私钥连接 HTTPS API，并把获取的公开证书附加到提交的证书链中。
3. 握手成功，因为监听器只请求证书链，除叶子证书的密钥外不做任何验证。
4. 信任循环遍历提交的链，将附加证书与某个信任库条目匹配，并将攻击者认证为该身份。

这种冒充同样作用于自助服务证书路径。通告指出，客户端可以更新或删除信任库中的任意条目；未验证的证书链还会进入授权脚本，让客户端把自选证书送入脚本的授权决策。所引用的厂商通告没有提供公开概念验证的链接。所有这些只需要网络可达性。

攻击是如何流动的？

对 HTTPS 监听器的一次连接，加上放在证书链中的受信任身份公开证书，就足以变成该身份。

攻击者能做什么？

攻击者继承被冒充身份的一切能力：

• 按照 CVE 记录，获得对集群及其管理的虚拟机的完全访问。Canonical 指出，当被冒充用户拥有特权时，攻击者可能获得主机机器的 root 权限。
• 按照 Incus 通告，提交服务器自己的证书即可访问数据库网关，提交其他成员的证书即可获得集群内部访问。冒充集群成员会完全绕过授权。
• 通过自助服务路径更新和删除信任库中的任意条目。同一缺陷还会影响授权脚本，客户端因此可以影响脚本的授权决策。这包括令牌和 OpenID Connect 客户端，它们在握手中同样可以提交任意证书。
• 冒充主机与虚拟机之间的 agent 连接的身份验证，该连接带有相同缺陷。

在 MicroCloud 中，Canonical 警告：能够在成员加入集群时截获其公开 TLS 证书的攻击者，随后可以该成员的身份通过身份验证。条件保持不变：API 的网络可达性加上一张公开证书，无需权限，也无需用户交互。

为什么修复有效？

公开的参考修复是 Incus 提交 8381e54c3631c627d7ecdec03945bca14d0bd542，即 Stéphane Graber 于 2026 年 10 月 13 日编写的 “Only trust the key-proven client certificate”：

+   // The TLS listener only proves possession of the first peer certificate's key, so the rest of
+   // the presented chain is attacker-controlled and must never be matched against the trust store.
+   var peerCert *x509.Certificate
+   if r.TLS != nil && len(r.TLS.PeerCertificates) > 0 {
+       peerCert = r.TLS.PeerCertificates[0]
+   }

信任检查随后只针对 peerCert 运行，取代了所有遍历 r.TLS.PeerCertificates 的循环：

-   if r.TLS != nil {
-       for _, i := range r.TLS.PeerCertificates {
-           trusted, fingerprint := localUtil.CheckTrustState(*i, trustedCerts[certificate.TypeServer], d.endpoints.NetworkCert(), false)
-           if trusted {
-               return true, fingerprint, "cluster", nil, nil
-           }
-       }
-   }
+   if peerCert != nil {
+       trusted, fingerprint := localUtil.CheckTrustState(*peerCert, trustedCerts[certificate.TypeServer], d.endpoints.NetworkCert(), false)
+       if trusted {
+           return true, fingerprint, "cluster", nil, nil
+       }
+   }

附加的证书无法再匹配任何条目，因为只有握手实际验证过的叶子证书会被查询。该提交将相同规则应用于通告列出的每条信任路径，覆盖 API 身份验证、证书注册与自助更新和删除、两侧的主机到虚拟机 agent 连接、授权脚本以及集群流量。

对于 LXD 和 MicroCloud，Canonical 的通告描述了相同的修复，“我受影响吗？”中列出的修复版本已将其包含。

如何检查我是否已被入侵？

厂商通告没有公布入侵指标。信任库未发生变化并不能排除冒充：攻击者可以利用现有的受信任身份，而无需创建新条目。

首先检查信任库和集群成员中是否有异常条目：

lxc config trust list

lxc cluster list

逐一检查信任库条目，查找无法解释的名称、类型或项目设置。请特别注意被更新过的条目，因为自助更新路径是该缺陷的一部分。如果某个特权身份可能已在主机上被冒充，请将该主机视为已被入侵：评估从该主机可访问的所有凭据，包括私钥，并轮换可能在入侵过程中暴露的凭据。按照事件响应流程重建受影响主机。

时间线

Incus 修复提交的编写日期比 CVE 发布早 17 天。作者时间戳并不能证明该提交何时公开。

• 2023-07-22：Incus 代码仓库作为 LXD 的分支创建。Incus 通告指出该缺陷模式自首个版本起就存在。
• 2026-10-13：Stéphane Graber 编写 Incus 修复提交 8381e54c3631c627d7ecdec03945bca14d0bd542。
• 2026-10-19：Canonical 预留 CVE-2026-112816。
• 2026-10-21：Canonical 发布 LXD 6.10.1，这是 6.x 分支的第一个修复版本。
• 2026-10-28：Canonical 发布安全通告，给出 LXD 和 MicroCloud 的修复 snap 版本。
• 2026-10-29：Incus 发布 GHSA-xg75-xf37-cph9。LXD 和 MicroCloud 的修复 snap 发布日期为 2026 年 10 月 29 日。
• 2026-10-30：CVE 记录发布，Incus 7.6.0 发布。CISA 的 ADP 于 2026 年 10 月 30 日记录无已知利用。

常见问题

为什么 TLS 握手不能证明整条证书链？

监听器使用 Go 的 tls.RequestClientCert 请求客户端证书，该选项请求证书链但不验证。握手只能证明客户端持有链中第一张证书的私钥；之后的每张证书都是客户端自行附加的数据。

默认配置的独立 LXD 安装受影响吗？

不受影响。独立守护进程只提供本地 Unix 套接字，只有在管理员配置网络地址后才绑定 HTTPS 监听器，因此默认安装无法从网络访问。集群和任何远程 lxc 客户端需要该网络 API。

打上修复后我需要轮换证书吗？

仅公开证书的披露不需要轮换，因为证书本来就不是秘密；补丁可以阻止身份验证绕过。如果攻击者已经访问主机，则应单独评估私钥和其他凭据的暴露情况，轮换已泄露的凭据，并检查信任库中的未授权变更。

LXD 和 Incus 的缺陷是同一个漏洞吗？

它们是共同源码谱系在两套代码中的同一机制。同时创建了 LXD 和 Incus 的 Stéphane Graber 报告了该缺陷；Incus 在 7.6.0 中修复，Canonical 在上列版本中修复了 LXD 和 MicroCloud。Canonical 的通告覆盖 LXD 和 MicroCloud，而 Incus 通告未附带 CVE 编号发布。

该漏洞在现实中被利用了吗？

没有已知利用。CISA 的 ADP 于 2026 年 10 月 30 日评估利用状态为无，截至 2026 年 11 月 1 日该缺陷不在 CISA 的 KEV 目录中。所引用的厂商通告没有提供公开概念验证的链接。

用 Ostorlab 找出暴露的 LXD 和 Incus 主机

Ostorlab 的攻击面发现会对面向互联网的主机进行资产盘点，帮助您找出哪些 LXD、Incus 和 MicroCloud 守护进程暴露了 HTTPS API，并优先修复它们。

参考文献

• CVE-2026-112816 记录，Canonical CNA，CVSS v4.0 10.0： https://www.cve.org/CVERecord?id=CVE-2026-112816 （2026 年 11 月 1 日核实）
• Canonical 安全通告，含修复 snap 版本： https://discourse.ubuntu.com/t/security-advisory-critical-vulnerability-found-in-canonical-lxd-and-microcloud/90557 （2026 年 10 月 28 日发布，2026 年 11 月 1 日核实）
• Incus 通告 GHSA-xg75-xf37-cph9，CVSS v3.1 10.0： https://github.com/lxc/incus/security/advisories/GHSA-xg75-xf37-cph9 （2026 年 10 月 29 日发布，2026 年 11 月 1 日核实）
• Incus 修复提交 “Only trust the key-proven client certificate”： https://github.com/lxc/incus/commit/8381e54c3631c627d7ecdec03945bca14d0bd542 （2026 年 10 月 13 日编写，2026 年 11 月 1 日核实）
• LXD 6.10.1 发布公告： https://discourse.ubuntu.com/t/lxd-6-10-1-lts-has-been-released/90024 （2026 年 10 月 21 日发布，2026 年 11 月 1 日核实）
• Incus 7.6 发布公告，18 项安全修复： https://discuss.linuxcontainers.org/t/incus-7-6-has-been-released/27462 （2026 年 10 月 30 日发布，2026 年 11 月 1 日核实）
• CVE-2026-112816 的 Ubuntu 追踪页面，软件源软件包状态与 Medium 优先级： https://ubuntu.com/security/CVE-2026-112816 （2026 年 11 月 1 日核实）
• LXD endpoints 源码，默认本地 Unix 套接字与配置后启用 HTTPS 监听器： https://github.com/canonical/lxd/blob/lxd-6.10.1/lxd/endpoints/endpoints.go （2026 年 11 月 1 日核实）
• CISA KEV 目录，针对 CVE-2026-112816 核实的订阅源： https://www.cisa.gov/known-exploited-vulnerabilities-catalog （2026 年 11 月 1 日核实）
• The Hacker News，"CVSS 10.0 LXD, MicroCloud Flaw Lets Attackers Impersonate Trusted Clients Without a Private Key"： https://thehackernews.com/2026/11/critical-lxd-and-microcloud-flaw-cvss.html （2026 年 11 月 1 日发布，2026 年 11 月 1 日核实）