LXD 和 Incus 的证书认证出了问题：没有私钥，为什么也能冒充客户端？

管理接口为什么会相信一张证书

管理容器和虚拟机的 API 不能让谁连上都直接操作，因此 LXD 等工具支持用客户端证书识别调用方。正常情况下，客户端在 TLS 握手中出示证书，还要证明自己持有与之对应的私钥；服务端再决定这个身份能做什么。公钥证书可以公开，私钥才是不能交出去的那一部分。

Canonical 近期披露的 CVE-2026-112816 打破了这个前提：能够访问受影响 HTTPS API 的攻击者，在满足证书条件时可能冒充受信任的客户端，而不需要那名客户端的私钥。Incus 项目也公布了同类认证与授权绕过问题。冒充身份之后能做什么，取决于被冒充身份及具体产品；管理员级身份可能导致对宿主机的 root 控制。

这不是“HTTPS 加密被破解”，而是服务把客户端提交的一部分证书材料当成了已经证明身份的证据。理解证书链在握手里各自负责什么，就能看清问题。

一条证书链里，并不是每张证书都证明了私钥

客户端发起双向 TLS 连接时，可以提交一条证书链。链的第一张是客户端使用的叶子证书；握手中的签名证明连接者持有与它匹配的私钥。后面的证书通常用于帮助建立信任路径，不能仅仅因为它们出现在客户端发来的列表里，就认为连接者也持有每张证书对应的私钥。

Canonical 的说明指出，旧版远程 API 认证逻辑却把客户端提交的每张证书都拿去与信任库比对。结果是，攻击者只要让自己提交的链里出现一张已受信任的公开证书，就可能让服务把连接识别为另一名可信客户端；握手签名证明的仍然只是第一张证书的私钥归属。补丁的意义，是让认证依据与实际完成私钥证明的证书对应起来。

这也解释了为什么“对方没有偷到管理员私钥”仍不能排除风险：公开证书本来就不是秘密。Canonical 对 LXD 的描述要求攻击者能够取得受信任客户端的公开证书；MicroCloud 在成员加入过程中也可能暴露相关公开证书。

Incus 不能简单照搬 LXD 的前提

Incus 项目在自己的安全公告中说明，受影响的 HTTPS 监听器会请求客户端证书，但认证和证书归属检查比较了链中的每张证书。项目还指出，服务器证书会在 TLS 握手时返回；在其描述的特定路径中，仅有网络可达性也可能足以获取可被滥用的公开证书。

因此排查 Incus 时，不应只问“客户端证书有没有外泄”。先确认 HTTPS 管理监听是否启用、谁能访问，以及是否为集群；再按项目公告调查认证、证书信任库和集群访问记录。Incus 公告使用独立的 GHSA 编号，不能直接把 LXD 的 CVE 版本列表套到 Incus。

修复要对照产品和分支

Canonical 给出的 Snap 修复版本包括：LXD 6/stable 为 6.10.1，5.21/stable 为 5.21.9，5.0/stable 为 5.0.11，4.0/stable 为 4.0.15；MicroCloud 2/stable 为 2.1.5，3/stable 为 3.4.1。先确认安装的产品、版本和通道，再按现有运维流程更新，不要为了套用另一分支的版本号直接切换通道。

例如使用 Snap 的环境，可以先用下面两条命令查看当前安装与通道；MicroCloud 用户把 lxd 替换为 microcloud。Canonical 公告提醒这些修复曾从 candidate 向 stable 逐步发布，因此执行刷新后仍需确认实际安装版本。Incus 上游公告列出 7.6.0 为修复版本；通过发行版软件包或其他渠道安装时，应同时查看该渠道的安全公告和回移状态。

snap list lxd
snap info lxd

更新前后该看什么

先盘点管理 HTTPS 接口的可达范围。公网、租户网络或不受信任的内部网能否直接访问，与它是否“只供管理使用”不是一回事。升级前无法立即消除风险时，应按业务拓扑限制到可信管理来源；Incus 官方将限制监听器的网络访问列为临时措施，并指出没有配置层面的漏洞修复。

更新后确认运行实例与集群成员都已安装对应修复，检查异常 API 调用、证书信任库变化、集群成员变更及容器或虚拟机配置；发现可疑活动时按应急流程保存日志和证据。限制端口能减少接触面，不能替代修复认证逻辑。

Ubuntu 的漏洞跟踪页还对发行版归档中的 lxd 包单独列出了“不在发行版中”或“不受影响”等状态。那个表格不能直接推出同一台 Ubuntu 主机上的 LXD Snap 没有问题：安装来源不同，应该分别核对。