一张本来就公开的证书，为什么能让别人冒充你接管 LXD 集群

Canonical 在 10 月 29 日挂出一条安全公告，标题里直接写了 critical，评分 10.0。洞的编号是 CVE-2026-112816，出在 LXD 和 MicroCloud 上。它闹心的地方不在分数，在利用门槛——不需要私钥，不需要密码，也不需要你手里有对方的任何东西，只要一张本来就公开的证书。

先说它是怎么成的。

LXD 的远程 API 走的是 mutual TLS，也就是 mTLS：客户端连上来得递一张证书，服务端拿这张证书去自己的 trust store 里核，认了才放行。问题出在「拿哪一张去核」。服务端校验的时候，是把客户端递上来的整条证书链里、每一张 peer 证书都拿去和 trust store 比对。可一条链里，只有最底下那张叶子证书能证明「私钥归谁」；中间那些中间证书，本来就是公开的、谁都能拿到。

于是构造就来了：攻击者手上只要有任意一个受信客户端的公开证书——这个东西太好拿了，TLS 握手时会发，证书透明日志里躺着一堆——把它塞进中间证书的位置，服务端一路比下来，比中了，就认。

它等于把「你有没有私钥」这件事，降级成了「你手里有没有一张公开的证书」。而公开证书，本来就不该是秘密。

这个洞是 Incus 团队先发现、再报给 LXD 的。Incus 就是当初从 LXD 分出去的那个 fork——分出去的兄弟先发现了爹的 bug，这事在圈里已经被拿来当谈资了。

后果取决于攻击者冒充的是谁。冒充一个普通客户端，可能只是看看；冒充的是管理员那条身份，就直接接管整个 LXD 集群，底下的容器、虚机全在射程里；被冒充的身份权限够高，宿主机 root 也一起给了。MicroCloud 还多一层麻烦：它能拦下正在加入集群的那个新成员的公开 TLS 证书，之后拿这个身份冒充那个成员。

触发的前提就一条：能摸到 LXD / MicroCloud 的 HTTPS API。API 只在内网、外面够不着的，优先级可以往后放；对着公网开着的，得立刻动。

这里有个特别容易踩空的地方。Ubuntu 的 CVE 查询页面上，把 lxd 的 deb 包标成了「不受影响 / 未发布」——因为这个洞的修复只走 snap。也就是说，如果你只盯着 apt 那套安全更新流程、只等 apt upgrade，这个洞你一条通知都收不到。用 snap 装的环境默认一天刷四次，一般会自己更上；但设过 refresh hold 把刷新按住的，最多能拖到 90 天。

影响版本 / 修复版本：

组件	受影响	修复
LXD	4.0.14 / 5.0.10 / 5.21.8 / 6.9.x	4.0.15 / 5.0.11 / 5.21.9 / 6.10.1
MicroCloud	2.x / 3.x	2.1.5 / 3.4.1

修复是 10 月 29 日起分通道渐进推的，所以「装到最新」不等于「已经修了」，妥当点的做法是核一下版本号。

一条自查：

lxd --version; snap list lxd 2>/dev/null        # 对照 4.0.15 / 5.0.11 / 5.21.9 / 6.10.1
snap list microcloud 2>/dev/null                # 对照 2.1.5 / 3.4.1
snap refresh --list 2>/dev/null                 # 有没有被 hold 住、刷新失败
ss -tlnp | grep -E ':(8443|8444)\b'             # API 端口是不是对 0.0.0.0 开着

官方明确说没有 workaround。真要在补丁之前先处理一批，只有一条路：把 HTTPS API 限制在可信主机、可信网段，其他的先堵在外面。

同类「不用登录就能做事」的洞，我们写过两回：一个是 Atlassian 自建版那个 9.3 分、不用登录就能读走配置文件的洞，另一个是顺着一个 SSH 转发摸到 root 才能碰的东西的那条链。LXD 这回的落点不太一样，它坏的不是某个接口的写法，是校验证书时把「链上每一张」都当成了信任依据——可一条链里，本来只有最底下那张叶子证书能证明私钥归谁。

Canonical 官方公告：https://discourse.ubuntu.com/t/security-advisory-critical-vulnerability-found-in-canonical-lxd-and-microcloud/90557

评论