Ubuntuの「LXD」に脆弱性11件 CVE-2026-63294ほか、危ないのは実質4件だけ

2026年8月12日、米国の脆弱性データベース NVD に、Ubuntuの開発元であるCanonicalの製品「LXD」の脆弱性が11件まとめて登録されました。そのうち9件がCVSS 9.9という、10点満点にほぼ張り付いた深刻度です。

数字だけ見れば大事件に見えます。ただ、実際に調べると話はかなり違いました。修正版はすでに8月2日に配布が完了しており、多くの利用者の手元では自動更新で対処が終わっています。さらに、9件あるはずの「9.9」のうち2件は、Canonical自身が本来「高（8.7 / 8.5）」と評価していたものが、登録データの食い違いによって最高ランクに膨らんで公開されたものでした。

この記事では、11件の正体、自分に関係があるのはどれか、どのバージョンに上げればいいのかを整理します。結論を先に書くと、あなたが自分ひとりでサーバーを使っていて、他人が作ったファイルを取り込む習慣がなければ、11件のうち11件とも実害はありません。逆に、たった1つの行為だけが単独利用者にも直撃します。

LXDとは何をするソフトなのか

LXDは、Canonical（Ubuntuというパソコン・サーバー向けOSを開発している英国企業）が作っている管理ソフトです。ひとことで言えば、サーバー1台の中に、独立した小さなサーバーを何台も作って動かすための道具です。

たとえば物理サーバーが1台あるとして、その中に「開発チーム用」「経理システム用」「お客様に貸し出す用」といった区画を切り、それぞれが別々のマシンであるかのように動かせます。この区画のことをコンテナ（軽量な仮想マシン）と呼びます。コンテナの仕組みそのものについては以前に解説した記事があるので、耳慣れない方はそちらも参考にしてください。

似た用途のソフトとしてはDockerが有名ですが、Dockerが「アプリを1つ動かす箱」なのに対して、LXDは「OSごと1台分を丸ごと動かす箱」を扱います。レンタルサーバー事業者やホームサーバー愛好家、研究室のマシン共有などで使われています。

なお、LXDには Incus（インカス）という派生版があります。2023年にCanonicalがLXDの管理体制を変更した際、開発者らが分岐して作ったもので、Debianなどはこちらを採用しています。今回の話はIncusにも関係するので、後半で触れます。

11件の脆弱性の中身

Canonicalが公式に公開したアドバイザリと、各CVEの技術詳細（GitHubのセキュリティアドバイザリ）をもとに、11件を一覧にしました。

11件のうち1件も「インターネットから誰でも攻撃できる」ものはありません。すべて「LXDに何らかのアカウントを持っている」または「管理者自身が細工されたファイルを取り込む」ことが前提です。この一点だけでも、9.9という数字から受ける印象とは温度差があります。

誰がこの穴を狙い、何をするのか

今回の11件を狙う立場にいるのは、外から無差別にサーバーを探し回る攻撃者ではありません。サーバーの区画を1つ借りている、正規のアカウント保持者です。研究室のマシンを共有している学生、社内の別部署、レンタルサーバーの隣の契約者。つまり「もともと少しだけ中に入れる人」が主役になります。もう一方の入口は、配布されている雛形ファイルに細工を仕込んでおく人物です。こちらは中に入る必要すらなく、管理者が自分でファイルを取り込むのを待つだけで済みます。

彼らがやるのは、貸し与えられた小部屋の壁を抜けることです。本来は自分の区画の中しか触れないはずなのに、設定の検査漏れや、ファイルの経路のすり替えを使ってサーバー本体の管理者権限を手に入れます。中でも CVE-2026-63294 は、細工したファイルを取り込ませるだけでサーバーの起動時処理に自分のプログラムを割り込ませられる、いちばん短い経路が確認されています。

そこまで行かれると何が失われるか。サーバー本体を取られるということは、同じマシンに同居している他の区画をすべて覗けるということです。他社・他部署のデータベース、保存されている顧客情報、バックアップ、鍵ファイル。区画ごとにパスワードを分けていても意味がありません。運用する側にとっては、「1台を複数の相手に安全に貸せる」という前提そのものが崩れます。だからCanonicalも、今回の一連の欠陥を「LXDが提供する分離の保証を著しく損なう」と表現しています。もっとも、それは裏返せば分離を必要としていない使い方なら影響が届かないということでもあります。次の章で線を引きます。

自分に関係があるのはどれか

11件は、成立条件で見るとはっきり2つに分かれます。ここが今回いちばん実用的な部分です。

グループA：他人と1台を共有している人だけ（7件）

CVE-2026-62420 / 63295 / 63296 / 63297 / 63298 / 63299 / 63300 の7件は、LXDの「プロジェクト」機能を、信用しきれない相手を隔離する壁として使っている場合にだけ意味を持ちます。攻撃者役は「制限をかけた区画の中にいる誰か」であり、その人が壁を越えて外に出るのが被害の形です。

自分ひとりしかLXDを操作しない環境なら、この7件にはそもそも攻撃者を務める人がいません。さらにCVE-2026-62420とCVE-2026-63296の2件は、複数台のサーバーを1つに束ねたクラスタ構成でなければ成立しません。ホームサーバー1台でコンテナを並べているだけの使い方であれば、この7件は静観して構いません。

グループB：他人が作ったファイルを取り込む人（4件）

問題はこちらです。CVE-2026-63293 / 63294 / 16033 / 66898 の4件は、共有もクラスタも一切不要で、条件はただ1つ、「そのイメージやバックアップは誰が作ったものか」だけです。

具体的には、フォーラムやチャットで共有された仮想マシンの雛形、他社から受け取った移行用のバックアップ、GitHubで拾ってきた構築済みイメージ。こういったものを取り込むコマンドを叩いた瞬間に、管理者本人の手でサーバー本体を明け渡すことになります。「安全なはずの自分ひとりのマシン」であっても関係ありません。

ただし、Canonicalが提供する公式のイメージ配布元だけを使っている場合は、実質的な脅威にはなりません。今回の4件で危ないのは、あくまで出所の分からないファイルを持ち込むケースです。この「信用できない部品を自分で取り込んでしまう」構図は、開発ツールの依存関係を経由して連鎖的に汚染が広がった事例や、公式配布のコンテナイメージに初期パスワードが残っていた件と同じ系統の話です。自分の環境が何を外から取り込んでいるかは、当サイトで公開している無料のOSSサプライチェーン スキャナーのようなツールで一度洗い出しておくと把握しやすくなります。

「9.9が9件」は実は水増しだった

ここからは、翻訳記事では出てこない部分です。NVD上で9.9とされている9件のうち、2件はCanonical自身がそこまで高く評価していません。

脆弱性の点数（CVSS）は、「ネットワーク越しか」「権限が要るか」「何が壊れるか」といった条件を並べた短い文字列から機械的に計算されます。ところが今回、CVE-2026-63298とCVE-2026-63299の2件では、Canonicalが登録した点数と、同時に登録した条件の文字列が食い違っていました。

NVDは提出された点数をそのまま信じるのではなく、条件の文字列から計算し直します。結果として、Canonicalが「高」と判断していた2件が「緊急」として世に出ました。したがって、実際に9.9と評価されているのは9件ではなく7件です。

細かい違いに見えますが、脆弱性管理ツールの多くはCVSS 9.0以上を自動で最優先の警報として扱います。運用担当者が深夜に叩き起こされるかどうかが、この2件分だけ変わります。CVSSの数字を鵜呑みにせず、条件と前提を読んでから優先順位を決めるべき、という教科書どおりの例が出てきたかたちです。実際に攻撃されている脆弱性かどうかを併せて確認したい場合は、米政府CISAが公開している「実際に悪用が確認された脆弱性リスト」を日本語で引けるダッシュボードも用意しています。今回の11件は、そのリストには1件も載っていません。

どのバージョンに上げればよいのか

Canonicalが示した修正版は次のとおりです。LXDは配布経路（チャネル）ごとに系統が分かれているので、自分が使っている系統の行だけ見れば足ります。

UbuntuでLXDを使っている場合、通常はsnapという仕組みで自動更新が有効になっています。8月2日の時点で、すべての安定版チャネルに修正版が届き終わっています。念のため確認したい場合は snap list lxd でバージョンを見て、古ければ sudo snap refresh lxd を実行するだけで済みます。Ubuntu本体の更新（Ubuntu標準の管理ツールに重大な脆弱性が見つかった件やAD連携ツールADSysの件で使うaptとは経路が違う点に注意してください。

「6.10へ更新を」という案内には従えない

ここは今回いちばん引っかかりやすい罠です。CVEの登録データや一部のアドバイザリには、6系の修正版として「6.10」と書かれています。ところが、LXD 6.10というバージョンは2026年8月13日時点で存在しません。GitHub上の6系の最新タグは6月23日の lxd-6.9 のままです。

実際に修正が入っているのは、6.9を差し替えた暫定版のsnap（6.9-ab8fad2）だけです。つまり6系をソースコードから自分でビルドして使っている人には、修正を受け取る経路が現時点で存在しません。「6.10が出たら上げよう」と待っていると、いつまで経っても脆弱なままになります。該当する場合は、修正が入ったコミットを取り込むか、長期サポート系列（5.21.6など）に切り替える判断が要ります。

修正は11日前に終わっていた

「8月12日に11件が公開された」という見え方は、あくまでNVDへの登録日を見た結果です。実際の流れはこうでした。

← スワイプで移動

脆弱性の監視ツールや購読サービスは、NVDへの登録を基準に警報を出します。そのため今回のように「修正が終わってから10日以上経って一斉に鳴る」ことが起こります。警報が鳴った日と、危険だった期間はまったく別物です。これは今回に限らず、CVEの日付を扱うときに毎回効いてくる話です。

同じ穴はIncusにもある。ただし数字には出ていない

Canonicalのアドバイザリには、興味深い一文があります。今回の脆弱性の一部は「Incusプロジェクトから報告され、LXDにも影響することが確認された」ものだと明記されているのです。実際、Incus側のセキュリティ情報はLXDより1日早い7月30日に公開されており、Incusの開発者が見つけた欠陥がLXDにも共有された形です。

ところが2026年8月13日時点で、Incus側の脆弱性にはCVE番号が付いていません。Incusは番号の発行をGitHubに委ねており、そのGitHub側の処理が3〜4週間分たまっているためです。一方Canonicalは自社で番号を発行できる立場にあるため、11件がその日のうちに世に出ました。

結果として何が起きるか。脆弱性スキャナや脅威情報のフィードを眺めると、「LXDだけが穴だらけで、Incusは健全」に見えます。実際には同じ欠陥を両者が抱えていて、片方は番号待ちで統計に現れていないだけです。番号の有無が製品の安全性を表しているわけではない、という当たり前の事実が、今回わかりやすい形で可視化されました。数字で製品を比較するときには、この非対称を頭に置いておく必要があります。

なお、Debianは以前からLXDではなくIncusを採用する方針に移っており、収録されているLXDは5.0系の古い版のままです。DebianでLXDを使っている場合、今回の11件はまだ整理すら始まっていません。この点は自力での確認が必要です。

攻撃に使われている形跡はあるのか

現時点では、実際に攻撃された報告も、攻撃用のコードの公開も確認されていません。整理すると次のとおりです。

報道もほとんど出ていません。海外の主要セキュリティメディアはいずれも未報道で、開発者コミュニティの反応も静かなままです。7月に公開されたCanonicalの公式アドバイザリには返信が1件も付いておらず、英語圏の技術系掲示板に立った関連スレッドもコメントゼロで流れています。修正がすでに配り終わっていて、しかも遠隔から一方的に攻撃できる類のものではないため、騒ぎになりようがなかったというのが実情でしょう。

見つけたのは誰か

11件は1つの研究チームの成果ではなく、6人の報告者が別々に見つけたものをCanonicalがまとめて処理した結果です。最も多くを報告したのは、動画共有サービスTikTokのセキュリティ部門に所属するZhixi "Jace" Sun氏で、11件中6件に関与しています。ほかにインドネシアのAdam Jordan氏、ペネトレーションテスト（侵入テスト）を手掛けるKingsley Olukanni氏らの名前が挙がっています。

内容を読むと、力任せの攻撃実験ではなく、ソースコードを読み込んで論理の穴を突く手法が中心です。たとえばCVE-2026-16033は、6月に修正された別の脆弱性について「コンテナ側の処理には防御が入ったのに、仮想マシン側の処理には入っていない」ことを指摘したものでした。11件のうち2件が、過去の修正の取りこぼしを再度突いたものです。この「修正漏れを追いかける」動きは、Linuxカーネルの権限昇格の脆弱性やOpenShiftの通信乗っ取りの件でも見られた流れで、一度パッチが出た箇所ほど再点検の対象になりやすいという傾向がここでも出ています。

結局、何をすればいいのか

やることは多くありません。まず snap list lxd でバージョンを確認し、5.21.6 / 5.0.8 / 4.0.12 / 6.9-ab8fad2 のいずれかに達していれば、それで終わりです。届いていなければ sudo snap refresh lxd を実行します。ソースコードから6系をビルドしている場合と、Debianのパッケージ版を使っている場合だけは、自分で修正の取り込み状況を確かめる必要があります。

そして今後の運用として意識しておきたいのは、出所の分からないイメージやバックアップを取り込まないという一点です。今回の11件のうち、単独利用者にも刺さる4件はすべてここが入口でした。公式の配布元だけを使っていれば、この経路は塞がります。

最後にもう一度整理しておきます。9.9という数字は9件ではなく7件、11件すべてに認証か管理者操作が必要、うち7件は他人と1台を共有していなければ関係なし、修正は8月2日に配布完了、悪用の報告なし。「CVSS 9.9が9件」という見出しだけを見て慌てる必要はありません。ただし、6.10を待っている人と、他人のイメージを気軽に取り込んでいる人。この2種類だけは、いま手を動かす価値があります。

参照元

• ▸ Canonical - Security advisory: Multiple vulnerabilities found in Canonical LXD
• ▸ GitHub - canonical/lxd セキュリティアドバイザリ一覧
• ▸ Canonical - LXD 6.9 interim snap release (6.9-ab8fad2)
• ▸ Canonical - LXD 5.21.6 LTS has been released（2026年7月23日）
• ▸ Canonical - LXD 4.0.12 LTS has been released
• ▸ NVD - CVE-2026-63294
• ▸ NVD - CVE-2026-63293
• ▸ NVD - CVE-2026-66898
• ▸ NVD - CVE-2026-63298
• ▸ NVD - CVE-2026-63299
• ▸ GitHub - lxc/incus セキュリティアドバイザリ一覧
• ▸ Linux Containers - Incus 7.3 has been released（2026年7月31日）
• ▸ Debian Security Tracker - lxd
• ▸ CISA - Known Exploited Vulnerabilities Catalog