Tesuji「秘密鍵は漏れていない。だから、証明書認証は大丈夫」。その前提を崩す脆弱性が、LXDとMicroCloudで公表されました。
Canonicalの公式告知によると、LXDのHTTPS APIに到達でき、信頼済みクライアントの公開証明書を持つ攻撃者が、そのクライアントになりすませる問題です。なりすます相手の権限によっては、ホストのroot権限に至る可能性があります。Canonicalの公式告知
何が起きたのか
相互TLS（mTLS）は、サーバーだけでなく接続するクライアントも証明書で確認する仕組みです。今回の問題は、その認証処理が、秘密鍵を持つことを確認できていない証明書まで信頼判定に使ってしまう点にありました。
MicroCloudにも影響があり、公式告知では、クラスタに参加するメンバーの公開証明書を傍受した攻撃者が、そのメンバーになりすませると説明されています。Canonicalの公式告知
LXD側の識別子は CVE-2026-112816。UbuntuのCVEページは2026年10月30日付で公開されています。UbuntuのCVE情報
最初に「管理APIへ誰が届くか」を調べる
LXDは、標準ではローカルのUnixソケットから利用し、ネットワークには公開されません。一方、リモート操作やWeb UIを使うために、HTTPSの待ち受けを設定することがあります。LXDのネットワーク公開に関する公式文書
ここからは、その仕様を踏まえた運用上の確認案です。
- LXD／MicroCloudを使っているホストと、実際に稼働している版を洗い出す。
- HTTPSの待ち受け設定と、ファイアウォールなどで許可している接続元を照合する。
- インターネットだけでなく、社内LANやVPNの利用者、他のサーバーからの到達範囲も確認する。
「コンテナ内のアプリは非公開」という情報だけでは、ホスト側の管理APIがどこから届くかは分かりません。アプリの入口と、管理の入口を別々に確認します。
修正版と、更新後の確認
Canonicalが示した修正済みSnap版は次のとおりです。公開されている表では、いずれも2026年10月29日リリースです。修正版の公式一覧
| 製品 | Snapチャンネル | 修正済み版 |
|---|---|---|
| LXD | 6/stable | 6.10.1 |
| LXD | 5.21/stable | 5.21.9 |
| LXD | 5.0/stable | 5.0.11 |
| LXD | 4.0/stable | 4.0.15 |
| MicroCloud | 2/stable | 2.1.5 |
| MicroCloud | 3/stable | 3.4.1 |
公式の案内は、利用中のチャンネルで提供される最新版への更新です。この表は告知時の修正版を示すもので、現在の最新版一覧ではありません。Snap以外の配布物は、利用している提供元の修正状況を確認してください。
運用では、更新コマンドの成功に加え、各ホストで修正済みのデーモンが動いていることと、必要な管理操作・ワークロードが動くことを確認します。公式告知には段階的な配信への言及もあるため、自動更新の設定だけで反映済みとは判断しません。Canonicalの更新案内
今回の手筋：認証・到達範囲・更新確認を組み合わせる
証明書認証にも実装の不具合は起こります。管理APIの到達範囲を絞ることと、認証処理の修正を届けることを、両方進めます。
対応記録には「対象ホスト／稼働版／管理APIの到達範囲／更新後の確認結果／担当と確認日時」を残す。この一組をそろえると、修正版が出たというニュースを、自分たちの対応がどこまで進んだかという判断につなげられます。
2026年11月2日に上記の公開情報を確認。本稿は公式情報の解説と運用上の確認案であり、特定環境の調査・更新結果を報告するものではありません。