LXDとIncusの証明書認証回避｜管理APIの到達範囲と修正版を確認

LXDやIncusの管理用HTTPS APIを運用している場合は、到達できるネットワークを確認し、配布元が示す修正版を適用してください。CVE-2026-112816では、攻撃者が対応する秘密鍵を持っていなくても、公開証明書を使って信頼済みの相手になりすませる場合があります。管理用デーモンの権限次第ではホストのroot権限に影響します。CanonicalのMicroCloudでも影響が確認されています。公開Webサイトの証明書を交換する作業とは別に、コンテナや仮想マシンを管理する側のソフトウェアを更新する必要があります。

秘密鍵の所持を証明した相手と信頼した相手が一致しない

CanonicalのLXD・MicroCloud向け公式告知によると、相互TLSによる認証の処理が、クライアントから送られた証明書の列を信頼ストアと照合していました。TLSの処理で秘密鍵の所持を示すのは列の先頭にあるクライアント証明書です。後ろに加えられた別の証明書について、同じ接続相手がその秘密鍵を持つことは示されません。ところが影響版では、後ろの証明書が信頼ストアに一致した場合でも、対応する信頼済みの相手として認証され得ました。

通常、公開証明書は秘密鍵と分けて管理されます。接続先へ公開証明書を提示したり、運用担当者同士が照合したりすること自体は異常ではありません。今回の問題は、その公開部分を別人が持つだけで認証判定に影響を与えられる点です。このため、秘密鍵を漏らしていないことや、信頼ストアへ新しい証明書が追加されていないことだけでは、影響を否定できません。

Incus開発元のセキュリティ勧告は、HTTPSリスナーに到達できる相手が、公開部分を入手した信頼済みのクライアント、メトリクス用、サーバー用の証明書になりすませると説明しています。サーバー証明書はTLSの接続時に取得できるため、公開証明書の所在を社内で制限しているという説明だけでは足りません。Incusでは自サーバーの証明書を利用したデータベースゲートウェイへのアクセスや、別クラスターメンバーの証明書を利用した内部アクセスにも言及があります。

Canonicalは、LXDでは管理用HTTPS APIに到達でき、信頼済みクライアントの公開証明書を持つ相手がなりすませると説明しています。MicroCloudでは、参加中のメンバーの公開証明書を取得した相手が、そのメンバーになりすます可能性を示しています。Incusの勧告に記載された個別の影響を、実装や構成を確認せずそのままLXDに当てはめないでください。

更新の優先順位は管理APIへの到達経路で決める

初めに、稼働するホストとクラスターを一覧にし、製品、導入経路、稼働版、管理リスナー、接続元を記録します。インターネットへ管理APIを公開している環境は優先しますが、プライベートアドレスで待ち受けていても、社内VPN、共有ネットワーク、管理用プロキシ、開発用の踏み台からどこまで到達できるか確認が必要です。ネットワークの名前が「内部」であることと、管理者以外の接続を制限できていることは別の確認項目です。

本サイトからの提案は、ホスト上の待ち受けを調べるだけでなく、経路の両端から確認することです。OS上では、たとえば ss -lntp で待ち受けソケットとプロセスを調べ、製品設定と対応させます。その結果をクラウドのセキュリティグループ、ロードバランサー、境界ファイアウォール、ホスト側の規則と照合します。標準ポートだけを探すと、ポートを変更した待ち受けやポート転送を取りこぼします。IPv4だけを調べた場合はIPv6側を確認済みとしないでください。

運用上の到達確認には、許可された検証元を使います。管理者用の経路から管理APIに接続できることに加え、管理者用でないネットワークから同じ入口へ到達できないことを確かめます。ここで確認するのは通信経路であり、脆弱性を再現する必要はありません。ネットワーク越しの接続が想定されない単体環境でも、ローカルの管理用ソケットが利用できることを、外部からHTTPSで到達できるという判断と混同しないようにします。

更新まで時間がかかる場合は、管理用リスナーへの接続元を運用に必要な範囲へ絞ります。管理作業が不要な入口は停止を検討します。クラスターではノード間通信や既存の監視が同じ経路を使うことがあるため、遮断前に必要な通信を洗い出し、管理アクセスを復旧できる手段を確保してください。到達制限は危険な入口を減らす措置であり、証明書の誤った照合を直すものではありません。

LXDとMicroCloudはSnapの追跡チャネルを照合する

Canonicalの告知に掲載されたLXDの修正版は、6/stableが6.10.1、5.21/stableが5.21.9、5.0/stableが5.0.11、4.0/stableが4.0.15です。MicroCloudの修正版は2/stableが2.1.5、3/stableが3.4.1です。掲載された配布日は2026年10月29日で、告知はLXDのポイントリリースについて段階配布にも言及しています。6系へ移行しなければ直らないという意味ではなく、現在追跡している系列に対応する修正を確認するのが先です。

Snap構成では、snap list で現在の版とリビジョンを確認し、snap info lxd または snap info microcloud で追跡中のチャネルと提供版を照合します。Canonicalが示す更新コマンドは sudo snap refresh lxd と sudo snap refresh microcloud です。実際に導入している製品のコマンドを使い、成功表示に加えて更新後の一覧を読み直します。更新の保留や段階配布で期待した版に届かなければ、別の系列へ無計画に切り替えず、配布状況と運用上の保留設定を確認します。

UbuntuのCVE-2026-112816追跡ページでは、製品の影響とパッケージの状況を確認できます。Snapでないパッケージや自前ビルドを使う構成では、上のSnap表をそのまま適用せず、採用した配布元やビルドの修正取り込みを確認してください。管理端末にあるクライアントだけを更新しても、攻撃を受ける側のデーモンが旧版なら対応は終わっていません。

Incusは上流版とディストリビューション版を読み分ける

Incusの開発元勧告は、上流では7.6.0未満を影響版、7.6.0以上を修正版としています。ディストリビューションのパッケージには、上流と異なる番号で修正が取り込まれる場合があります。7.6.0より小さい番号だから必ず未修正とも、LTSの最新パッケージだから必ず修正済みとも判断できません。現在のパッケージを提供している配布元のセキュリティ情報で、CVE番号と修正パッケージの版を対応させます。

確認では、パッケージ管理ツールの表示だけでなく、更新されたデーモンが動いているかを確かめます。更新後に古い実行ファイルのプロセスが残っていないか、サービスを再起動した結果が記録されているか、管理先が意図したホストかを確認します。手元のコマンドで見えるバージョンがクライアントのものか、接続先サーバーのものかも読み分けます。複数の配布方法が混ざる場合、あるホストで使った更新コマンドを全台へ適用する前に構成を分けてください。

Incusの告知は、信頼ストアの更新・削除処理、ホストと仮想マシンの間のエージェント認証、証明書情報を使う認可用スクリプトにも影響を示しています。トークンやOIDCを使う環境でも、任意の証明書が認可用スクリプトに渡る経路に言及されています。ログイン画面で普段どの方式を選ぶかだけで安全と判断せず、管理API全体とカスタムの認可処理を確認してください。

全ノードの修正と普段の管理操作を確かめる

クラスターでは、作業計画にメンバーごとの更新前後の版、適用時刻、再起動の結果を残します。最初の1台で修正が確認できても、残りのノードに旧版があればクラスター全体の作業は終わっていません。共通の名前やプロキシを通す管理画面では、接続先が修正済みノードだったというだけで全台の状態を判断しないでください。ローリング更新の可否と順序は、導入している系列の手順に従います。

更新後は、普段使う管理クライアントからインスタンス一覧を取得できるか、読み取りだけを許したアカウントの権限が変わっていないか、クラスターが正常に見えるかを点検します。メトリクス取得や仮想マシンのエージェントを使う環境では、そちらも通常の経路で確かめます。認証できることだけでなく、権限を与えていない検証用クライアントが管理操作を許されないことを確認すると、更新後に設定を誤って緩めた場合にも気づけます。本稿では攻撃の再現試験は行っていません。

管理APIが到達可能だった期間は記録を保全する

修正と並行して、影響版が稼働していた期間と、管理リスナーへ到達できた接続元を見積もります。ファイアウォールやプロキシ、デーモンのログに加え、保持している場合は信頼ストアの変更履歴、インスタンスの作成・構成変更、ノード参加の記録を保全します。現在の信頼ストアだけでは、過去にどの認証が通ったか分かりません。管理者名がログに残っていても、今回のように別人になりすませる不備では、名前だけで正常操作と判断できません。

運用者が実行した変更と突き合わせ、不明な時刻のインスタンス作成、ホスト資源の割り当て変更、証明書登録の追加や削除などを調べます。複数の記録が残っている場合は、接続元、時刻、対象ノード、操作の順に照合してください。異常が見つかった環境では、ホストとその上のワークロードに調査を広げ、関連する資格情報や成果物にアクセスされた可能性を評価します。更新の適用は、更新前に行われた操作を取り消すものではありません。

確認した公式勧告が示すのは、成立条件と影響です。脆弱性の存在だけで自社への侵害を断定せず、反対に記録が残っていない期間を無被害として扱わないようにします。今回の作業記録には、製品と配布元、全ノードの修正版、管理APIの到達範囲、調査に使えた期間を残してください。