CVE-2026-112816とは？LXDのなりすまし問題とUbuntuでの確認・更新方法

Ubuntuのセキュリティ情報に、CVE-2026-112816という脆弱性が公開されている。対象は、コンテナや仮想マシンを管理するLXDの認証処理だ。

条件がそろうと、攻撃者が信頼済みの利用者になりすまして、管理機能へアクセスできてしまう。まず確かめたいのは、自分の管理する環境でLXD・MicroCloudを使っているかというところ。

この記事は2026年11月2日時点の公式情報に基づく解説。Ubuntuなどで動くCanonical LXD・MicroCloudを対象に、後半ではSnap版の確認・更新手順を紹介する。特定のサーバーで実施した作業記録ではない。

出典：UbuntuのCVE情報。

そもそもLXDって何？

LXDは、一つのマシンや複数台のサーバーで、Linuxのコンテナや仮想マシンを動かし、まとめて管理するソフトウェア。

例えば、開発用と検証用に別々のLinux環境を用意したいときに使える。環境を作ったり、起動・停止したりする操作を、コマンドや管理APIから行える。LXD公式の概要

先に、今回の話で使う言葉を整理しておく。

LXDの管理機能を奪われると、その上で動かしている環境にも影響が広がり得る。Webサイトの表示だけを扱う機能と比べても、与えられる権限の範囲を意識したいところだ。

証明書の確認で、何を間違えていた？

今回の問題は、管理用HTTPS APIで使うクライアント証明書による本人確認にある。MicroCloudにも同様の問題があると開発元が説明している。

証明書を使う認証では、次の二つを区別すると分かりやすい。

説明のために社員証で例えると、社員証を見せることに加えて、その持ち主本人かどうかまで確認する必要がある、という感じ。公開証明書を手に入れただけで、その人としてログインできてはいけない。

ところが、問題の認証処理は、クライアントから届いた証明書チェーン（複数の証明書の並び）全体を信頼済みの証明書と照合していた。秘密鍵の所持を確認した接続者の証明書と、信頼済みの身元を正しく結び付けられていなかった。

その結果、信頼済みの公開証明書を悪用し、その利用者の秘密鍵を持たずに本人として認証される可能性があった。通信が暗号化されていても、本人確認の処理に不備があれば、管理機能を守り切れないということになる。

出典：Canonicalのセキュリティ告知。

どんな環境で危険になる？

開発元の説明から、問題になる条件を整理すると次のようになる。

1. 脆弱性のあるバージョンのLXD・MicroCloudを使っている。
2. 攻撃者が対象の管理用HTTPS APIに接続できる。
3. 攻撃者が、なりすます相手の信頼済み公開証明書を入手している。

なりすました相手の権限によっては、ホストのroot権限まで取得される可能性があると告知されている。rootは、Linuxでシステム全体を管理できる強い権限だ。Canonicalの影響説明

LXDは、標準ではローカルのUnixソケットを使い、ネットワーク越しには接続できない。HTTPSで接続を受け付けるには設定が必要になる。LXD公式のネットワーク公開手順

ただし、管理APIへの接続経路はインターネット公開だけとは限らない。社内LANやクラスター内も含めて、どこから届くかを確認したい。LXD・MicroCloudの利用者は、公開範囲の確認と併せて修正版へ更新する。

Ubuntuで導入状況とバージョンを確認する

以下は、調べたいサーバーにSSHなどで接続してから実行する。手元のWSLで実行すれば、確認するのもWSL側の環境になる。

まずSnap版が入っているかを見る

製品ごとに確認する。

snap list lxd
snap list microcloud

LXDの確認方法は、公式のSnap管理手順にも載っている。

表示されたら、主に次の列を見る。

バージョンに追加の文字列が付く場合は、先頭の5.21.9などがLXDのリリース番号になる。

該当するSnapがないという表示なら、その名前のSnap版が見つからなかったという意味。ソースからの導入など、別の方法を使っている場合は、その方法で確認する。snapコマンド自体がない場合も、確認のためだけにLXDを新規インストールする必要はない。

LXDのHTTPS設定を見る

LXDが導入・初期化済みなら、管理権限を持つ利用者が対象ホストで次を実行できる。

sudo lxc --force-local config get core.https_address

lxcはLXDを操作するクライアント。--force-localは、そのホストのUnixソケットを使う指定で、別のリモートサーバーを確認してしまうことを避けられる。公式コマンドリファレンス

core.https_addressにアドレスやポートが設定されていれば、その設定でHTTPS接続を受け付ける。実際に誰が接続できるかは、ファイアウォールやネットワーク構成も合わせて確認する。

この値だけで、クラスターやMicroCloudを含む環境全体の安全性までは判断できない。コマンドが失敗した場合も、エラーの理由を確認する必要がある。

修正版とSnapでの更新方法

公式に案内されている修正版は次のとおり。使っている系列に対応する修正版、またはその後の修正を含むバージョンになっているかを確認する。

出典：UbuntuのCVE情報、Canonicalの修正版一覧。この表を「すべての過去バージョンが影響を受ける」という一覧として読むのは避け、個別の影響範囲は公式情報で確認する。

Snap版LXDを使っている場合は、次で更新する。

sudo snap refresh lxd

MicroCloudも導入している場合は、こちらも更新する。

sudo snap refresh microcloud

通常は、今追跡しているチャンネル内の最新版へ更新される。複数台でLXDクラスターを組んでいる場合は、全メンバーのバージョンをそろえるなど、公式のクラスター更新手順にも従う。

更新後は、もう一度snap listで製品ごとのバージョンを確認する。

snap list lxd
snap list microcloud

公式告知には段階的な配信の案内もある。更新がないと表示されても修正版に届いていなければ、チャンネルや配信状況を確認したい。

snap info lxd
snap info microcloud

本番でチャンネルを変更する場合は、互換性や運用への影響を確認する。まずは現在のチャンネルと導入済みバージョンを把握するのが先になる。LXD公式のSnap管理手順

aptで更新していれば大丈夫？

Snap版はSnap側で更新状況を確認する。 APTで管理するパッケージと、Snapで管理するパッケージは分かれている。

Snapには自動更新があるけれど、更新のタイミングや保留設定を変更できる。「普段OSを更新しているから」と推測するより、今回のように製品名を指定して確認するほうが確実だ。Snap公式の更新管理

Ubuntuの「Not in release」と「Medium」はどう読む？

UbuntuのCVEページでは、Ubuntu 24.04などのlxdがNot in releaseになっている。公式の定義は「そのUbuntuリリースに、そのパッケージが含まれない」という意味だ。

そのため、この表示から、別途導入したSnap版LXDの安全性まで判断することはできない。OSの表と、実際に導入したソフトウェアの配布形式・バージョンを組み合わせて確認する必要がある。

また、同ページのMediumはUbuntu側の対応優先度。Ubuntuは、深刻さだけでなく、影響を受ける利用者数や構成なども考慮すると説明している。個別にMediumとした理由までは、このページからは分からない。

一方、LXD・MicroCloudの開発元は今回の問題をCriticalと呼び、利用者に速やかな更新を案内している。優先度の一語だけで判断せず、使っている製品と設定に照らして対応したい。

参考：対象CVEのページ、Ubuntuのステータス・優先度の定義、Canonicalのセキュリティ告知。