一张公开证书，就能冒充别人登录LXD的管理接口。Canonical在 2026年10月29日 发布的公告里，把这个身份验证逻辑错误定为 CVE-2026-112816 ，CVSS评分 10.0 。 LXD是跑在Linux主机上的系统容器与虚拟机管理器，通过HTTPS API对外提供管理能力，MicroCloud则把多台这样的主机组成集群。双向TLS（mTLS）本来是决定"哪个客户端能调这个API"的机制：握手证明客户端持有证书链中第一张证书对应的私钥，服务端再拿证书去信任库里比对。 问题出在比对的范围上。公告写得很直白：HTTPS监听器请求客户端证书却不做验证，握手只证明了第一张证书的私钥归属，链上其余证书完全由客户端控制。而修复前的所有权检查，是把客户端提交的整条链上每一张证书都拿去和信任库比对。 结果就是：只要拿到某张受信任证书的公开部分，不需要对应私钥，就能以那个身份通过认证。 公开证书从哪来 这一点最让运维意外。服务端证书会在每次TLS握手时返回，攻击者不需要任何前置访问权限就能拿到一张。客户端证书则可以被任何受信任的客户端通过证书API读取，或者从该客户端连接过的任意服务器上收集。 攻击路径因此变得很短：从一次常规连接里取得公开证书，把它作为中间证书追加进自己的证书链，就被认证成了那个身份。追加服务器自己的证书，可以进入数据库网关；在集群里追加另一台成员的证书，能拿到绕过授权检查的内部集群访问权。 一个冒名身份能摸到哪些面 公告列出了同一套所有权检查覆盖的路径，每一条都是独立的权限： 主API：集群与实例控制 指标端点：暴露遥测数据 集群网关与数据库网关：各自位于独立检查之后 证书自助续期与自助删除：冒名身份可以续期或删除信任库中的条目 基于令牌的注册，以及主机与其虚拟机之间的连接，用的是同一套比对 Canonical对影响的措辞很克制：攻击者可能仅凭另一用户的公开客户端证书冒充该用户，从而获得守护进程的信任；视受害用户的权限而定，可能拿到主机的root权限。运维层面最糟的情况是通过自助路径删除信任条目——资产失去了"谁曾被信任"的记录，而攻击者保住了已经到手的东西。 MicroCloud的版本更具体 MicroCloud在集群成员加入时犯了同样的错。公告称，攻击者可以截获一个正在加入的集群成员的公开TLS证书，然后以该成员身份通过认证。加入成员在设计上就是高权限身份：它复制配置、持有存储凭据、参与控制平面。 修复只比第一张证书 修补后的行为是一次更小的比对：只把提交链上的第一张证书——也就是握手证明了私钥的那张——拿去和信任库匹配。这一处改动覆盖了主API、指标端点、集群与数据库网关检查、自助续期与删除路径、基于令牌的注册，以及虚拟机代理连接。 公告列出的修复版本为LXD 6.10.1、5.21.9、5.0.11、4.0.15 ，以及MicroCloud 3.4.1、2.1.5 ，snap通道于2026年10月29日发布。Canonical同时说明，这些点版本正在从candidate通道滚动到stable通道——在假定一次刷新已经装上修复之前，这句话值得对着自己的主机核一遍。 当天该做什么 限制HTTPS监听器的网络访问，是Canonical给出的唯一缓解措施，并明确表示不存在基于配置的绕过办法。两个snap通道都需要刷新，然后确认服务跑在已修补的版本上，通道名只当作起点。 还有一件公告没有指派、但同样重要的事：这个检查从初始版本起就是错的，那么在这段时间里建起来的信任库都值得读一遍——哪些客户端证书被信任、谁能读到它们、这些身份是否还该留在名单里。 对做mTLS的人来说，这条教训值得记一次：信任决策只属于协议证明了私钥的那张证书，链上其余证书都只是调用方自己写下的声明。把"检查整条链"当成认证，等于把一叠公开文件变成了一串钥匙。 特别
