CVE-2026-112816: クリティカルなLXDおよびMicroCloud認証バイパスがクラスター乗っ取りを可能に

Canonicalは、LXDおよびMicroCloudに影響を与える重大な認証バイパスの脆弱性CVE-2026-112816に対応するセキュリティ更新を発表しました。この欠陥は最大CVSSスコア10.0を持ち、認証されていないリモート攻撃者が、TLSクライアントの私有鍵を持たずに信頼されたTLSクライアントを偽装することを可能にします。

この脆弱性を成功裏に悪用されると、LXDまたはMicroCloud APIへのアクセス権を、偽装されたアイデンティティに割り当てられた特権で提供します。信頼されたアイデンティティに十分な権限がある場合、攻撃者はクラスター、管理された仮想マシン、および基盤となるホストへのrootレベルのアクセスを得る可能性があります。

この脆弱性は、相互TLS認証に使用されるクライアント証明書チェーンの不適切な検証に起因しています。対応する私有鍵を所持しているクライアントに対してのみリーフ証明書を認証する代わりに、脆弱性のある実装はクライアントが制御するチェーン内のすべての証明書を信頼された証明書と比較します。

そのため、HTTPS APIに到達しすでに信頼されたクライアントの公開証明書を入手できる攻撃者は、その証明書を攻撃者が制御するリーフ証明書と連結し、信頼されたアイデンティティとして受け入れられる可能性があります。

2026年10月後半にCanonicalは、Incusプロジェクトの指摘によりこの問題を開示しました。修正されたLXDおよびMicroCloudのリリースが利用可能であり、管理者は直ちにアップデートすることを強く推奨します。

LXDがシステムコンテナや仮想マシンを管理し、MicroCloudがクラスター化されたインフラを調整するため、この欠陥は特にインフラ環境で重大です。管理上のアイデンティティの侵害は、単一のサービスを超えて影響を及ぼし、ワークロードやホスト自身を制御する可能性があります。

CVE-2026-112816の検出において、セキュリティチームは、インターネットまたはネットワークからアクセス可能なLXDおよびMicroCloudのHTTPS APIを特定し、信頼されたクライアント証明書を確認し、予期しないソースシステムや異常な管理操作と成功した証明書ベースの認証を相関させることを優先すべきです。

SOC PrimeのAI-Native Detection Intelligence Platformは、ネットワーク、Linux、クラウド、コンテナ、およびアイデンティティのテレメトリー全体での悪用や侵害後の行動に対するカバレッジを強化するためにセキュリティチームを支援します。

営業へのお問い合わせ

関連する検出コンテンツとハンティングロジックにアクセスするには、Click Explore Detectionsをクリックしてください。CVE-2026-112816を検出するために、防御者は脆弱なバージョンのインベントリをAPIアクセス監視、証明書認証テレメトリー、およびコンテナ、仮想マシン、またはクラスター構成に影響を与える疑わしい管理活動と組み合わせるべきです。

CVE-2026-112816分析

CVE-2026-112816は、Canonical LXDおよびMicroCloudで使用されるHTTPSリスナーにおける不適切な証明書検証の脆弱性です。

両製品は、相互TLSを使用してリモートクライアントを認証できます。通常のmTLSの動作では、接続してくるクライアントは証明書を提示し、TLSチェーンのリーフとして使用される証明書に関連付けられた私有鍵の所有を証明します。

問題は、脆弱なLXDおよびMicroCloudの実装が認証されたリーフ証明書以上のものを検査しているために発生します。

Canonicalによれば、リモートAPI認証ロジックはクライアントによって提示されたすべての証明書を信頼された証明書ストアのエントリーと比較していました。しかし、TLSはリーフ証明書のみについて私有鍵の所有を証明します。提示されたチェーン内の追加の証明書は、クライアントによって提供され、対応する私有鍵の所有を独立して証明しません。

これにより、認証のギャップが生じます。

攻撃者は自身が制御する証明書と私有鍵を生成して、その証明書をリーフとして使用し、信頼されたクライアントの公開証明書を提示されたチェーンの他の部分に追加できます。脆弱なサーバーは信頼された証明書を見つけて、攻撃者が私有鍵を持たなくても、その信頼されたアイデンティティに関連付けるかもしれません。

したがって、CVE-2026-112816の詳細は、悪用が主に2つの前提条件に依存することを示しています：

• 攻撃者がLXDまたはMicroCloudのHTTPS APIに到達できる。
• 攻撃者が、ターゲットによってすでに信頼されているアイデンティティの公開証明書を所有している。

信頼されたクライアントの私有鍵は必要ありません。

この違いが脆弱性の重大な深刻度を説明します。証明書ベースの認証は秘密の私有鍵の所有を示すことが期待されますが、影響を受けるロジックは公共証明書の所有のみで信任の決定の一部を満たすことが事実上可能です。

スタンドアロンのLXDインストレーションはデフォルトでそのリモートHTTPS APIを公開しません。Hacker Newsによれば、LXDは通常そのローカルのUnixソケットのみをリッスンし、管理者が例えばcore.https_addressの設定を通じてネットワークアクセスを有効にしない限りは公開しません。

これにより、すべての脆弱なLXDインストレーションが他のホストからリモートで悪用可能なわけではないことを意味します。

APIが管理ネットワークを介して有効化されるか、インターネットに公開されると、露出は大幅に増加します。

MicroCloudは、もう一つの関連する攻撃シナリオを提示します。Canonicalによれば、MicroCloudクラスターに参加するマシンの公開TLS証明書を傍受できる攻撃者は、その参加メンバーとしてその後に認証することが可能です。

CVE-2026-112816は、修正された対応リリース前の4.0.14、5.0.10、5.21.8、6.9を含む脆弱なCanonical LXDリリースに影響を与えます。

Canonicalは、これらの修正されたLXDバージョンをリストしています：

• LXD 6.10.1（6/stableチャンネル用）
• LXD 5.21.9（5.21/stable用）
• LXD 5.0.11（5.0/stable用）
• LXD 4.0.15（4.0/stable用）

MicroCloudについて、修正されたバージョンは：

• MicroCloud 3.4.1（3/stable用）
• MicroCloud 2.1.5（2/stable用）

UbuntuのCVEレコードは、巧妙な証明書チェーンを介して認証されていない攻撃者が信頼されたクライアントとして認証され、クラスターおよび管理された仮想マシンへの完全なアクセス権を得ることを可能にする成功した悪用を説明しています。

10.0の最大CVSSスコアは、ネットワークアクセスの可能性、低い攻撃の複雑さ、必要な特権の不存在、ユーザーの介入が不要であること、および機密性、完全性、可用性への潜在的に高い影響を反映しています。

最終的な影響は、偽装されているアイデンティティの特権に依存します。

制限されたアイデンティティは、限られたAPI機能を提供するかもしれません。高い特権を持つクライアントまたはクラスターアイデンティティは、実質的に大きなアクセス権を提供できます。

Canonicalは、特権を持つ信頼されたユーザーの偽装がホストマシンへのrootアクセスをもたらす可能性があると明示的に警告しています。

それにより、攻撃者が潜在的に可能なこと：

• コンテナおよび仮想マシンを管理または変更する。
• 侵害されたLXD環境を通じて管理されるワークロードにアクセスする。
• インフラストラクチャ構成を変更する。
• 新しいワークロードを作成したり、既存のものを変更したりする。
• 可用性に影響を与える。
• 偽装されたアイデンティティに利用可能なデータにアクセスする。
• 十分な権限がある場合、rootレベルの特権でホストにアクセスする。

欠陥は関連するIncusプロジェクトで最初に特定され、次にCanonicalに送信され、LXDにも同じ証明書チェーン認証の問題が影響を与えていることが確認されました。

Incusは基礎となる問題を同様に説明しています：サーバーは、提出されたチェーン全体を検証することなくクライアント証明書を要求し、信頼チェックは実際のリーフ証明書への認証を制限するのではなく、すべての提供されたピア証明書に繰り返し適用されました。Incusは、バージョン7.6.0でこの問題に対処しました。

この脆弱性は長期間存在していたようです。Incusは、同等の認証ロジックがリリースされて以来存在していたと示しています。Canonicalの公開アドバイザリーは、脆弱なLXDの動作が初めて導入された正確な日付を提供していません。

2026年11月2日時点で、独立したCVE-2026-112816 PoCおよびラボの再現が公開されています。これは、2026年11月1日に発表されたHacker Newsの報告からの変化を示しています。この公開された再現は開示後に登場し、最初の脆弱性研究ではありません。

Canonicalおよび参照された報告は、現実の攻撃でこの脆弱性が悪用されていることを示していません。

Hacker Newsは、2026年10月30日に米国CISAの評価で問題が悪用されているとは知られていなかったと報告しており、その時点でCISAの「既知の脆弱性」カタログに含まれていませんでした。

したがって、CVE-2026-112816の特定のキャンペーン固有のIOC（確認された悪意のあるIPアドレス、ドメイン、マルウェアハッシュ、または悪用に関連する特定の攻撃者インフラストラクチャ）はありません。

代わりに、防御者は、脆弱性の露出と行動に重点を置くべきです。

潜在的なハンティングの機会には以下が含まれます：

• 予期しないシステムからのLXDまたはMicroCloud HTTPS APIへのリモート接続。
• 通常、信頼された管理者によって使用されないネットワークから発信された成功したAPI認証。
• 複数の無関係なソースシステムから現れる信頼された証明書ID。
• 証明書の予想所有者と一致しない管理API活動。
• コンテナおよび仮想マシンの予期しない作成、削除、または変更。
• 信頼された証明書エントリの変更。
• 新しいまたは変更されたクラスター メンバー。
• ストレージ、ネットワーキング、プロファイル、プロジェクト、インスタンス構成への予期しない変更。
• 異常な証明書ベースの認証の直後に発生する特権操作。
• リモートからアクセスすることを意図していなかった管理インタフェースへのAPI接続。

組織はまた、以前の管理者、廃止されたホスト、自動化システム、およびクラスター メンバーと関連付けられた信頼された証明書の在庫を把握する必要があります。

悪用は公開証明書を要求し、私有鍵ではないため、防御者は秘密鍵の機密性だけでこの特定の脆弱性に対する十分な保護とはみなさないでください。

監視はまた、共有管理ネットワークを考慮に入れる必要があります。

公開インターネットに直接公開されていないAPIでも、管理インタフェースにアクセスできる別のシステムにすでに足場を築いている攻撃者によって悪用される可能性があります。

これは、ラテラルムーブメントが特に関連性が高いことを意味します。ネットワークにアクセス可能なLXD APIを持つ侵害されたワークステーション、サーバー、CI/CDランナー、管理ホスト、またはクラウドワークロードは、内部的に公開されたシステムを悪用するために必要な位置を提供できるかもしれません。

CVE-2026-112816 の軽減

Canonicalは、影響を受けたLXDおよびMicroCloud展開を修正済みの最新バージョンにただちにアップグレードすることを推奨しています。

Snapベースの展開の場合、管理者は次のコマンドを使用して更新できます：

sudo snap refresh lxd

そして：

sudo snap refresh microcloud

リフレッシュ後は、更新が正常に適用されたことを前提とするのではなく、実際にインストールされているバージョンを確認してください。

開示の際に、Canonicalは、いくつかのLXDポイントリリースが候補から安定チャンネルに進行中であると説明しました。したがって、管理者はシステムが修正済みのバージョンの1つで実行されていることを明示的に確認する必要があります。

CVE-2026-112816の主要な軽減策はアップグレードです：

製品	修正バージョン
LXD 6.x	6.10.1
LXD 5.21	5.21.9
LXD 5.0	5.0.11
LXD 4.0	4.0.15
MicroCloud 3.x	3.4.1
MicroCloud 2.x	2.1.5

Canonicalは、基盤となる認証の欠陥を完全に排除する構成ベースの回避策を公開していません。

即時のアップグレードが不可能な場合、HTTPS APIへのネットワークアクセスをできる限り運用要求に合わせて制限します。

承認された管理ホストおよび信頼されたインフラストラクチャのみがリスナーへの接続を確立できるようにすべきです。

リモート管理を必要としないLXDインストールの場合、管理者はネットワークAPIが有効になったままでいる必要があるかどうかを評価すべきです。

リモートアクセスを必要とする環境には：

• ホストまたはネットワークファイアウォールを使用してAPIを制限します。
• 専用の管理ネットワークからのみ接続を許可します。
• APIを直接公開インターネットに公開することを避けます。
• 適切な場合はVPNまたはバスチオンベースの管理アクセスを使用します。
• コンテナおよび仮想化管理インフラをユーザーネットワークから分離します。
• すべての成功した管理APIリクエストを監視します。
• 信頼された証明書をレビューし、不必要なエントリーを削除します。

これらの制御は露出を減少させますが、脆弱な証明書検証ロジックを修正しません。

MicroCloudを実行している組織は、すべての関連するクラスター メンバーを更新し、予期しないシステムまたは証明書IDのために最近の参加活動をレビューすることを優先すべきです。

管理者はまた、信頼された証明書ストアを見直すべきです。

廃止されたホスト、以前の管理者、使用されていない自動化システム、またはアクセスがもはや必要でないアイデンティティに属する証明書を削除します。

疑わしい活動が発見された場合、資格情報を回転させる前に影響を受けたホストおよびクラスターを調査し、証拠を変更します。

関連するテレメトリーソースに含まれるかもしれないものには以下が含まれます：

• LXDおよびMicroCloudサービスログ
• Linuxシステムログ
• ファイアウォールおよびネットワークフローレコード
• 適用される場合、リバースプロキシのテレメトリー
• ホストEDRデータ
• クラウドネットワークログ
• クラスターの構成およびメンバーシップ履歴
• 管理変更記録

予期しないインスタンスの作成、変更、削除、スナップショット活動、ストレージ操作、ネットワークの変更、および構成の更新を探します。

恐れている悪用が疑われ、特権を持つ証明書IDが偽装された場合、防御者はCanonicalが特権が十分であればrootアクセスが可能である可能性を認めているため、潜在的なホストレベルの侵害を真剣に取り扱うべきです。

インシデントレスポンダーは、関連する証拠を保存し、持続性、無許可のアカウントや証明書、変更されたサービス、新しいワークロード、疑わしいプロセス、および異常なアウトバウンドネットワーク通信についてシステムを検査する必要があります。

Canonical LXDの代わりにIncusを使用している組織は、関連するサポート済みの修正リリースまたはIncus 7.6.0に個別に更新する必要があります。ただし、関連プロジェクトは同じ基礎となる証明書チェーンの信頼問題の影響を受けました。

Ubuntuも、現在リストされているUbuntuリリースのアーカイブパッケージ化されたLXDバージョンが、影響を受けるパッケージパスを通じて出荷されていないか、影響を受けていないことを指摘していますが、CanonicalのセキュリティガイダンスはSnapリリースに焦点を当てています。管理者は、環境で実際に実行されているLXDの配布およびバージョンを確認する必要があります。

免責事項： すべてのCVEに対して、検出コンテンツが利用可能ではないかもしれません。SOC Prime Platformで現在のカバレッジを確認してください。関連する検出がまだ利用可能でない場合は、新しい脅威インテリジェンスや検出コンテンツが継続的に追加されているため、再度確認してください。