LXDとIncusのmTLS認証バイパス（CVE-2026-112816）

TL;DR

• Canonical LXD、MicroCloud、IncusのHTTPS APIに存在する欠陥により、ネットワーク上の攻撃者は対象クライアントの秘密鍵なしに、任意の信頼済みクライアントとして認証できます。Incusプロジェクトが報告し、CanonicalがLXDとMicroCloudへの影響を確認しました。Canonicalは2026年10月28日に勧告を公開しました。
• 影響を受ける未修正のデーモンは、攻撃者がHTTPS APIに到達し、信頼済みIDの公開証明書を得られる場合に露出します。IncusはTLS接続でサーバー証明書を提示します。MicroCloudの勧告は、参加するメンバーの証明書の傍受を説明しています。認証も権限もユーザー操作も不要です。
• CanonicalのCVEレコードはCritical、CVSS v4.0 10.0と評価しています。2026年11月1日時点で悪用は確認されておらず、CISAのKEVカタログにも載っていません。引用した勧告には公開PoCへのリンクはありません。
• sudo snap refresh lxdとsudo snap refresh microcloudでLXDとMicroCloudを更新し、Incusは7.6.0に上げてください。HTTPSリスナーへのネットワークアクセスの制限は暫定策にすぎず、修正ではありません。

影響を受けますか？

以下の条件がすべて成立した場合に影響を受けます。

• 以下の該当範囲のデーモン（LXD、MicroCloud、Incus）が稼働している。
• HTTPS APIが攻撃者の到達できるネットワークアドレスでリスニングしている。単独のLXDデーモンはデフォルトでローカルのUnixソケットのみを提供し、ネットワークリスナーはアドレスを設定したときだけバインドします（エンドポイントのソースコードによる）。クラスターとリモートクライアントにはネットワークAPIが必要です。
• 攻撃者が信頼済みIDの公開鍵証明書を取得できる。サーバー証明書は毎回のTLSハンドシェイクで返されるため、最も直接的な攻撃経路には事前アクセスが一切不要です。

Incusの勧告は、この欠陥のあるパターンが初回リリースから存在していたと述べています。つまり、7.6.0より前のIncusインストールはすべて影響を受けます。

CanonicalはLXDとMicroCloudをsnapとして配布しています。Ubuntuアーカイブに影響を受けるLXDパッケージはなく、Ubuntuのトラッカーはこの問題をMediumと評価しています。上記の修正バージョンはCanonical勧告によるsnapバージョンです。

稼働中のバージョンとネットワークAPIの状態を確認してください。

snap list lxd
lxc version
lxc config get core.https_address
lxc config get cluster.https_address
snap list microcloud

APIとクラスターの両方のリスナーアドレスを確認してください。APIアドレスが空でも、クラスターのリスナーがないとは限りません。Incusも同じ設定キーを使います。

incus version
incus config get core.https_address
incus config get cluster.https_address

修正するには？

各LXDおよびMicroCloudデーモンをそのチャンネルの修正バージョンに更新し、Incusを7.6.0に上げてください。

1. snapを更新します：sudo snap refresh lxdとsudo snap refresh microcloud。
2. デーモンが実際に修正版を実行していることを確認します：snap list lxdとlxc version。Canonicalは、勧告の公開時点でLXDの各ポイントリリースがcandidateからstableへ段階的に展開中だったと述べているため、更新後に再確認してください。
3. Incusをそのパッケージチャンネルで7.6.0に更新します。リリース告知によれば、このリリースは他の17件のセキュリティ問題も修正しています。

設定による回避策はありません。更新が届くまでの暫定策は、HTTPSリスナーへのネットワークアクセスを信頼できるホストに限定することで、Incusの勧告が推奨しています。その限界は明確です。欠陥はデーモンに残ったまま、リスナーへの信頼できない経路が1つでもあれば攻撃可能なままです。

根本原因は何ですか？

信頼の検証処理は、クライアントが送信したすべての証明書を信頼ストアと照合していました。TLSハンドシェイクが証明するのは、クライアントがチェーンの最初の証明書の秘密鍵を保持していることだけです。チェーンの残りはクライアントが自由に選べます。LXDとIncusのHTTPSリスナーはGoのtls.RequestClientCertでクライアント証明書を要求しますが、これはチェーンを検証せずに要求します。

Incusデーモンには、バージョン7.6.0より前のcmd/incusd/daemon.goのAuthenticateに、この欠陥の最も明確な形がありました。

    // Allow internal cluster traffic by checking against the trusted certficates.
    if r.TLS != nil {
        for _, i := range r.TLS.PeerCertificates {
            trusted, fingerprint := localUtil.CheckTrustState(*i, trustedCerts[certificate.TypeServer], d.endpoints.NetworkCert(), false)
            if trusted {
                return true, fingerprint, "cluster", nil, nil
            }
        }
    }

r.TLS.PeerCertificatesをループする同じ構造が、通常のクライアント証明書でもメトリクス証明書でも実行されていました。ここでiは提示された各証明書です。r.TLS.PeerCertificatesは、クライアントが任意の順序で渡したすべての証明書です。CheckTrustStateは1つの証明書を信頼ストアのエントリと比較するため、このループはクライアントが組み立てたチェーンを候補IDのリストに変えてしまいます。

信頼済みIDの公開鍵証明書を余分なチェーン要素として追加すれば、攻撃者はそのIDとして認証されます。リーフ証明書が証明するのは攻撃者が誰かであり、追加された証明書が決めるのはサーバーが誰だと信じるかです。

どのように悪用されますか？

攻撃に必要なのはTLS接続1回と公開鍵証明書1枚です。

1. 攻撃者は信頼済みIDの公開鍵証明書を入手します。サーバー証明書はデーモンとの任意のTLSハンドシェイクから取り出せるため、事前アクセスは不要です。クライアント証明書は、信頼済みクライアントなら誰でもcertificates APIから読めますし、そのクライアントが接続した任意のサーバーからも収集できます。
2. 攻撃者は自分の証明書と秘密鍵でHTTPS APIに接続し、取得した公開鍵証明書を提示するチェーンに追加します。
3. ハンドシェイクは成功します。リスナーはチェーンを要求するだけで、リーフの鍵より先は何も検証しないためです。
4. 信頼のループが提示されたチェーンを走査し、追加された証明書を信頼ストアのエントリと照合して、攻撃者をそのIDとして認証します。

なりすましはセルフサービスの証明書経路にも働きます。勧告は、クライアントが信頼ストアの任意のエントリを更新または削除できたと述べています。また、未検証のチェーンが認可スクリプトレットに渡され、攻撃者が選んだ証明書をスクリプトレットの認可判断に差し込めたとも述べています。引用した勧告には公開PoCへのリンクはありません。これらに必要なのはネットワーク到達性だけです。

攻撃の流れはどうなりますか？

HTTPSリスナーへの接続1回と、チェーンに置かれた信頼済みIDの公開鍵証明書1枚で、そのIDになりすませます。

攻撃者に何ができますか？

攻撃者は、なりすましたIDにできることをすべて引き継ぎます。

• CVEレコードが述べるように、クラスターとその管理下の仮想マシンへの完全なアクセス。Canonicalは、なりすまされたユーザーが特権を持つ場合、攻撃者がホストマシンのroot権限を得る可能性があると述べています。
• Incusの勧告が述べるように、サーバー自身の証明書を提示すればデータベースゲートウェイにアクセスでき、クラスターメンバーの証明書を提示すれば内部クラスターアクセスを得られます。クラスターメンバーになりすますと、認可全体が迂回されます。
• セルフサービス経路による信頼ストアエントリの更新と削除。同じ欠陥が認可スクリプトレットにも影響するため、クライアントはスクリプトレットの認可判断に影響を与えられます。これはトークンやOpenID Connectのクライアントにも当てはまり、ハンドシェイク中に任意の証明書を提示できます。
• ホストと仮想マシンの間のエージェント接続の認証。ここにも同じ欠陥があります。

MicroCloudでは、Canonicalは、クラスターメンバーの参加時にその公開TLS証明書を傍受できる攻撃者が、後でそのメンバーとして認証できると警告しています。条件は同じで、APIへのネットワーク到達性と公開鍵証明書のみであり、権限もユーザー操作も不要です。

修正はなぜ機能しますか？

公開されている基準となる修正は、Stéphane Graberが2026年10月13日に作成したIncusコミット8381e54c3631c627d7ecdec03945bca14d0bd542「Only trust the key-proven client certificate」です。

+   // The TLS listener only proves possession of the first peer certificate's key, so the rest of
+   // the presented chain is attacker-controlled and must never be matched against the trust store.
+   var peerCert *x509.Certificate
+   if r.TLS != nil && len(r.TLS.PeerCertificates) > 0 {
+       peerCert = r.TLS.PeerCertificates[0]
+   }

これにより信頼の検証はpeerCertのみに対して実行され、r.TLS.PeerCertificatesをループするすべての箇所が置き換えられます。

-   if r.TLS != nil {
-       for _, i := range r.TLS.PeerCertificates {
-           trusted, fingerprint := localUtil.CheckTrustState(*i, trustedCerts[certificate.TypeServer], d.endpoints.NetworkCert(), false)
-           if trusted {
-               return true, fingerprint, "cluster", nil, nil
-           }
-       }
-   }
+   if peerCert != nil {
+       trusted, fingerprint := localUtil.CheckTrustState(*peerCert, trustedCerts[certificate.TypeServer], d.endpoints.NetworkCert(), false)
+       if trusted {
+           return true, fingerprint, "cluster", nil, nil
+       }
+   }

追加された証明書は何とも照合できなくなります。参照されるのは、ハンドシェイクが実際に検証したリーフだけだからです。コミットは、勧告が列挙するすべての信頼経路に同じ規則を適用します。API認証、証明書の登録とセルフサービスの更新・削除、ホストとVMのエージェント接続の両側、認可スクリプトレット、そしてクラスタートラフィックをカバーしています。

LXDとMicroCloudについては、Canonicalの勧告が同じ修正を説明しており、「影響を受けますか？」に列挙した修正版がそれを組み込んでいます。

侵害されたかどうかを確認するには？

ベンダーの勧告には侵害指標は公開されていません。信頼ストアが変更されていなくても、攻撃者は既存の信頼済みIDを使えるため、なりすましを否定できません。

まず信頼ストアとクラスターのメンバー一覧に不審なエントリがないか調べてください。

lxc config trust list

lxc cluster list

信頼ストアの各エントリを確認し、説明のつかない名前、種別、プロジェクト設定がないか調べてください。セルフサービスの更新経路はこの欠陥の一部であるため、更新されたエントリには特に注意が必要です。特権IDがなりすまされた可能性のあるホストは、侵害されたものとして扱ってください。秘密鍵を含め、そのホストからアクセスできるすべての認証情報を評価し、侵害時に露出した可能性があるものを更新してください。インシデント対応手順に従ってホストを再構築してください。

時系列

Incusの修正コミットはCVE公開の17日前に作成されました。作成日時だけでは、そのコミットが公開された日時はわかりません。

• 2023-07-22: IncusのリポジトリがLXDのフォークとして作成されます。Incusの勧告は、この欠陥のあるパターンが初回リリースから存在していたと述べています。
• 2026-10-13: Stéphane GraberがIncusの修正コミット8381e54c3631c627d7ecdec03945bca14d0bd542を作成します。
• 2026-10-19: CanonicalがCVE-2026-112816を予約します。
• 2026-10-21: CanonicalがLXD 6.10.1を発表します。6.xブランチで最初の修正リリースです。
• 2026-10-28: CanonicalがLXDとMicroCloudの修正snapバージョンを記載したセキュリティ勧告を公開します。
• 2026-10-29: IncusがGHSA-xg75-xf37-cph9を公開します。LXDとMicroCloudの修正snapリリースは2026年10月29日付です。
• 2026-10-30: CVEレコードが公開され、Incus 7.6.0がリリースされます。CISAのADPは2026年10月30日付で悪用は確認されていないと記録しています。

FAQ

なぜTLSハンドシェイクはチェーン全体を証明しないのですか？

リスナーはGoのtls.RequestClientCertでクライアント証明書を要求しますが、これはチェーンを要求するだけで検証しません。ハンドシェイクが証明するのは、クライアントがチェーンの最初の証明書の秘密鍵を保持していることだけです。それ以降の証明書は、クライアントが付け加えたデータにすぎません。

デフォルト設定の単独LXDインストールは影響を受けますか？

いいえ。単独のデーモンはローカルのUnixソケットを提供し、管理者がネットワークアドレスを設定したときだけHTTPSリスナーをバインドします。したがってデフォルトのインストールはネットワークから到達できません。クラスターとリモートのlxcクライアントにはこのネットワークAPIが必要です。

修正後に証明書をローテーションする必要はありますか？

公開証明書の開示だけなら更新は不要です。証明書は秘密情報ではなく、パッチが認証バイパスを防ぎます。攻撃者がホストにアクセスした場合は、秘密鍵や他の認証情報の露出を別途評価し、侵害された認証情報を更新するとともに、信頼ストアの不正な変更を確認してください。

LXDとIncusの欠陥は同じバグですか？

両者は共通の系譜を持つ2つのコードベースで、同じメカニズムを共有しています。LXDとIncusのどちらも作ったStéphane Graberが報告し、Incusは7.6.0で修正し、Canonicalは上記のリリースでLXDとMicroCloudを修正しました。Canonicalの勧告はLXDとMicroCloudを対象とし、Incusの勧告はCVE IDなしで公開されています。

実際に悪用されていますか？

悪用は確認されていません。CISAのADPは2026年10月30日付で悪用を「なし」と評価しており、2026年11月1日時点でこの欠陥はCISAのKEVカタログに載っていません。引用した勧告には公開PoCへのリンクはありません。

Ostorlabで露出したLXDとIncusのホストを見つける

Ostorlabのアタックサーフェスディスカバリーはインターネットに露出したホストをインベントリ化します。どのLXD、Incus、MicroCloudのデーモンがHTTPS APIを公開しているかを把握し、それらから修正できます。

参考文献

• CVE-2026-112816レコード、Canonical CNA、CVSS v4.0 10.0： https://www.cve.org/CVERecord?id=CVE-2026-112816 （2026年11月1日確認）
• 修正snapバージョンを記載したCanonicalのセキュリティ勧告： https://discourse.ubuntu.com/t/security-advisory-critical-vulnerability-found-in-canonical-lxd-and-microcloud/90557 （2026年10月28日公開、2026年11月1日確認）
• Incus勧告GHSA-xg75-xf37-cph9、CVSS v3.1 10.0： https://github.com/lxc/incus/security/advisories/GHSA-xg75-xf37-cph9 （2026年10月29日公開、2026年11月1日確認）
• Incusの修正コミット「Only trust the key-proven client certificate」： https://github.com/lxc/incus/commit/8381e54c3631c627d7ecdec03945bca14d0bd542 （2026年10月13日作成、2026年11月1日確認）
• LXD 6.10.1リリース告知： https://discourse.ubuntu.com/t/lxd-6-10-1-lts-has-been-released/90024 （2026年10月21日公開、2026年11月1日確認）
• Incus 7.6リリース告知、18件のセキュリティ修正： https://discuss.linuxcontainers.org/t/incus-7-6-has-been-released/27462 （2026年10月30日公開、2026年11月1日確認）
• CVE-2026-112816のUbuntuトラッカーページ、アーカイブパッケージの状態とMedium優先度： https://ubuntu.com/security/CVE-2026-112816 （2026年11月1日確認）
• LXDのエンドポイントソース、デフォルトのローカルUnixソケットと設定済みHTTPSリスナー： https://github.com/canonical/lxd/blob/lxd-6.10.1/lxd/endpoints/endpoints.go （2026年11月1日確認）
• CISAのKEVカタログ、CVE-2026-112816について確認したフィード： https://www.cisa.gov/known-exploited-vulnerabilities-catalog （2026年11月1日確認）
• The Hacker News、「CVSS 10.0 LXD, MicroCloud Flaw Lets Attackers Impersonate Trusted Clients Without a Private Key」： https://thehackernews.com/2026/11/critical-lxd-and-microcloud-flaw-cvss.html （2026年11月1日公開、2026年11月1日確認）