CVE-2026-112816：CVSS 10.0！LXD 证书链验证漏洞如何让攻击者绕过认证、接管虚拟化集群？

摘要： 2026 年 10 月，Canonical 披露 LXD 和 MicroCloud 存在严重的 TLS 客户端证书验证漏洞（CVE-2026-112816），CVSS 4.0 评分达到 10.0。攻击者可能利用伪造的证书链，仅凭受信任客户端的公开证书绕过身份认证，进而控制虚拟机、容器甚至宿主机。本文介绍漏洞产生的原因、利用条件、影响范围，以及服务器管理员如何自查和修复。

一、漏洞概述

LXD 是 Canonical 维护的 Linux 容器与虚拟机管理平台，能够通过统一的 API 管理系统容器、虚拟机、存储和网络资源。

它经常出现在私有云、开发测试平台、企业虚拟化环境和 Linux 服务器集群中。

2026 年 10 月，Incus 项目的安全研究人员 Stéphane Graber 发现了一个严重的 TLS 客户端证书验证问题。Canonical 随后确认，LXD 和 MicroCloud 也受到该问题影响。

漏洞编号为 CVE-2026-112816。

CVSS 4.0 评分向量为：

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

其中，AV:N 表示可以通过网络触发，AC:L 表示攻击复杂度较低，PR:N 则表示无需预先获得系统账户权限。

Canonical 已经发布安全更新，并建议所有 LXD、MicroCloud 用户及时升级。

受影响版本

根据 Canonical 的 CVE 记录及官方安全公告：

这些修复版本均已于 2026 年 10 月 29 日发布。

需要注意，CVE 记录列出了明确的 LXD 受影响版本范围。对于更早的历史版本，建议结合厂商公告及实际补丁情况核实，避免仅凭版本号较低就判断安全。

二、漏洞原理：服务器为什么会相信一张伪造的证书链？

这个漏洞的核心问题其实很容易理解：

服务器检查了客户端提交的整条证书链，却没有正确区分哪些证书真正完成了私钥持有证明。

1. 正常的 TLS 客户端认证

LXD 支持通过 HTTPS API 远程管理服务器。

为了确保连接者具有管理权限，LXD 可以使用 TLS 客户端证书进行身份认证。

正常情况下：

1. 管理员持有一张客户端证书，以及与之对应的私钥。
2. 管理员连接 LXD 服务器。
3. TLS 握手过程中，客户端使用私钥证明自己的身份。
4. 服务器检查完成身份验证的证书是否受到信任。
5. 认证通过后，服务器根据客户端身份授予相应权限。

这里有个关键概念：公开证书可以被复制，私钥才是证明身份的重要凭据。

即使攻击者拿到了管理员的公开证书，通常也无法直接冒充管理员，因为他无法使用管理员的私钥完成身份认证。

2. LXD 的错误在哪里？

问题出在客户端证书链的处理方式上。

TLS 连接中，客户端可能提交多张证书组成的证书链。

例如：

客户端提交的证书链：

Certificate[0]：客户端证书
Certificate[1]：中间证书
Certificate[2]：其他证书

在相关的 TLS 握手模式下，客户端实际证明持有私钥的是第一张证书，也就是叶子证书（Leaf Certificate）。

后续证书由客户端提供，其身份声明需要经过适当验证才能被信任。

然而，存在漏洞的认证逻辑会将客户端提交的多张证书逐一与服务器的信任库比较。

只要其中某张证书与信任库中的受信任证书匹配，就可能错误地认可该身份。

可以用下面这段简化伪代码理解：

# 漏洞逻辑示意，并非 LXD 原始源码def authenticate(peer_certs, trusted_certs):    for cert in peer_certs:        if cert in trusted_certs:            return True    return False

问题在于：

peer_certs 中的每一张证书，并没有都完成对应私钥的持有证明。

这就给攻击者留下了机会。

3. 攻击者如何利用？

假设有一台 LXD 服务器，以及一位拥有管理员权限的用户 Alice。

攻击者 Bob 已经获得 Alice 的公开客户端证书，但没有 Alice 的私钥。

Bob 可以尝试构造如下证书链：

攻击者提交的证书链

┌────────────────────────────┐
│ Certificate[0]             │
│ Bob 自己控制的证书          │
│ Bob 持有对应私钥            │
└─────────────┬──────────────┘
              │
              ▼
┌────────────────────────────┐
│ Certificate[1]             │
│ Alice 的公开证书            │
│ Bob 没有 Alice 的私钥       │
└─────────────┬──────────────┘
              │
              ▼
┌────────────────────────────┐
│ LXD 错误的证书匹配逻辑      │
│ 在信任库中找到 Alice 的证书 │
└─────────────┬──────────────┘
              │
              ▼
       错误地认可 Alice 身份

Bob 使用自己的私钥完成 TLS 握手，却通过额外提交的 Alice 证书欺骗了后续认证逻辑。

最终，服务器可能把 Bob 当成 Alice。

这也解释了为什么该漏洞如此危险：攻击者无需窃取管理员私钥，仅需要取得符合条件的受信任公开证书。

上述过程是根据厂商披露的缺陷机制进行的概念性说明，省略了具体 TLS 报文构造与证书链处理细节。

4. 为什么这可能演变成宿主机接管？

LXD 管理员通常拥有很高的系统权限。

例如，可以创建容器、修改实例配置、管理存储设备，并在具备相应权限的情况下访问宿主机资源。

如果攻击者成功冒充高权限管理员，便可能进一步：

• 读取容器或虚拟机中的敏感数据；
• 修改、停止或删除业务实例；
• 篡改虚拟网络和存储配置；
• 创建具有危险宿主机访问能力的实例；
• 在满足相应权限条件时取得宿主机 root 权限。

Canonical 官方明确确认了潜在的宿主机 root 权限风险。

对于多节点集群，这种攻击还可能影响多个业务系统。

三、哪些用户需要担心？

判断这个漏洞的实际风险，需要同时考虑软件版本、HTTPS API 的可访问性，以及攻击者能否获得可用于冒充的公开证书。

1. 高风险：开放远程管理接口的 LXD 服务器

LXD 默认主要通过本地 Unix Socket 管理。

管理员也可以配置远程 HTTPS API，例如：

lxc config set core.https_address :8443

这条命令会让管理 API 在指定端口监听网络连接。

如果服务器使用受影响的 LXD 版本，并且攻击者可以访问该接口，就形成了漏洞利用的重要条件。

尤其需要关注：

• 将 LXD 管理端口开放到公网的 VPS；
• 使用 LXD 搭建的企业私有云；
• 多用户共享的虚拟化管理平台；
• 通过 VPN 或内网远程管理的 LXD 集群。

即便管理接口只允许内网访问，已经进入内网的攻击者仍然可能尝试利用该漏洞。

2. MicroCloud 集群管理员

MicroCloud 用于部署和管理小型云基础设施，其中涉及 LXD 等基础组件。

Canonical 指出，攻击者可能截获正在加入集群的成员节点的公开 TLS 证书，并随后冒充该成员。

因此，MicroCloud 用户需要同时检查 MicroCloud 和 LXD 的安全版本。

3. Incus 用户也要关注

Incus 是从 LXD 项目发展出来的独立容器和虚拟机管理系统。

其 GitHub 安全公告 GHSA-xg75-xf37-cph9 披露了相同类型的证书链认证绕过问题。

Incus 公告指出，攻击者甚至可能利用 TLS 握手中可获得的服务器公开证书，冒充受信任的服务器身份。

该问题在 Incus 中由独立 GHSA 跟踪。官方公告列出的主线修复版本为 7.6.0；使用 6.0、7.0 LTS 或发行版维护版本的用户，应额外核实对应分支是否已经回移修复。

4. 普通开发者需要担心吗？

可以参考下面的判断：

这里还需要区分宿主机与业务环境。

例如，一个开发者可能在 LXD 容器中运行 Jupyter Notebook 或 AI 推理服务。

即使这些应用本身已经更新到最新版本，只要底层 LXD 管理平台存在漏洞，整个运行环境仍可能受到威胁。

四、风险分析：已经有人利用了吗？

截至 2026 年 11 月 2 日，公开信息可以分为三个层次。

1. 理论利用能力：高

根据官方披露：

• 可以通过网络触发；
• 无需预先登录；
• 无需用户交互；
• 攻击复杂度较低；
• 可能获得整个虚拟化集群的管理权限。

因此，该漏洞的严重性已经得到厂商确认。

不过，实际攻击仍需要能够访问目标 HTTPS 服务，并满足对应的证书获取和身份匹配条件。

2. 公开 PoC：尚未找到经过独立核实的可运行利用代码

目前可以找到公开的技术原理和 GitHub 安全公告。

部分自动化漏洞情报网站将其标记为存在 PoC，但没有提供可以独立核实的有效代码或复现证据。

因此，截至本文撰写时，尚未确认存在公开、可运行的 CVE-2026-112816 专用 PoC。

这也意味着，公开披露的漏洞机制和完整的可复现利用程序，应当分开判断。

3. 真实攻击：尚无已证实的大规模利用事件

CISA 在 2026 年 10 月 30 日的 SSVC 评估中，将该漏洞的已知利用状态记录为 none。

截至本文撰写时，也尚未发现该漏洞进入 CISA 的 KEV（Known Exploited Vulnerabilities）目录的记录。

这反映了目前公开证据的情况，不能据此排除尚未披露的攻击活动。

五、如何检查自己的服务器？

以下操作适用于 Ubuntu 等 Linux 系统。

第一步：检查是否安装 LXD

command -v lxc
snap list lxd

如果通过 Snap 安装，会看到类似输出：

Name  Version   Rev    Tracking
lxd   6.10.0    ...    6/stable

其中：

• Version 表示安装的软件版本；
• Tracking 表示当前跟踪的 Snap 更新通道。

如果显示 6.10.0，就属于官方列出的受影响范围。

还可以检查 LXD 服务端信息：

lxc info

需要以实际服务端版本为准，尤其是在客户端和服务端分别安装的情况下。

第二步：检查 HTTPS 管理接口

执行：

lxc config get core.https_address

常见结果：

还可以检查实际监听端口：

sudo ss -lntp | grep 8443

注意：8443 是常见端口，实际环境可能使用其他端口。

如果使用反向代理、防火墙端口映射或集群网络，还需要检查相应的网络访问路径。

第三步：检查 MicroCloud

snap list microcloud

如果已经安装，核对是否达到官方修复版本：

MicroCloud 2.x：2.1.5
MicroCloud 3.x：3.4.1

对于 Incus，可以使用：

incus version

随后根据对应分支的官方安全公告检查补丁情况。

六、官方修复方案

1. 优先升级 LXD

Canonical 推荐通过 Snap 更新：

sudo snap refresh lxd

升级后重新检查：

snap list lxd

确认版本达到对应分支的安全版本。

需要特别注意，Canonical 在公告中说明，部分 LXD 修复版本采用从 candidate 向 stable 渐进发布的方式。

因此，即使执行了更新命令，也应该重新检查实际安装版本。

如果当前稳定通道暂未提供安全版本，应查看：

snap info lxd

确认对应通道的可用版本，并按照生产环境的变更要求选择升级方式。

2. 更新 MicroCloud

sudo snap refresh microcloud

同样需要确认更新后的实际版本。

对于 LXD 集群，应按照 Canonical 的集群更新流程协调各节点版本，避免节点之间出现不兼容情况。

3. 暂时无法升级怎么办？

最有效的临时措施是收紧管理 API 的网络访问权限。

建议优先执行以下措施：

限制管理接口访问来源。

在云平台安全组、硬件防火墙或主机防火墙中，仅允许可信管理节点连接 LXD HTTPS 端口。

关闭不必要的公网暴露。

如果仅需本地操作，可以考虑将 HTTPS API 绑定到本机回环地址：

sudo lxc config set core.https_address 127.0.0.1:8443

执行前应确认管理连接方式，避免造成远程管理中断。集群环境还需考虑节点间通信需求。

检查已有信任关系。

审查 LXD 的受信任客户端及其权限，关注不再使用的管理身份。

如果怀疑存在入侵，应进一步核查管理 API 请求记录、异常实例创建、证书信任关系变化和集群配置变更。

需要强调的是，网络访问控制只能降低攻击面。针对该漏洞的根本处理措施仍然是安装安全补丁。

Incus 官方也明确建议限制 HTTPS 监听器的网络访问，并指出该问题没有通用的配置级修复方案。

七、总结：这个漏洞暴露了什么问题？

CVE-2026-112816 值得关注的地方，在于它揭示了证书认证系统中一个容易被忽略的安全问题：

一张证书出现在客户端提交的证书链中，并不能证明客户端拥有这张证书对应的私钥。

LXD 的认证逻辑错误地信任了证书链中的其他证书，导致攻击者可能绕过身份验证。

对于开发者，这个漏洞提供了一个很有价值的安全设计案例：使用双向 TLS 时，必须正确处理证书链、私钥持有证明与身份授权之间的关系。

对于服务器管理员，建议立即完成三项工作：

1. 检查是否运行受影响版本的 LXD、MicroCloud 或相关 Incus 版本。
2. 检查 HTTPS 管理 API 是否可以被公网或不可信网络访问。
3. 安装官方补丁，并确认升级后的实际服务端版本。

尤其需要警惕那些直接向公网开放 LXD 管理接口的服务器。 一旦攻击者成功冒充高权限客户端，受到威胁的可能是整台物理服务器及其管理的所有虚拟化实例。

参考资料

• Canonical：Security advisory: Critical vulnerability found in Canonical LXD and MicroCloud
• Ubuntu Security：CVE-2026-112816
• NVD：CVE-2026-112816
• GitHub Security Advisory：GHSA-xg75-xf37-cph9
• GitHub Advisory Database：GHSA-pq55-m3w3-jh54
• CISA：SSVC 漏洞评估及 KEV 目录
• Canonical LXD Documentation：How to expose LXD to the network、How to manage the LXD snap