CVE-2026-112816とは - LXDのHTTPS APIで信頼済みのクライアントになりすませる認証回避と、MicroCloud・Incusの対応

CVE-2026-112816は、Canonicalのコンテナと仮想マシンの管理ツールLXDで見つかった、認証回避の脆弱性です。LXDのHTTPS APIは、クライアント証明書（相互TLS）で相手を認証します。ところが、クライアントが送ってきた証明書のチェーンを最後まで信頼ストアと照らし合わせていたため、攻撃者は「信頼されている誰かの公開証明書」をチェーンに混ぜるだけで、その人として認証されてしまいました。

CanonicalはCVSS 4.0で10.0（Critical）と評価しています。2026年10月28日（UTC）にCanonicalが告知を出し、LXDのsnapの各チャンネルとMicroCloudに修正版が出ています。同じ処理を持つIncus（LXDから分かれたプロジェクト）でも見つかり、Incusの開発者が報告しました。この記事では、CVEの記録、Canonicalの告知、Incusのアドバイザリと修正コミットをもとに、仕組みと対応を整理します（2026年11月2日時点）。

まず結論 - やること

• LXDのHTTPS API（core.https_address）をネットワークに公開しているサーバーと、LXDのクラスタ、MicroCloudが対象です。既定のLXDはローカルのUnixソケットだけで待ち受けるので、HTTPS APIを公開していなければ外からは届きません。
• sudo snap refresh lxd（MicroCloudはsudo snap refresh microcloud）で修正版に更新します。修正版は、LXDが6.10.1、5.21.9、5.0.11、4.0.15、MicroCloudが3.4.1、2.1.5です。
• すぐに更新できない場合は、HTTPS APIのポートに届く相手をファイアウォールで信頼できるホストだけに絞ります。HTTPS APIを使っていないなら、公開をやめます。
• Incusは7.6.0で直っています。DebianのLXDのパッケージ（lxd 5.0.2系）は、11月2日時点で修正前です。

CVE-2026-112816の概要

CISAがCVEの記録に付けた評価（SSVC）は、10月30日時点で「悪用: なし」「自動化できる: はい」「技術的な影響: 全面的」です。NVDの状態は「Deferred」で、NVD自身の評価は付いていません。

タイムライン

日付はUTCです。

Canonicalの告知によると、この脆弱性はIncusのプロジェクトから知らされ、LXDにも当てはまることを確かめたものです。

脆弱性の仕組み

LXDの認証は相互TLS

LXDをネットワーク越しに操作するときは、クライアントが自分のTLS証明書をサーバーに示し、サーバーはその証明書が信頼ストア（trust store）に登録されているかで相手を見分けます（TLSのハンドシェイク）。クライアントの証明書は、トークンを使ってあらかじめ信頼ストアに登録しておきます。

TLSのハンドシェイクで「この証明書の持ち主である」と証明できるのは、チェーンの先頭の証明書（リーフ証明書）だけです。クライアントはリーフ証明書の秘密鍵で署名して、鍵を持っていることを示します。チェーンの2つ目以降の証明書は、ただの付け足しで、送り主が中身を自由に選べます（公開鍵暗号とデジタル署名）。

チェーンの全部を信頼ストアと照合していた

Incusのアドバイザリと修正コミットによると、問題は次の2つが重なったことです。

1. HTTPS APIは、クライアント証明書を「求める」だけで、TLSの層では検証していませんでした（Goのtls.RequestClientCert）。これ自体は、自己署名の証明書を信頼ストアで認証するLXDの仕組みでは不自然ではありません。
2. そのうえで、認証の処理が、送られてきたチェーンの証明書を1つずつ信頼ストアと照らし合わせ、どれか1つでも一致すれば認証していました。

その結果、攻撃者は自分で作った証明書を先頭に置き、その後ろに「信頼されている誰かの公開証明書」を付け足すだけで、その人として認証されました。公開証明書は秘密ではないので、手に入れる方法はいくつもあります。

修正は、信頼ストアと照らし合わせる証明書を、鍵の所有が証明されたチェーンの先頭の1枚だけにするものです。Incusの修正コミットは、HTTPS APIの認証、証明書の更新や削除、クラスタの内部通信、仮想マシンのエージェントとの通信、認可のスクリプトレットの6か所を同じように直しています。

Canonicalの告知も、要約として「相互TLSの認証が、クライアントが送ったすべての証明書を信頼ストアと比べていた。鍵の所有を証明するのはリーフ証明書だけである」と説明しています。

危険度

LXDに管理者として登録されたクライアントは、コンテナや仮想マシンの作成、ホストのディレクトリのマウントなど、ホストに対して強い操作ができます。そのため、なりすましはホストの乗っ取りにつながりえます。

Incusは、サーバー自身の証明書でもなりすませると説明しています。この経路がLXDでも同じように成り立つかは、Canonicalの告知に書かれておらず、筆者は確認できていません（未確認）。いずれにしても、HTTPS APIに届く相手が信頼済みの誰かの公開証明書を手に入れられれば成り立つので、HTTPS APIを公開しているなら危険度は高いと考えます。

11月2日時点で、実際の攻撃や公開されたPoCの報告は見当たりません。

影響を受ける版と修正版

LXD（snap）

CVEの記録は、影響を受ける版を「4.0.14、5.0.10、5.21.8、6.9から、それぞれの修正版の前まで」と書いています。一方で、Incusは「最初のリリースからこうなっていた」と説明し、DebianはLXDの5.0.2のパッケージを影響ありと判定しています。このため、上の範囲より古い版も同じ問題を持っていると考えて、修正版へ更新するのが安全です（推測）。Canonicalの告知も、すべての利用者に更新を求めています。

Canonicalの告知の時点で、修正版は各チャンネルのcandidateからstableへ順番に配信している途中でした。

MicroCloud

Incus

Incusのアドバイザリ（GHSA-xg75-xf37-cph9）は、7.6.0より前を影響あり、7.6.0を修正版としています。IncusのLTS版やディストリビューションのIncusのパッケージがいつ直るかは、確認できていません（未確認）。

ディストリビューションのパッケージ

Ubuntuでは、LXDはsnapで配布されています。対応はsnapの更新です。

構成ごとの対応方法

snapで入れたLXD

sudo snap refresh lxd
snap list lxd

snap list lxdのVersionが、使っているチャンネルの修正版以上になっていれば完了です。snapは自動で更新されますが、更新を保留（snap refresh --hold）している場合や、配信がまだ届いていない場合があるので、手動で確かめます。

LXDのクラスタ

クラスタでは、すべてのメンバーでsnap refresh lxdを実行し、同じ修正版にそろえます。Incusのアドバイザリによると、クラスタのメンバーどうしの内部通信もこの問題の対象なので、一部のメンバーだけ更新した状態で止めないようにします。

MicroCloud

sudo snap refresh microcloud
sudo snap refresh lxd

Canonicalの告知が求めているのは、MicroCloudとLXDの両方の更新です。

Incus

Incusは7.6.0以上に更新します。ディストリビューションなどのパッケージで入れている場合は、配布元の更新を確かめます。

DebianのLXDのパッケージ

11月2日時点で修正版がありません。DebianのLXDのパッケージをHTTPS APIの公開に使っている場合は、次の緩和策で届く相手を絞ります。

すぐに更新できないときの緩和策

Incusのアドバイザリは、緩和策として「HTTPS APIに届く相手を信頼できるホストに限る」ことを挙げ、設定で避ける方法はないとしています。

HTTPS APIを公開しているか確かめる

lxc config get core.https_address
# クラスタの場合
lxc config get cluster.https_address
# 実際に待ち受けているポート（既定は8443）
sudo ss -ltnp | grep lxd

core.https_addressが空なら、LXDはネットワークで待ち受けていません。LXDのドキュメントにあるとおり、既定ではローカルのUnixソケットだけで使えます。

使っていないなら公開をやめる

lxc config unset core.https_address

LXDのWeb UIはHTTPS APIを使うので、公開をやめるとUIも使えなくなります。クラスタではメンバーどうしの通信にcluster.https_addressが必要なので、外さずにファイアウォールで絞ります。

ファイアウォールで届く相手を絞る

HTTPS APIのポート（既定は8443）に、管理に使うホストとクラスタのメンバーだけが届くようにします。ufwの例です（アドレスはドキュメント用の例）。

sudo ufw allow from 192.0.2.10 to any port 8443 proto tcp
sudo ufw deny 8443/tcp

ufwはルールを上から順に評価するので、許可のルールを先に入れます。クラウドのセキュリティグループで絞れる場合は、そちらでも同じ効果があります。

影響を受けるか・更新できたかを確かめる

# LXDの版とチャンネル
snap list lxd
snap info lxd | grep -E '^(tracking|installed)'
 
# HTTPS APIの公開
lxc config get core.https_address
 
# 信頼ストアに登録されている証明書（覚えのないものがないか）
lxc config trust list

更新の前にHTTPS APIを公開していた場合は、信頼ストアに覚えのない証明書が増えていないか、インスタンスや設定に覚えのない変更がないかも確かめます。この脆弱性では、なりすました相手として信頼ストアのエントリーを更新したり消したりもできたと、Incusのアドバイザリは説明しています。

まとめ

• CVE-2026-112816は、LXDのHTTPS APIで、クライアントが送った証明書のチェーンの全部を信頼ストアと照合していたため、信頼済みの誰かの公開証明書を付け足すだけでその人として認証できた脆弱性です。CVSS 4.0で10.0です。
• 鍵の所有を証明できるのはチェーンの先頭の証明書だけです。修正は、その1枚だけを照合するものです。
• LXDは6.10.1、5.21.9、5.0.11、4.0.15、MicroCloudは3.4.1、2.1.5、Incusは7.6.0で直っています。DebianのLXDのパッケージは修正前です。
• HTTPS APIを公開していないLXDは、外からは届きません。公開している場合は、更新までの間、届く相手をファイアウォールで絞ります。

コンテナの仕組みそのものは、Linuxコンテナの名前空間とcgroupsの記事で扱っています。TLSのクライアント証明書の検証の不備としては、Node.jsのTLSのホスト名検証の回避も記事にしています。

参考資料

• CVE-2026-112816（CVE.org）
• Security advisory: Critical vulnerability found in Canonical LXD and MicroCloud（Ubuntu Discourse）
• LXD 6.10.1 LTS has been released
• LXD 5.21.9 LTS has been released
• LXD 5.0.11 LTS has been released
• LXD 4.0.15 LTS has been released
• Incus - Authentication and authorization bypass through unverified client certificate chains（GHSA-xg75-xf37-cph9）
• Incusの修正コミット 8381e54c3631
• LXD - How to expose LXD to the network
• Debian Security Tracker - CVE-2026-112816
• Ubuntu - CVE-2026-112816
• NVD - CVE-2026-112816
• CISA Known Exploited Vulnerabilities Catalog