LXDに9.9の脆弱性 CVE-2026-66897 LTSは未修正

Ubuntuを開発するCanonicalの「LXD」——1台のサーバーの上に、独立したLinux環境をいくつも立てて動かすためのソフトです——に、深刻度9.9の脆弱性が公表されました（CVE-2026-66897）。コンテナを1つ編集できるだけの権限、あるいは細工されたイメージを起動させるだけで、ホスト側のどのファイルでもroot権限で上書きできます。上書きできるということは、その先でホストの管理者権限を取れるということです。

ただし、更新の案内には注意が必要です。開発元のアドバイザリは修正版として 4.0.13 / 5.0.9 / 5.21.7 / 6.9-ab8fad2 / 6.10 を挙げていますが、2026年8月24日時点で 6.10 は存在せず、LTS系の3つ（4.0.13・5.0.9・5.21.7）はまだ配布されていません。実際にsnapで配られているものとの食い違いを、本記事の中ほどで整理します。なお本件は、同じLXDで8月12日に一斉登録された11件とは別の新しい脆弱性です（そちらはLXDの脆弱性11件をまとめた記事で扱っています）。

CVE-2026-66897 で何が起きるのか

LXDには「テンプレート」という仕組みがあります。コンテナを起動するたびに、あらかじめ決めておいたファイルをコンテナの中に自動で作る機能で、置き先のパスはイメージに同梱された metadata.yaml に書かれています。ホスト名の設定ファイルなどを、起動のたびに書き込むといった用途に使われます。

問題は、この置き先のパスを検査する処理と、実際に書き込む処理がずれていたことです。

• ▸検査するときは、Goの os.Root（指定したディレクトリの外へ出られないようにする仕組み）を使って、パスが枠の中に収まっているかを確かめている
• ▸実際に書き込むときは、その枠を使わず、文字列のパスをそのまま os.Create に渡してファイルを作っている

検査は通ったのに、書き込みは枠の外へ出られる。この差が抜け道になります。開発元のアドバイザリは具体例として /nonexistent/../../victim のような形を挙げています。存在しないディレクトリを一度経由させるのがポイントで、この形は検査を通り抜け、その後の filepath.Join が .. を整理した結果、枠の外を指すパスに変わります。

書き込みはホストのroot権限で行われるため、ホスト側のどのファイルでも上書きできます。ログイン設定や定期実行の設定を書き換えれば、そのままホストの乗っ取りに至ります。分類はCWE-22（パス名の制限不備）、CVSSは3.1基準で9.9です。スコープが「変更あり」と評価されており、コンテナという枠を越えて影響が及ぶことがスコアに反映されています。

攻撃に必要なもの — コンテナ1つの編集権限だけ

この脆弱性のたちの悪さは、前提条件の軽さにあります。開発元のアドバイザリは、コンテナ1つに対する can_edit 権限があれば足りるとしています。経路は2つです。

• ▸APIからメタデータを更新する — 権限を絞って渡したはずの利用者が、自分のコンテナのメタデータを書き換えるだけで成立します
• ▸細工されたイメージを起動させる — こちらは権限すら要りません。誰かが用意したイメージを取り込んで起動した時点で発動します

そして、テンプレートの適用はコンテナを起動するたびに毎回走ります。一度仕込まれれば、再起動のたびに書き込みが繰り返されることになります。

1台のLXDホストを複数の人やチームで分け合っている環境、社外から持ち込まれたイメージを動かす環境、検証用にネット上のイメージを気軽に取ってくる環境——このいずれかに当てはまるなら、優先度は高いと考えてください。逆に、自分ひとりで使っていて、自分で作ったイメージしか動かさないのであれば、慌てる必要はありません。

影響を受けるバージョンと、開発元が挙げる修正版

表の右端が、開発元のアドバイザリが「これに上げてください」と示している版です。ところが、この案内をそのまま実行しようとすると行き詰まります。

案内されている修正版が、まだ配られていない

LXDは主にsnap（Ubuntuのパッケージ形式）で配布され、既定では自動更新されます。そこで、実際にsnapで配られている版を確認しました。2026年8月24日時点の状況です。

読み取れることは3つです。

1つめ。6系を使っているなら、対処はすでに終わっています。snapで配られている 6.9-ab8fad2 は、アドバイザリが修正版として挙げているものと同じです。8月2日の配布で、自動更新が効いていれば手を動かす必要はありません。

2つめ。6.10は存在しません。アドバイザリは修正版として 6.10 を併記していますが、GitHubのタグ lxd-6.10 は8月24日時点で存在せず（照会すると404が返ります）、リリース一覧にもありません。6系の最新は6.9です。「6.10へ上げてください」という案内には、現時点で従えません。

3つめ。LTS系の3つは取り残されています。4.0.13 / 5.0.9 / 5.21.7 は、GitHubのタグとしては存在します。しかしリリース一覧には載っておらず、snapの各チャンネルにも届いていません。snapで配られているのは 4.0.12 / 5.0.8 / 5.21.6 のままです。つまり、LTSを使っている環境は、上げたくても上げられる先がない状態です。今回は6系だけが先に直り、長期サポート版が後回しになっています。

同じLXDの8月12日の11件でも、案内された 6.10 が存在しないという同じ食い違いが起きていました。アドバイザリの記載を鵜呑みにせず、配布物を確認してから動く——このソフトについては、その手順を習慣にしておくのが安全です。

なぜ同じ形の穴が繰り返し見つかるのか

LXDのアドバイザリ一覧を並べると、今回の1件が単発ではないことが分かります。7月31日には9件がまとめて公開されており、その内訳は次のような顔ぶれです。

• ▸バックアップ書庫の復元時に、インスタンス名が検証されずrootでファイルを書けるもの（Critical）
• ▸イメージ内の metadata.yaml をシンボリックリンクにすると、ホストのファイルへrootで到達できるもの（Critical）
• ▸イメージの backup.yaml のシンボリックリンク経由でroot権限のコード実行に至るもの（Critical）
• ▸過去の修正が不完全だったもの — テンプレートのパストラバーサル対策がLXCのドライバには入ったが、QEMU（仮想マシン）側のドライバには入っていなかった（High）

最後の1件が、今回を理解する鍵になります。「対策を入れたが、入れた範囲が足りていなかった」という指摘です。そして今回のCVE-2026-66897も、構造としてはまったく同じ形をしています。パスの検査には os.Root という新しい安全な仕組みを導入したのに、その直後の書き込みには適用し忘れていた。安全な部品を入れること自体が対策なのではなく、通り道すべてに行き渡らせて初めて対策になる——という教訓が、同じ製品で繰り返し出ています。

運用側が受け取るべき示唆は単純です。LXDのこの領域は現在も掘られ続けており、今後も同種の報告が続く前提で構えたほうがよいということです。都度の更新に加えて、「誰にコンテナの編集権限を渡すか」「どこから来たイメージを起動するか」という2つの入口を絞っておけば、次に似た脆弱性が出たときの影響も同時に小さくできます。個別のCVEを追いかけるより、こちらのほうが費用対効果は高くなります。

攻撃されているのか

2026年8月24日時点で、実際に攻撃に使われたという報告は確認できません。CISAのKEV（実際に悪用が確認された脆弱性の一覧）はカタログ版 2026.08.21・全1,674件を実査しましたが、本件は未収載です。EPSSは公開当日のためまだ算出されていません。公開されている実証コード（PoC）も見つかっていません。KEVの状況はCISA KEV ダッシュボード（日本語版）でも追えます。

報告したのは @larrasket 氏で、アドバイザリの公開はLXDのメンテナである tomponline 氏が行っています。外部の研究者からの報告を開発元が受け取って修正し、公表するという通常の流れをたどっており、攻撃者が先に見つけて悪用していたことを示す情報はありません。

アドバイザリには回避策（設定変更などで塞ぐ方法）の記載がありません。テンプレートはLXDの標準機能で、切り離せる作りになっていないためとみられます。できるのは、更新することと、誰にコンテナの編集権限を渡しているかを見直すことの2つです。

何をすればいいのか

• ▸まず版を確認する — snap list lxd で、入っている版とチャンネルが分かります。6.9-ab8fad2 と出ていれば対処は済んでいます
• ▸6系なら更新する — snap refresh lxd を実行します。自動更新を止めている環境では、これが必要です
• ▸LTS系なら、当面は権限側で守る — 上げる先がまだ配られていないため、コンテナの編集権限を持つ利用者を絞る、出所の分からないイメージを起動しない、の2点で凌ぎます。LTSチャンネルの更新が来ているかは snap info lxd で確認できます
• ▸持ち込みイメージの経路を洗う — 権限がなくても、細工イメージを起動させるだけで成立します。CIやテスト基盤が外部のイメージを自動で取得して起動していないか確認してください

なお、LXDから派生した「Incus」を使っている場合も、同じ由来のコードを持つため確認が必要です。Incus側は独自に採番と修正を行っており、CVE番号としては表に出にくい傾向があります。利用している場合は、開発元の告知を直接確認してください。

よくある質問

参照元

• ▸Canonical LXD - GHSA-q39m-8fx9-42fv（公式アドバイザリ・2026年8月24日）
• ▸NVD - CVE-2026-66897（CWE-22・CVSS 3.1で9.9）
• ▸Canonical LXD - Security Advisories 一覧（7月31日公開の9件を含む）
• ▸Snap Store - lxd（各チャンネルの配布状況。本記事の表は2026年8月24日時点のAPI応答を実査）
• ▸Canonical LXD - Releases（4.0.13 / 5.0.9 / 5.21.7 / 6.10 の掲載なしを確認）
• ▸CISA - Known Exploited Vulnerabilities Catalog（版 2026.08.21・全1,674件を実査、未収載）
• ▸関連記事：Ubuntuの「LXD」に脆弱性11件 CVE-2026-63294ほか（当サイト）