要点
- Canonical のコンテナ・仮想マシン基盤 LXD と MicroCloud に、認証をすり抜けられる欠陥（CVE-2026-112816）が見つかった。深刻度は最高の CVSS 10.0 である。
- LXD の API にネットワークから届く攻撃者は、登録済みの利用者の「公開」証明書を持っているだけで、その利用者になりすませる。秘密鍵はいらない。
- 修正版はすでに出ており、LXD をネットワーク越しに使っているなら早めの更新が要る。
何が起きたか
LXD は、Canonical が開発している仕組みだ。1台のサーバーの上で、たくさんのコンテナ（軽い仮想のサーバー）や仮想マシンを動かし、まとめて管理する。MicroCloud は、LXD を使って小さなクラウドを組むための製品である。
LXD は、ネットワーク越しに操作を受け付けるときに、相手を電子証明書で確かめる。登録済みの証明書を持つ相手は、そのまま受け入れる。登録されていない証明書のときは、サーバーがトークン（登録のための文字列）を求める。
問題は、この確かめ方にあった。証明書を使った本人確認で、相手が秘密鍵を持っていると示せるのは、送られてきた束の先頭の1枚だけだ。束のほかの証明書は、だれでも付け足せる。Canonical の advisory によると、LXD は束の中の証明書をどれも登録済みの一覧と比べていた。このため、先頭以外に登録済みの証明書が紛れていても、通してしまっていた。
公開証明書は、名前のとおり人に見せる前提のものだ。攻撃者は秘密の鍵を盗まなくてよい。被害の大きさは、だれになりすますかで変わる。advisory は、権限の強い利用者になりすませば、サーバー本体の root 権限（いちばん強い管理者の権限）まで握られるおそれがあると書いている。CVE の記録には、クラスター（LXD サーバーのまとまり）と、そこで動く仮想マシンを乗っ取れると書かれている。
MicroCloud で狙われるのは、クラスターへの参加の場面だ。advisory によると、参加の途中で新しいサーバーの公開証明書を手に入れた攻撃者は、参加を終えたそのサーバーとして認証を通れる。
Canonical によると、この問題は別の製品 Incus の開発チームが知らせてきたもので、LXD でも同じことが確かめられた。Incus 側も 2026年10月29日に同じ種類の問題を公表している。Canonical の advisory は10月28日付けで、修正版の日付は10月29日。CVE の記録は10月30日（日本時間10月31日）に公開された。
日本の利用者への影響
日本で LXD がどれだけ使われているか、日本の組織に影響が出ているかについては、確かめた一次情報には書かれていない。
当たるかどうかは、使い方で大きく変わる。LXD は、初めの設定では同じサーバーの中からしか操作を受け付けない。ネットワーク越しの操作を有効にしていて、しかもその窓口に攻撃者が届くときだけ、この欠陥を突かれる。インターネットから LXD の窓口に届く状態なら、とくに危ない。
今すぐやること
- 自分の会社や担当のサーバーで、LXD か MicroCloud を使っていないか確かめる。開発チームが知らないうちに入れていることもある。
- 使っているなら、すぐ更新する。Canonical は、LXD も MicroCloud も、いま使っている系統（channel）の最新版にするよう求めている。
- 更新のあとで、本当に修正版になったかを確かめる。Canonical によると、LXD の修正版は段階的に配られている途中だ。
- LXD の操作の窓口を、インターネットに出していないか確かめる。出す必要がないなら、社内のネットワークや決まった相手だけに絞る。
- 登録済みの利用者の一覧を見直し、もう使わない証明書を消す。なりすまされる相手が減る。
背景
少し前の2026年10月17日には、認証局（電子証明書を出す会社）eMudhra の中間 CA 証明書8つについて、ある研究者が秘密鍵を割り出したと報告した。Qualys によると、鍵の乱雑さが足りず、計算で求められる状態だった。Chrome、Mozilla、Apple はその TLS 証明書を、Microsoft はコード署名用の2つの証明書をブロックした。あれは、鍵そのものが割り出されて証明書が信用できなくなった話だった。
今回の LXD の件は、鍵がまったく漏れていなくても、証明書の確かめ方の誤りだけでなりすませてしまう。証明書を使う認証では、「誰の鍵で署名されているか」を最後まで確かめないと、仕組み全体が崩れる。Canonical の別の製品（snap-openstack）でも、同じ考え方で、束の先の1枚だけを確かめる直しが入っている。
技術者向けの詳細
- CVE: CVE-2026-112816。CWE-295（証明書の確かめ方の誤り）。CNA は Canonical。
- CVSS v4.0: 10.0（
AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H）。 - CISA の SSVC: Exploitation は none、Automatable は yes、Technical Impact は total（2026-10-31 時点）。
- 原因: mTLS の認証で、クライアントが送った証明書の束を全部、信頼済みの一覧と照らしていた。リーフ（束の先の1枚）だけを照らすべきだった。
- 修正版（snap の channel ごと）:
lxd6/stable: 6.10.1lxd5.21/stable: 5.21.9lxd5.0/stable: 5.0.11lxd4.0/stable: 4.0.15microcloud3/stable: 3.4.1microcloud2/stable: 2.1.5
- CVE の記録が当たるとする範囲: 4.0.14 以上 4.0.15 未満、5.0.10 以上 5.0.11 未満、5.21.8 以上 5.21.9 未満、6.9.0 以上 6.10.1 未満。Canonical の advisory は修正版だけを挙げているので、修正版より古い版は当たるとみて扱う。
- LXD の修正版は candidate から stable へ段階的に配られている（Canonical の advisory による）。更新したあとで版を確かめること。
- 確かめ方と更新（版を見るのは snap の標準の使い方。advisory が示しているのは
snap refreshだけ）:
snap list lxd microcloud
lxc config get core.https_address # ネットワーク越しの窓口の設定を見る（初期設定ではネットワークに出ていない）
sudo snap refresh lxd
sudo snap refresh microcloud
- Incus 側の advisory: GHSA-xg75-xf37-cph9。Incus の利用者は Incus 側の修正版を確かめること。
- Canonical は、更新のほかの一時的な対策を示していない。