LXDのCVE-2026-112816、公開証明書で信頼済みクライアントになりすませる

TL;DR

---

Canonical LXDのHTTPS APIに、認証を回避される脆弱性CVE-2026-112816が公開された。
CVEレコードを転載したOpenCVEによると、深刻度尺度であるCVSS v4.0の基本値は10.0で、公開日は2026年10月30日だ。
LXDはコンテナと仮想マシンをまとめて管理するソフトウェアで、Dockerとは別物だ。Dockerのみを動かしている環境には影響しない。
Ubuntuを使っているだけで直ちに影響を受けるわけではないが、確認のしかたによってはLXDを使っていないのに「入っている」と誤認しやすい落とし穴がある。

秘密鍵なしで正規クライアントとして認証される仕組み

LXDのリモートAPIは、相互TLS（クライアント側もサーバーへ証明書を提示して相互に認証する方式）を採用している。
通常のTLS相互認証では、クライアントが自身の秘密鍵で署名を行い、その鍵に対応する証明書（リーフ証明書）を提示することで本人性を証明する。
TLSハンドシェイクにおいて秘密鍵の所持が検証されるのは、チェーン先頭のリーフ証明書のみだ。チェーンに含まれる残りの証明書（上位認証局などを繋ぐ証明書）は、接続元が任意に指定できる。

ところがCanonicalのアドバイザリによると、LXDは提示されたチェーン内のすべての証明書を信頼ストア（接続を許可した証明書一覧）と照合し、一致した証明書の権限でアクセスを認めてしまう実装になっていた。
そのため攻撃者は、自作の鍵で署名したリーフ証明書を用意し、中間証明書の位置に信頼済みクライアントの公開証明書を含めるだけで、そのクライアントとして認証を通過できてしまう。
公開証明書は秘密情報ではないため、提示されただけではなりすましを防げない。暗号解読も不要で、認証判定ロジックの不備を突く形だ。

flowchart TD
    A["攻撃者が自作の鍵でリーフ証明書を作成"] --> B["信頼済みクライアントの公開証明書をチェーンに追加"]
    B --> C["TLSハンドシェイクで検証されるのは攻撃者の鍵のみ"]
    C --> D["LXDがチェーン内の全証明書を信頼ストアと照合"]
    D --> E["中間証明書が信頼ストアに一致し正規クライアントとして認証"]

被害の範囲は、なりすまされたクライアントの権限に依存する。
Canonicalは、悪用された証明書の権限によってはホストの管理者（root）権限を奪われる恐れがあると説明している。
またMicroCloudでは、クラスター参加メンバーの公開TLS証明書を入手されると、そのメンバーとして不正に認証される可能性がある。

修正版と影響するバージョン

Canonicalのアドバイザリ（2026年10月29日公開）が示す修正版は次のとおりだ。

Snapのチャネル	パッケージ	修正版
6/stable	lxd	6.10.1
5.21/stable	lxd	5.21.9
5.0/stable	lxd	5.0.11
4.0/stable	lxd	4.0.15
3/stable	microcloud	3.4.1
2/stable	microcloud	2.1.5

CVEレコード上の影響バージョンには4.0.14、5.0.10、5.21.8、6.9が記載されている。
6.10.0は一覧に載っていないが、6系の修正版は6.10.1なので、6系を利用している環境は6.10.1への更新が必要になる。

UbuntuのCVEページにおける優先度は「中（Medium）」とされている。
debパッケージ形式の lxd は26.10、26.04、24.04、22.04で「Not in release（リリース対象外）」、20.04以前で「Not affected（影響なし）」となっており、更新対象はSnap版に限られる。

本脆弱性の発端は、LXDからフォークしたIncus側の報告だ。
Incusのアドバイザリ GHSA-xg75-xf37-cph9はCVSS v3.1で10.0とし、修正版として7.6.0を公開している。設定変更による回避策はないとされている。
なおIncusのアドバイザリ内のCVE欄は空欄で、Incusのリリース一覧を見ても7.6.0以降に7.0系の修正版は公開されていない（2026年11月2日時点）。

公開証明書の入手性と攻撃成立の条件

Canonicalが挙げるLXDの悪用条件は、HTTPS APIに外部から到達できることと、信頼済みクライアントの公開証明書を所持していることだ。
ただし、公開証明書の秘匿性に頼って安全とみなすのは難しい。

Incusのアドバイザリによれば、サーバー証明書はTLS接続時にサーバーから返されるため事前アクセス権なしで取得でき、これをチェーンに追加することで内部データベースゲートウェイへの接続に悪用可能と説明されている。
またクライアント証明書についても、正当な権限を持つクライアントであれば証明書APIから取得できるほか、そのクライアントが過去に接続したサーバーから採取できるとされている。
LXDの公式勧告には同経路の可否について言及がないものの、証明書が非公開であることだけを安全の根拠にはできない。

一方、HTTPS APIの外部露出については設定で確認できる。
LXDの公式ドキュメントによると、LXDの初期設定ではローカルのUnixソケット（ローカル通信用）のみで待ち受けており、ネットワーク経由の接続は受け付けない。
外部接続を受け付けるのは core.https_address を明示的に設定した場合に限られる。
ドキュメントに記載されている8443番ポートは設定例にすぎず、環境によってポート番号を変更している場合もあるため、ポート番号のみで判断せず設定値を確認する。

サーバーにおけるLXDの導入状況と確認手順

Dockerのみでコンテナを動かしているサーバーは、LXDを別途導入していなければ影響を受けない。
確認は snap list から行う。
Ubuntu 24.04には lxd-installer というパッケージがあり、/sbin/lxc と /sbin/lxd を配置する。
説明には「Wrapper to install lxd snap on demand」とあり、必要になった段階でLXDのSnapを導入するためのラッパーだ。
このラッパーが入っていると、LXDを一切使っていなくても /sbin が環境変数 PATH にあれば command -v lxd で実行ファイルのパスが返ってしまう。
パッケージのスクリプトを確認すると、Snapが存在しない状態でラッパーを実行した場合にSnapのインストールを促す処理が入っている。
意図せず導入処理を走らせないためにも、コマンドを実行する前にまずSnapの導入状況を確認する。

# LXD本体とMicroCloudのSnapがあるか確認
snap list lxd microcloud

# HTTPSで待ち受けているか（Snapが入っている場合のみ実行）
lxc config get core.https_address

# 実際に待ち受けているポートを確認
sudo ss -ltnp | grep -E 'lxd|microcloud'

snap list の出力に表示されなければ、Snap版のLXDおよびMicroCloudはこのサーバーに導入されていない。
もしSnapが導入されている場合は、core.https_address が空であっても修正版へ更新しておく。

sudo snap refresh lxd
sudo snap refresh microcloud
snap list lxd microcloud

Canonicalのアドバイザリ公開時点では、修正版が段階的に配信されていた。
更新コマンドが成功してもバージョンが修正版へ上がっているとは限らないため、最後の snap list でバージョン番号を確かめる。
修正版への更新が完了するまでは、HTTPSの待ち受けポートへのアクセス元を信頼できるホストのみに制限するファイアウォール設定（Incusのアドバイザリが緩和策として提示している方法）が有効だ。

検証コードの公開状況と悪用の有無

OpenCVEが転載する米CISAの評価では、悪用状況は「なし（none）」で、既知の悪用脆弱性カタログ（KEV）への掲載もない。
一方で、攻撃の自動化は「可能（yes）」と評価されている。

エクスプロイト情報サイトのSploitusには、PoCとして dehasoft-tr/cve-2026-112816 が登録されている。
しかし README を確認すると、内容はSnap版の確認と更新を行うシェルスクリプトであり、攻撃実証コードではない。
したがってSploitusに掲載されているこの項目は、攻撃再現コードが存在する根拠にはならない。

VPS基盤側でLXDが稼働している場合の影響

VPSを契約している場合、事業者のホスト基盤側でLXDが稼働している構成も考えられる。
その場合、仮想マシン内のOSやDockerを更新しても、基盤側の管理APIに存在する問題は解消しない。
そしてホスト側にLXDが使われているかやその修正状況は、契約者側からは確認できない。

ConoHa VPSのFAQには、ハイパーバイザー（仮想化基盤）としてKVMを採用している旨が記載されている。
今回の問題はKVMそのものではなくLXDの管理APIにあるため、KVM基盤であること自体が直ちに対応を要する理由にはならない。
ただしLXDは仮想マシンの管理にも対応しているため、KVMの採用情報だけでは管理基盤側でLXDを使っていないとまでは判断できない。
同FAQにLXDへの言及はなく、ConoHa VPSのニュース一覧の2026年10月以降の項目にも、CVE-2026-112816やLXDを対象とした告知は出ていない（2026年11月2日時点）。

ConoHa VPSの利用者が事業者の告知を確認する際の参考として、過去の別件における告知例を整理した。

日付	ConoHaの告知	利用者側の確認事項
2026年10月19日	CVE-2026-99999で新規申し込みを一時停止	ゲストからホストへ抜ける脆弱性の対応
2026年10月23日	パッチ適用済みホストを用意して受付を再開	既存サーバーのホストは順次メンテナンスが行われ、実施日時は登録メールへ個別に案内されるとされていた
2026年10月24日	緊急メンテナンスで新規申し込みを再び停止	13時40分から停止。告知は終了日時を未定とし、CVE番号を挙げていない
2026年10月30日	CVE-2026-98432の対策のお願い	VPS内のカーネルを修正版に更新して再起動する

ホスト基盤側の対応だったCVE-2026-99999では、VPS内で uname -r を実行してもホストの状態は把握できない。表示されるのはゲストOSのカーネルだからだ。
ConoHaの場合は、告知にあるメンテナンス案内メールが確認の判断材料となった。
一方、CVE-2026-98432はゲストOS内のカーネルが対象のため、利用者が自分で更新を適用して再起動する必要があった。
事業者の告知を見る際は、基盤側のメンテナンスなのか、仮想マシン内の自己対応が必要なのかを切り分けて確認することが重要だ。