Canonical 已发布安全更新,修复了影响 LXD 和 MicroCloud 的关键身份验证绕过漏洞 CVE-2026-112816。此漏洞的 CVSS 评分最高为 10.0,可允许未经身份验证的远程攻击者在不持有客户端私钥的情况下冒充受信任的 TLS 客户端。
成功利用漏洞后,攻击者可以借助伪造身份的权限访问 LXD 或 MicroCloud API。如果被信任的身份具有足够的权限,攻击者可能会获得对集群、管理的虚拟机的完全访问权限,甚至可能获得底层主机的 root 级别访问权限。
该漏洞源于对用于双向 TLS 身份验证的客户端证书链的验证不当。易受攻击的实现不会仅验证客户端证明持有相应私钥的叶证书,而是将每个客户端控制链提供的证书与受信证书进行比较。
因此,攻击者如果能够访问 HTTPS API 并获得已信任客户端的公共证书,就可以将该证书附加在攻击者控制的叶证书之后,并被接受为受信任的身份。
Canonical 在 2026 年 10 月底披露了该问题,并由 Incus 项目转交。现在已提供修复后的 LXD 和 MicroCloud 版本,并强烈建议管理员立即更新。
该漏洞在基础架构环境中尤为显著,因为 LXD 管理系统容器和虚拟机,而 MicroCloud 协调集群基础设施。管理权限的泄露可能超越单一服务,并对工作负载或主机本身提供控制。
针对 CVE-2026-112816,安全团队应优先识别互联网上或网络可访问的 LXD 和 MicroCloud HTTPS API,审查受信的客户端证书,并将成功的基于证书的身份验证与意外的源系统或非正常的管理操作进行关联。
SOC Prime 的人工智能本地检测智能平台使安全团队能够加强对网络、Linux、云、容器和身份遥测的利用和后期妥协行为的覆盖范围。
单击“探索检测”以访问相关检测内容和狩猎逻辑。要检测 CVE-2026-112816,防御者应结合易受攻击版本清单与 API 访问监控、证书认证遥测,以及对容器、虚拟机或集群配置影响的可疑管理活动。
CVE-2026-112816 分析
CVE-2026-112816 是一个影响 Canonical LXD 和 MicroCloud 的 HTTPS 监听器中的证书验证不当漏洞。
这两种产品都可以使用双向 TLS 来验证远程客户端。在正常的 mTLS 行为下,连接的客户端会展示一个证书,并证明拥有与用作 TLS 链叶的证书相关联的私钥。
问题在于,易受攻击的 LXD 和 MicroCloud 实现检查的内容超出了那个经过身份验证的叶证书。
根据 Canonical,远程 API 身份验证逻辑将客户端呈现的所有证书与受信证书存储中的条目进行比较。然而,TLS 只为叶证书证明私钥持有。呈现链中的其他证书由客户端提供,不能独立证明其对应私钥的所有权。
这造成了身份验证漏洞。
攻击者可以生成一个他们控制的证书和私钥,使用该证书作为叶,并在呈现的链中附加受信客户端的公共证书。易受攻击的服务器可能会发现该受信证书,并将连接与该受信身份关联,即便攻击者不持有其私钥。
因此,CVE-2026-112816 的细节表明,漏洞利用主要依赖于两个先决条件:
- 攻击者可以访问 LXD 或 MicroCloud HTTPS API。
- 攻击者持有目标已信任身份的公共证书。
不需要受信客户端的私钥。
这种区分解释了漏洞的严重性。基于证书的身份验证预计显示持有机密私钥,而受影响的逻辑有效地允许仅公共证书拥有即可满足部分信任决策。
默认情况下,独立的 LXD 安装不会暴露其远程 HTTPS API。《黑客新闻》指出,除非管理员通过例如 core.https_address 配置启用网络访问,否则 LXD 通常只监听其本地 Unix 套接字。
这意味着并不是每个易受攻击的 LXD 安装都可以从另一台主机远程利用。
当管理员在管理网络上启用 API 或将其暴露到互联网时,暴露风险显著增加。
MicroCloud 提供了另一个相关的攻击场景。Canonical 表示,攻击者若能截取加入 MicroCloud 集群的机器的公共 TLS 证书,可能随后可以验证为该加入成员。
CVE-2026-112816 影响的易受攻击的 Canonical LXD 版本包括 4.0.14、5.0.10、5.21.8 和 6.9 在其相应修复版本之前。
Canonical 列出的修复后的 LXD 版本为:
- LXD 6.10.1 for 6/stable channel
- LXD 5.21.9 for 5.21/stable
- LXD 5.0.11 for 5.0/stable
- LXD 4.0.15 for 4.0/stable
对于 MicroCloud,修复的版本是:
- MicroCloud 3.4.1 for 3/stable
- MicroCloud 2.1.5 for 2/stable
Ubuntu 的 CVE 记录描述称,成功利用可让未经身份验证的攻击者以一个受信的客户端进行身份验证,并通过伪造的证书链获得集群和管理的虚拟机的完全访问权。
最高 CVSS 分数 10.0 反映了网络可访问性、低攻击复杂性、不需要特权和用户交互,同时对机密性、完整性和可用性具有潜在的高影响。
最终影响取决于伪造身份的权限。
受限身份可能仅提供有限的 API 功能。高特权客户端或集群身份可以提供显着更大的访问权限。
Canonical 明确警告说,冒充特权受信用户可能导致对主机机器的 root 访问。
这可能允许攻击者:
- 管理或修改容器及虚拟机。
- 访问通过被攻破的 LXD 环境管理的工作负载。
- 修改基础架构配置。
- 创建新工作负载或更改现有工作负载。
- 干扰可用性。
- 访问伪造身份可获取的数据。
- 在权限充足时,潜在地达到具有 root-level 权限的主机。
该漏洞最初在相关的 Incus 项目中被发现,然后被转交给 Canonical 进行确认,该问题影响了 LXD 的证书链身份验证。
Incus 以类似方式描述了底层问题:服务器请求客户端证书而不验证整个提交链,而信任检查遍历每个提供的对等证书而不是限制身份验证到实际的叶证书。Incus 在版本 7.6.0 中已解决此问题。
该漏洞似乎已存在较长时间。Incus 声明其等效的身份验证逻辑自其首次发布以来一直存在。Canonical 的公共通告未提供首次引入易受攻击的 LXD 行为的确切日期。
截至 2026 年 11 月 2 日,独立的 CVE-2026-112816 PoC 和实验室再现已经公开发布。这与 11 月 1 日发布的《黑客新闻》报告有所不同,该报告称尚未发布可行的漏洞利用。公开的再现是在披露后出现的,而不是原始漏洞研究。
Canonical 和所引用的报告没有表明该漏洞已在实际攻击中被利用。
《黑客新闻》报道称,问题在美国 CISA 日期为 10 月 30 日的评估中尚未知道被利用,并且当时未被包含在 CISA 的已知利用漏洞目录中。
因此没有与 CVE-2026-112816 的利用相关的特定活动指标 (IOCs),例如已确认的恶意 IP 地址、域名、恶意软件哈希或已知的攻击者基础设施。
防御者应将注意力集中在漏洞曝光和行为上。
潜在的狩猎机会包括:
- 来自意料之外的系统的对 LXD 或 MicroCloud HTTPS API 的远程连接。
- 来自通常不为受信管理员使用的网络的成功 API 身份验证。
- 来自多个无关来源系统的受信证书身份。
- 不符合证书预期所有者的管理 API 活动。
- 意外创建、删除或修改容器和虚拟机。
- 受信证书条目的更改。
- 新的或更改的集群成员。
- 对存储、网络、配置文件、项目或实例配置的意外更改。
- 在不正常的基于证书的身份验证后很快发生的特权操作。
- 本不应被远程访问的管理接口上的 API 连接。
组织还应清点与前管理员、退役主机、自动化系统和集群成员相关的受信证书。
由于利用需要公共证书而非私钥,防御者不应仅将私钥的机密性视作对此特定漏洞的足够保护。
监控还应考虑共享的管理网络。
一个未直接暴露于公共互联网的 API 仍可能被已经获得能够到达管理接口的另一系统站稳脚跟的攻击者利用。
这使得横向移动尤为相关。一个被攻陷的工作站、服务器、CI/CD 运行器、管理主机或云工作负载,通过网络访问 LXD API 提供所需位置来利用被内部暴露的系统。
CVE-2026-112816 缓解措施
Canonical 推荐立即将受影响的 LXD 和 MicroCloud 部署升级到最新修复版本。
对于基于 Snap 的部署,管理员可以使用以下命令进行更新:
sudo snap refresh lxd
以及:
sudo snap refresh microcloud
刷新后,验证实际安装的版本,而非假设更新已成功应用。
Canonica 已在披露期间指出,一些 LXD 点版本正在从候选通道过渡到稳定通道。因此,管理员应明确确认其系统运行的是修复版本之一。
CVE-2026-112816 的主要缓解措施是升级至:
| 产品 | 修复版本 |
| LXD 6.x | 6.10.1 |
| LXD 5.21 | 5.21.9 |
| LXD 5.0 | 5.0.11 |
| LXD 4.0 | 4.0.15 |
| MicroCloud 3.x | 3.4.1 |
| MicroCloud 2.x | 2.1.5 |
Canonical 未发布能够完全消除底层身份验证缺陷的配置解决方案。
如果无法立即升级,则尽可能强烈限制对 HTTPS API 的网络访问以满足操作需求。
只有授权管理主机和被信任的基础设施应能建立与监听器的连接。
对于不需要远程管理的 LXD 安装,管理员应评估是否需要保持网络 API 启用。
对于需要远程访问的环境:
- 使用主机或网络防火墙限制 API。
- 仅允许来自专用管理网络的连接。
- 避免将 API 直接暴露于公共互联网。
- 适当时使用 VPN 或堡垒为基础的管理访问。
- 将容器和虚拟化管理基础设施与用户网络隔离。
- 监控所有成功的管理 API 请求。
- 审查受信证书并删除不再必要的条目。
这些控件减少了曝光但并未纠正易受攻击的证书验证逻辑。
运行 MicroCloud 的组织应优先更新所有相关集群成员,并审查最近的加入活动以排除意外的系统或证书身份。
管理员还应审查其受信证书存储。
删除属于退役主机、前管理员、未使用自。
使用系统或不再需要访问的身份的证书。
发现可疑活动时,在轮换凭据或修改证据之前调查受影响的主机和集群。
- 相关遥测源可能包括:
- LXD 和 MicroCloud 服务日志
- Linux 系统日志
- 防火墙和网络流量记录
- 如果适用,反向代理遥测
- 主机 EDR 数据
- 云网络日志
- 集群配置和成员历史
管理变更记录
查找意外的实例创建、修改、删除、快照活动、存储操作、网络变化和配置更新。
如果怀疑已被利用且特权证书身份被冒用,防御者应认真对待潜在的主机级妥协,因为 Canonical 确认可能的 root 访问权取决于受害者身份的权限。
事件响应者应保留相关证据并检查系统以查找持久化、未授权帐户或证书、修改服务、新工作负载、可疑进程和异常的出站网络通信。
使用 Incus 而非 Canonical LXD 的组织应分开更新至 Incus 7.6.0 或相关支持的修复版本,因为相关项目受到相同的证书链信任问题影响。
Ubuntu 还指出,其当前列出的 Ubuntu 版本中,存档打包的 LXD 版本要么没有通过受影响的包路径提供,要么不受影响,而 Canonical 的安全指南集中在 Snap 版本。管理员仍应验证其环境中实际运行的 LXD 分布和版本,而不应仅以 Ubuntu 版本假定曝光情况。 免责声明:
FAQ
检测内容可能并不适用于每个 CVE。在 SOC Prime 平台上检查当前覆盖范围。如果相关检测尚不可用,请再检查一次,因为新的威胁情报和检测内容会被持续添加。
CVE-2026-112816 是什么以及它如何工作?
CVE-2026-112816 是一项影响 Canonical LXD 和 MicroCloud 的证书验证不当的关键漏洞。易受攻击的服务器将客户控制的 TLS 链中提供的多个证书与受信证书进行比较,而不是将认证决策限制为实际证明私钥所有权的叶证书。能访问 HTTPS API 并获得受信身份公共证书的攻击者可能在不持有私钥的情况下冒充该身份。
CVE-2026-112816 的最初发现时间是什么时候?
该问题由 Incus 项目转交给 Canonical,并由 Canonical 在 2026 年 10 月底公开披露。Canonical 的安全通报发表于 10 月 28 日,相关通道跟进了修复版本,并于 10 月 30 日发布了 CVE 记录。可用的 Canonical 资源未提供研究人员首次识别底层缺陷的确切日期。
CVE-2026-112816 对系统的影响是什么?
成功利用可能允许未经身份验证的攻击者冒充受信的 LXD 或 MicroCloud 客户端。攻击者会获得该身份的关联访问权限,可能包括对集群和管理的虚拟机的控制。如果被信身份权限足够高,Canonical 警告说,利用可能导致对主机的 root 访问。此漏洞的 CVSS 评分最高为 10.0。
2026 年 CVE-2026-112816 仍会对我产生影响吗?
根据情况,将 LXD 升级到 6.10.1、5.21.9、5.0.11 或 4.0.15,并将 MicroCloud 更新到 3.4.1 或 2.1.5。更新后确认安装版本。在修补完成之前,仅允许受信管理主及网络访问 HTTPS API。Canonical 未提供完全修复证书验证漏洞的配置方案,因此升级仍是主要的补救措施。
我如何保护自己不受 CVE-2026-112816 的影响?