CVE-2026-112816 LXD / MicroCloud｜影響判定と更新

はじめに

2026年10月28日、Canonical は LXD と MicroCloud に影響する重大な脆弱性 CVE-2026-112816 を公表しました。HTTPS API の相互 TLS（mTLS）認証で、クライアントが送信した証明書チェーンの扱いに不備があり、信頼済みクライアントの公開証明書を入手した攻撃者が、そのクライアントになりすませる問題です。

CVSS v4.0 の基本値は 10.0 ですが、対応を判断するうえで重要なのは「HTTPS API を待ち受けているか」「どこから到達できるか」「snap が実際に修正版へ更新されたか」の 3 点です。修正版は snap の段階配布で展開されたため、更新コマンドを実行しただけでは修正済みとは限りません。

本記事では、Canonical のアドバイザリ、CVE レコード、LXD / MicroCloud の公式ドキュメントをもとに、仕組み、影響判定、更新手順、更新後の確認を整理します。記載するコマンドと手順は公式ドキュメントに基づくもので、筆者による実機検証は行っていません。

結論として、HTTPS API（core.https_address）をネットワークへ公開している LXD と、MicroCloud クラスタは対応が必要です。track ごとの修正版（LXD 6.10.1 / 5.21.9 / 5.0.11 / 4.0.15、MicroCloud 3.4.1 / 2.1.5）へ更新し、全メンバーで snap の実バージョンを確認してください。証明書の再発行やローテーションでは認証ロジックの不備は解消しないため、修正版の適用が根本対策です。

CVE-2026-112816 とは｜公開証明書で認証回避できる仕組み

CVE-2026-112816 は、LXD の HTTPS リスナーにおけるクライアント証明書の検証不備（CWE-295）です。CVE レコードでは、細工した証明書チェーンにより、未認証の攻撃者が任意の信頼済みクライアントとして認証され、クラスタと管理下の仮想マシンへのフルアクセスを得られると説明されています。Canonical によると、この脆弱性は Incus プロジェクトから報告され、LXD にも影響することが確認されました。

理解に必要な証明書の用語

リーフ証明書

接続してきたクライアント自身の証明書です。TLS ハンドシェイクでは、クライアントがこの証明書に対応する秘密鍵で署名し、鍵を所有していることを示します。

中間証明書

本来はリーフ証明書と信頼の起点（ルート CA）をつなぐために、チェーンに添えて送られる証明書です。送信側が任意に添付でき、添付しただけでは対応する秘密鍵の所有は証明されません。

信頼ストア

LXD が接続を許可するクライアント証明書の登録先です。lxc config trust add などで登録した証明書が照合の対象になります。

公開証明書と秘密鍵

公開証明書は接続のたびに相手へ提示される公開情報で、秘匿を前提としていません。なりすましを防ぐ根拠になるのは、証明書に対応する秘密鍵を所有していることです。

正常な mTLS 認証と脆弱な検証処理の違い

Canonical のアドバイザリによると、LXD の mTLS 認証処理は、クライアントが送信したすべての証明書を信頼ストアの登録内容と照合していました。しかし、秘密鍵の所有を証明しているのはリーフ証明書だけです。

参考: Canonical Security Advisory（Ubuntu Discourse）
“only the leaf certificate proves ownership of the signing key.”
（署名鍵の所有を証明するのはリーフ証明書だけです。）
https://discourse.ubuntu.com/t/security-advisory-critical-vulnerability-found-in-canonical-lxd-and-microcloud/90557

攻撃者は、自分で生成した鍵ペアのリーフ証明書を先頭に置き、その後ろに信頼済みクライアントの公開証明書を中間証明書として添えて接続します。ハンドシェイクで攻撃者が証明しているのは自分のリーフ証明書の鍵だけですが、チェーン内の証明書が信頼ストアと一致するため、信頼済みクライアントとして扱われていました。攻撃者は信頼済みクライアントの秘密鍵を取得しておらず、公開情報である証明書をチェーンに含めるだけでなりすましが成立する点が、この脆弱性の本質です。

修正内容と、証明書のローテーションで解決しない理由

LXD の修正を stable-6 ブランチへ取り込んだ GitHub のプルリクエスト #19426 では、認証に使う証明書をピア証明書リストの先頭、つまりリーフ証明書だけに限定しています。コミットの対象は HTTPS API の認証処理に加え、クラスタ、vsock、lxd-agent の認証処理にも及びます。これは修正したコードの範囲であり、Canonical のアドバイザリが攻撃経路として説明しているのは、HTTPS API と MicroCloud のメンバー参加時の経路です。

不備は証明書の照合ロジックにあるため、クライアント証明書を再発行・ローテーションしても、新しい証明書が公開情報として入手されれば同じ手口が成立すると考えられます。ローテーションは侵害が疑われる場合の事後対応として検討の余地はありますが、根本対策は修正版の適用です。

攻撃成立条件と影響｜LXD HTTPS API が対象になる構成

攻撃の成立には次の 3 条件がそろう必要があります。CVSS の値だけで判断せず、自社環境で条件が満たされるかを確認してください。

• 攻撃者が対象の LXD / MicroCloud の HTTPS API にネットワーク経由で到達できる
• 攻撃者が信頼済みクライアントの公開 TLS 証明書を入手している
• 対象が修正前のバージョンで動作している

LXD は既定では HTTPS API を公開しません。

参考: How to expose LXD to the network（LXD documentation）
“LXD can be used only by local users through a Unix socket”
（既定では、LXD は Unix ソケット経由でローカルユーザーだけが利用できます。）
https://canonical.com/microcloud/docs/default/lxd/howto/server_expose/

HTTPS API がネットワークで待ち受けるのは core.https_address を設定した場合で、リモートクライアント、Web UI、運用自動化などで利用されます。クラスタ構成では、クラスタ通信用の cluster.https_address も設定されます。LXD を導入しているだけで外部から攻撃可能になるわけではなく、HTTPS API へ到達できる環境が対象です。

公開証明書の入手経路と MicroCloud 固有の攻撃経路

公開証明書は秘匿を前提としない情報で、管理端末のクライアント設定、運用自動化ツールの設定、構成管理リポジトリなど、複数の場所に配布・保管されていることがあります。MicroCloud については、クラスタへ参加するメンバーの公開 TLS 証明書を傍受し、参加済みメンバーとして認証できる経路があると Canonical が説明しています。

なりすまし後に想定される影響

認証回避後に実行できる操作は、なりすまされたクライアントの権限に依存します。制限のないクライアントやクラスタメンバーとして認証された場合は、次のような影響が考えられます。

• LXD / MicroCloud の管理 API への不正アクセスと設定変更
• クラスタ構成の変更や管理操作
• コンテナ・仮想マシンの作成、削除、停止、コマンド実行
• 権限によってはホストの root 権限の取得

Canonical のアドバイザリも、悪用される証明書の権限によってはホストの root 権限取得につながる可能性があるとしています。一方、特定のプロジェクトに制限した（restricted）クライアントになりすました場合、操作は原則としてその権限の範囲に限られます。

悪用状況・公開 PoC・CISA KEV（2026年11月2日時点）

同じ SSVC 評価では、Automatable: yes、Technical Impact: total とされています。悪用報告がないことは安全を意味しないため、条件に該当する環境では早期の更新を推奨します。

影響バージョンと修正版｜LXD 6.10.1 / 5.21.9 の確認ポイント

Canonical は 2026年10月29日に、各 track の修正版 snap を公開しました。CVE レコードが LXD の影響範囲として挙げるバージョンとあわせて整理します。

表の影響バージョンは、CVE レコードの affected 範囲を転記したものです。この範囲外の古いバージョンが安全という意味ではありません。たとえば 5.21.8 より前の 5.21 系は、2026年9月に公表された別の重大な脆弱性の修正も含みません。Canonical はすべての LXD / MicroCloud ユーザーに更新を呼びかけているため、バージョンを問わず、追跡している track の修正版以上へ更新してください。

snap の段階配布に注意する

LXD の公式ドキュメントは、snap の更新がプログレッシブリリースとして配信され、マシンごとに更新が届く時期が異なると説明しています。Canonical によると、今回の修正版も candidate から stable へ段階的に展開されました。channel ごとに stable へ到達した時期が異なるため、各 channel の配布状況は snap info lxd で確認してください。

sudo snap refresh lxd が正常終了しても、修正版に到達したとは限りません。追跡 channel と、実際にインストールされたバージョンの両方を確認してください。

MicroCloud の公式手順に従って snap refresh --hold を設定している環境では、修正版が stable に到達しても自動更新では適用されません。次の手順で、snap 名を指定して手動で更新してください。

Ubuntu CVE ページの「Not affected」の読み方

Ubuntu の CVE ページでは、Ubuntu アーカイブの deb パッケージ lxd について、26.10 / 26.04 LTS / 24.04 LTS / 22.04 LTS が「Not in release」、20.04 LTS / 18.04 LTS / 16.04 LTS が「Not affected」と表示されています。これは deb パッケージのステータスであり、Canonical が修正版を案内しているのは snap 版です。この表示を根拠に、snap 版 LXD を影響なしと判断しないでください。

CVSS 10.0 と Ubuntu priority「Medium」の違い

CVE レコードでは、CNA である Canonical が CVSS v4.0 基本値 10.0（Critical、CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H）を付与しています。一方、Ubuntu CVE ページの priority は Medium です。

CVSS は脆弱性そのものの技術的な深刻度を示す指標で、Ubuntu priority は Ubuntu セキュリティチームが Ubuntu の配布物を対象に付ける優先度です。両者は目的も対象も異なるため、単純に比較できません。priority が Medium であることは、snap 版の更新優先度を下げる根拠にはなりません。

自社環境の影響確認手順｜snap・HTTPS API・信頼済みクライアント

次の 3 点を順に確認し、影響の有無と更新の優先度を判断します。コマンドは公式ドキュメントに記載されたもので、出力形式は環境やバージョンにより異なります。

snap list lxd microcloud
snap info lxd
snap info microcloud

lxc config get core.https_address
lxc config get cluster.https_address

lxc config trust list

lxc auth identity list

LXD snap 更新と MicroCloud セキュリティ更新の手順

Canonical のアドバイザリが案内する基本コマンドは次の 2 つです。単体の LXD サーバーとクラスタでは、実施方法が異なります。

sudo snap refresh lxd
sudo snap refresh microcloud

単体の LXD サーバーを更新する

単体サーバーでは、snap を更新したあと、インストールされたバージョンを確認します。

sudo snap refresh lxd
snap list lxd

Snap の公式ドキュメントによると、hold は自動更新や snap 名を指定しない一括更新を抑制する設定で、snap 名を指定した更新は hold を設定したままでも実行できます。単体サーバーでは、--cohort="+" の指定も必須ではありません。Version が修正版に達していない場合は、段階配布がまだ届いていない可能性があるため、時間を置いて再確認してください。

MicroCloud クラスタを更新する

MicroCloud の公式ドキュメントは、MicroCloud、LXD、MicroCeph、MicroOVN の各 snap について、全クラスタメンバーで常に同じバージョンを動かす必要があるとしています。バージョンが揃わない間もデータプレーンは動作しますが、メンバーやインスタンスの追加・削除など、コントロールプレーンの変更はできません。

通常の更新順序は MicroCeph → MicroOVN → LXD → MicroCloud で、同じコンポーネントを全メンバーで更新してから次へ進みます。Canonical のアドバイザリが更新対象として示しているのは lxd と microcloud の snap です。MicroCeph / MicroOVN の更新ではストレージやネットワークに一時的な影響が出る可能性があるため、今回の対応に含めるかは、保留中の更新の有無と保守計画をもとに判断してください。あわせて更新する場合は、公式の順序に従い LXD より先に実施します。

sudo snap refresh lxd --cohort="+"

sudo snap refresh microcloud --cohort="+"

sudo microcloud status

MicroCloud を使わない LXD クラスタでも、メンバー間でバージョンを揃える必要がある点は同じです。LXD の snap 管理ドキュメントに従い、cohort を設定したうえで全メンバーを更新してください。

更新後に確認すること

• 全メンバーで snap list lxd microcloud の Version が修正版以上になっている
• Tracking が想定どおりの channel で、クラスタでは Notes に in-cohort が表示されている
• sudo microcloud status（MicroCloud）や lxc cluster list（LXD クラスタ）で全メンバーが正常に見えている
• lxc list でインスタンスが表示され、テスト用インスタンスの起動・停止ができる
• 正規のリモートクライアント、Web UI、運用自動化ツールから認証できる
• 運用方針に応じて、更新の保留を再設定している

更新できない場合の暫定対策と侵害調査

根本対策は修正版の適用です。保守時間の調整などで即時に更新できない場合は、攻撃成立条件のうち「HTTPS API への到達」を狭める対策でリスクを下げます。クラスタ環境では、変更が管理通信やメンバー間通信を妨げないことを事前に確認したうえで実施してください。

前述のとおり、証明書のローテーションだけでは認証ロジックの不備は修正されません。暫定対策を実施した場合も、修正版の適用計画は並行して進めてください。

API の公開停止と LXD デーモンの停止は別の操作です。LXD の公式ドキュメントでは、sudo snap stop lxd でデーモンを停止すると、実行中のインスタンスもすべて停止するとされています。API を閉じる目的でデーモンを停止しないよう注意してください。

侵害調査の観点

HTTPS API が修正前に広い範囲から到達可能だった環境では、次の観点で調査することを推奨します。

• 想定外の送信元から HTTPS API への接続がないか
• 信頼済みクライアントや identity の一覧に、不審な追加・変更がないか
• インスタンスの不審な作成・削除・設定変更、コマンド実行がないか
• クラスタメンバーの追加・削除など、クラスタ構成に予期しない変更がないか
• ホスト上に不審なプロセスやファイル変更がないか

調査に使う情報源は、目的によって次のように分かれます。

LXD の公式ドキュメントは、本番環境ではイベントを Loki などの専用システムへ保存する構成を案内しています。snap の設定オプションには、ログイベントを syslog へ送る daemon.syslog もあります。こうした記録を事前に残していない環境では、ログに痕跡がないことを根拠に侵害なしと判断しないでください。

更新後の監視には lxc monitor を使えます。lifecycle イベントでは、インスタンスの起動・停止などを確認できます。

lxc monitor --type=lifecycle --pretty

LXD 6.10.1 のドキュメントでは、認証試行や認可判定を示す security イベントの監視も説明されています。旧 track で利用できるかは、対象バージョンのドキュメントで確認してください。

lxc monitor --type=security --pretty

まとめ

CVE-2026-112816 は、mTLS 認証でリーフ証明書以外の証明書も照合していたため、公開証明書だけでなりすましが成立する脆弱性です。対応の要点は、HTTPS API の公開状況で影響を判定し、snap の実バージョンで修正の完了を確認することです。

• 秘密鍵の所有を証明するのはリーフ証明書だけで、修正版はリーフのみで認証する。
• 影響を受けるのは HTTPS API を公開した LXD と MicroCloud クラスタ
• 修正版は LXD 6.10.1 / 5.21.9 / 5.0.11 / 4.0.15、MicroCloud 3.4.1 / 2.1.5
• 段階配布のため、更新後は全メンバーで snap list の実バージョンを確認する。
• MicroCloud では LXD を全メンバーで並行更新し、microcloud status で確認する。
• Ubuntu の deb ステータスや priority を理由に snap 版の対応を遅らせない。
• 証明書のローテーションでは解決せず、即時更新できない場合は到達性を絞る。

以上、最後までお読みいただきありがとうございました。