LXDの脆弱性CVE-2026-112816とは、証明書チェーンの検証不備で信頼済みクライアントになりすませる問題と修正版

Canonicalが開発する、コンテナと仮想マシンの管理ソフトウェアLXDに、証明書の検証不備の脆弱性CVE-2026-112816が見つかりました。LXDのHTTPS APIに到達できる攻撃者が、信頼済みとして登録されたクライアントの公開証明書を持っていれば、そのクライアントになりすまして認証を通れます。CVEを採番したCanonicalは、CVSS v4.0で最高の10.0(Critical)と評価しています。

Canonicalは2026年10月28日にアドバイザリを公開し、LXDとMicroCloudのすべての利用者に、直ちに最新版へ更新するよう求めました。なりすました相手の権限によっては、ホストのroot権限を得られるとしています。

この記事は、LXDやMicroCloudで開発環境、CI、ホスティングの基盤を運用するエンジニアに向けて、脆弱性の仕組み、影響を受ける構成、修正版、更新できない間の暫定策を、CVEレコード、Canonicalのアドバイザリとリリースノート、LXDの公式ドキュメントで整理します。攻撃を再現する手順は扱いません。事実は執筆時点(2026年11月2日)で確認できた範囲に限ります。

CVE-2026-112816はLXDの証明書チェーン検証の不備#

LXDは、Linuxの上でシステムコンテナと仮想マシンを一元的に管理するソフトウェアです。開発環境やCIの実行環境、小規模なホスティングの基盤として使われ、複数台を束ねたクラスタも組めます。MicroCloudは、LXDを中心に複数のサーバーをまとめて構築するCanonicalの製品です。

CVEレコードによると、CVE-2026-112816はLXDのHTTPSの待ち受けにある証明書の検証不備(CWE-295)です。認証のない攻撃者が、細工した証明書チェーンを使って任意の信頼済みクライアントとして認証され、クラスタと管理下の仮想マシンへの完全なアクセスを得られるとしています。

CVEレコード(CNAはCanonical)は、Canonical LXD 4.0.14、5.0.10、5.21.8、6.9から、それぞれ4.0.15、5.0.11、5.21.9、6.10.1より前の版のHTTPSの待ち受けにある不適切な証明書検証により、認証のない攻撃者が細工した証明書チェーンを使って任意の信頼済みクライアントとして認証され、クラスタと管理下の仮想マシンへの完全なアクセスを得られると記載しています。

末端の証明書以外を照合していたことが原因#

LXDのリモートAPIは、クライアント証明書を使う相互TLS認証で利用者を識別します。公式ドキュメントによると、サーバーはクライアントの証明書が信頼ストアにあれば接続を許可し、なければトークンの入力を求め、一致した場合に証明書を信頼ストアへ追加します。

TLSのクライアント認証では、クライアントは末端の証明書と、それを発行した中間の証明書を並べたチェーンを送ります。そのうえで、末端の証明書に対応する秘密鍵で通信の内容に署名し、その証明書の持ち主であることを示します。中間の証明書は、チェーンの一部として添えられているだけのデータです。

Canonicalのアドバイザリによると、LXDとMicroCloudの認証の処理は、クライアントが送ったすべての証明書を信頼ストアの登録内容と照合していました。そのため攻撃者は、自分で作った鍵と証明書を末端に置き、信頼済みのクライアントの公開証明書を中間の証明書としてチェーンに入れるだけで、そのクライアントとして認証を通れました。公開証明書は秘密鍵と違い、秘密として守る前提の情報ではありません。

Canonicalのアドバイザリは、相互TLSのリモートAPI認証の処理が、クライアントが送ったすべての証明書を既知の信頼ストアの登録と照合していたと説明しています。署名の鍵の所有を証明するのは末端の証明書だけで、攻撃者は信頼された公開証明書を中間証明書としてチェーンに置くことで、別の身元としてLXDやMicroCloudのAPIに認証できたとしています。

HTTPSで使う証明書の役割と、証明書が証明する範囲は、次の記事で整理しています。

あわせて読みたい

HTTPSと電子証明書が守る範囲と、鍵マークが示さないこと

なりすました相手の権限がそのまま手に入る#

攻撃者が得る権限は、なりすました信頼済みクライアントの権限と同じです。LXDの公式ドキュメントは、トークンで追加したクライアントは制限を付けない限りLXDへの完全なアクセスを持つとしています。Canonicalは、被害を受けたクライアントの権限によっては、攻撃者がホストのroot権限を得る可能性があるとしています。

MicroCloudについてCanonicalは、クラスタに参加しようとしているメンバーの公開証明書を攻撃者が途中で入手し、そのメンバーとして認証できる可能性があるとしています。

深刻度と悪用の状況#

CISAのSSVCの評価は、悪用は確認されていないものの、攻撃を自動化でき、成功すれば対象を完全に支配できるという判断です。JPCERT/CCとIPAの注意喚起は、執筆時点では確認できませんでした。CVEレコードは参照先としてGitHubのアドバイザリ(GHSA-99jp-jwmc-65p4)も挙げていますが、執筆時点ではアクセスすると404で、内容を確認できませんでした。

Canonicalによると、この脆弱性は派生プロジェクトのIncusから知らされ、LXDにも影響することを確認したものです。CVEレコードには、報告者としてStéphane Graber氏の名前が記載されています。

影響を受ける構成#

LXDは既定では、ローカルの利用者がUnixソケット経由で使うだけで、ネットワークからは到達できません。公式ドキュメントによると、ネットワークに公開するにはcore.https_addressの設定で待ち受けるアドレスを指定します(例: ポート8443)。WebのUIを使う場合も、ネットワークへの公開が前提です。

そのため、影響を受けるのは主に次の構成です。

• core.https_addressを設定し、HTTPS APIをネットワークに公開しているLXD
• 複数台を束ねたLXDのクラスタ
• MicroCloudで構築した環境

Ubuntuのセキュリティ情報では、Ubuntuのdebパッケージとして配布されていた古い版のlxdは影響なしとされています。現在のLXDは主にsnapで配布されており、snapで入れたLXDの版を確かめる必要があります。

修正版と更新の方法#

Canonicalのアドバイザリが示す修正版は、次のとおりです。いずれも2026年10月29日に各チャネルで公開されました。

CVEレコードの影響範囲は、4.0.14、5.0.10、5.21.8と、6.9から6.10.1より前の版として記載されており、列挙した範囲の外は影響なし(defaultStatusがunaffected)とされています。一方でCanonicalのアドバイザリは、LXDとMicroCloudのすべての利用者に、それぞれのチャネルの最新版へ直ちに更新するよう求めています。影響範囲に入るかどうかにかかわらず、使っているチャネルの最新版へ更新します。

Canonicalは、snap refresh lxdとsnap refresh microcloudで更新するよう案内しています。アドバイザリの公開時点では、各版は候補版のチャネルから安定版のチャネルへ段階的に配信中とされていました。snapの自動更新に任せている場合も、更新を保留している環境や配信が届いていない環境では古い版のままのことがあるため、snap list lxdなどで実際の版を確かめます。クラスタでは、すべてのメンバーを修正版にそろえます。

更新できない間の暫定策#

暫定策は修正ではありません。修正版へ更新するまでの間、露出を減らすために使います。

管理用のAPIを利用者のネットワークから切り離す設計は、次の記事で整理しています。

あわせて読みたい

ネットワークセグメンテーションで侵入後の被害を広げない設計

侵害されていないかを点検する#

この脆弱性では、攻撃者は正規のクライアントとして認証されるため、LXDの記録では正規の利用者の操作と見分けにくくなります。HTTPS APIを公開していた環境では、次の点を確認します。

• 心当たりのないインスタンスの作成や、設定、デバイス、プロファイルの変更がないか
• 信頼ストアに、身に覚えのない証明書が追加されていないか
• 前段のファイアウォールやプロキシの記録で、想定外の接続元からHTTPS APIへの接続がないか
• ホストに、心当たりのないプロセスやアカウント、外部への通信がないか

不審な痕跡があれば、ホストを隔離して証拠を保全し、インシデント対応に切り替えます。管理下のコンテナや仮想マシンも、改ざんされている可能性を前提に調べます。

点検の過程で脆弱性の有無を自ら確かめる場合は、自組織が管理し、許可を得た環境に限って行います。他者のサーバーに無断で認証を試みる行為は、不正アクセス禁止法などの関連法令に触れるおそれがあります。

確認チェックリスト#

対応の抜けを防ぐための確認項目を整理します。

同じ週には、Linuxカーネルにも、TCPの接続を受け付けるサーバーに遠隔から届く脆弱性が公表されています。LXDのホストはカーネルもあわせて更新します。

あわせて読みたい

Linuxカーネルの脆弱性CVE-2026-98432とは、IPv4のTCP接続処理の解放後使用と修正版、MPTCPの確認

まとめ#

CVE-2026-112816は、LXDの相互TLS認証が、所有を証明できる末端の証明書だけでなく、チェーンに含まれるすべての証明書を信頼ストアと照合していた不備です。信頼済みクライアントの公開証明書さえあれば、そのクライアントになりすませるため、HTTPS APIを公開している環境では影響が大きくなります。

優先するのは、使っているチャネルの修正版へ更新し、実際の版を確かめることです。更新までの間はHTTPS APIへの接続元を絞り、信頼ストアを棚卸しします。悪用の状況やKEVへの登録は今後変わる可能性があるため、Canonicalの公式情報を引き続き確認します。