UbuntuやDebianでソフトウェアの導入・更新を担う「APT」に、取得したファイルの検証を回避される脆弱性「CVE-2026-109518」が見つかり、2026年11月4日に修正版が公開されました。特定の条件が重なると、不正なパッケージをインストールさせられ、サーバーの管理者権限でプログラムを動かされるおそれがあります。Debianの公式発表

自社サイトをクラウドで運用している場合も、確認が必要です。AWSは11月5日付の案内で、Ubuntu・Debianを使うEC2インスタンスやコンテナーイメージについて、環境を確認し、修正済みAPTを適用するよう利用者に求めています。AWSの案内

APTとは？ サイトの管理画面とは別の更新の仕組み

APTは、ソフトウェアをまとめた「パッケージ」の導入・更新を管理する仕組みです。今回の問題はAPTのHTTP通信処理にあり、apt、apt-get、aptitudeや、APTを使う画面付きの更新アプリにも関係します。Ubuntuの技術説明

Web担当者にとっては、WordPressなどの管理画面から行う更新とは別に、サーバー側の更新を行うAPT自体が修正済みかを確認する話です。「サイトの更新は済んでいる」「クラウドに置いている」という情報だけでは、対応状況は分かりません。

サーバー間で配布されるソフトウェアの箱を盾で守り、通信経路の注意を表した概念イラスト

画像は、ソフトウェアの配布経路と検証の保護を表した概念イラストです。実際の攻撃手順やシステム構成を再現したものではありません。

HTTP通信の操作と、ダウンロードの再試行が成立条件

今回の問題は、インターネットからサーバーへ接続できるだけで、直ちに攻撃が成立するものではありません。未修正のAPTで、主に次の条件が重なる場合に問題になります。

  • パッケージの取得にHTTPを使い、攻撃者がその通信を操作できる。悪意ある配布ミラーやプロキシも含まれる。
  • APTがパッケージのインストールを行う。
  • 取得先の変更を指示するリダイレクトを処理し、失敗したダウンロードを再試行する。
  • 再試行を制御する「Acquire::Retries」が、0以外に設定されている。

公式のCVE情報では、再試行の設定はDebian 12とUbuntu 22.04 LTSから標準で3です。それ以前の版も、管理者の設定やスクリプトで再試行を有効にしていれば影響を受け得るため、「古いOSだから対象外」とは判断できません。Ubuntuの対象条件

技術的には、ダウンロードの再試行時に、同じ実体のファイルを複数の名前で扱う「ハードリンク」の処理が不適切なため、検証済みのパッケージを後から差し替えられる問題です。APTの開発者は、インストールが管理者権限で行われることから、不正なコードの実行につながると説明しています。APT開発者の発表

サイトのファイル、設定、業務データを扱うサーバーで管理者権限を奪われれば、改ざんや情報へのアクセス、停止につながる可能性があります。これは成立した場合のリスクであり、今回の発表から個別の企業の被害が確認されたという意味ではありません。

Ubuntu・Debianの修正版を、OSの版ごとに確認する

Ubuntuの公式セキュリティ通知が示す、主な修正済みAPTの版は次のとおりです。

  • Ubuntu 26.10：3.3.3ubuntu0.1
  • Ubuntu 26.04 LTS：3.2.1ubuntu0.1
  • Ubuntu 24.04 LTS：2.8.4ubuntu0.1
  • Ubuntu 22.04 LTS：2.4.15ubuntu0.1

Ubuntu 20.04 LTSと18.04 LTSにもUbuntu ProのESM経由で修正が提供されています。16.04 LTSと14.04 LTSはLegacy Support追加契約の対象です。古い環境は修正版の有無だけでなく、その端末が必要なサポートと更新経路を利用できるかを確認してください。Ubuntuの修正版・提供条件

Debianでは、主な安定版の修正済みAPTは次のとおりです。

  • Debian 13（trixie）：3.0.4
  • Debian 12（bookworm）：2.6.2

Debian 13は通常のセキュリティ更新、Debian 12はLTSの告知で案内されています。Debian 13の案内、Debian 12の案内

これらは各系列で今回の修正が入った版です。作業時には、そのOSで提供されている最新の修正済み版を確認します。異なるOSの版番号同士を比べたり、上流の番号だけで未修正と判断したりせず、配布元の情報と照合してください。Debianの開発版などの状態も、公式の追跡ページで確認できます。Debianの対応状況

更新するときは、再試行を一時的に止める公式手順を確認

修正版を取得する最初の更新も、現在入っているAPTを使います。Ubuntuは、修正を適用する際にAcquire::Retriesを0にし、再試行を一時的に無効にする方法を案内しています。通信経路を操作する攻撃者と、悪意ある配布ミラーの両方に対する緩和策です。Ubuntuの更新手順

AWSも、影響を受けるインスタンスに対して次の更新例を示しています。

sudo apt-get update && sudo apt-get upgrade -o Acquire::Retries=0

これは保守担当者向けの公式手順の例です。APT以外のパッケージも更新対象になるため、本番環境ではバックアップ、サービスへの影響、必要な再起動、更新後の動作確認を担当者が判断してください。非技術職の担当者が、意味の分からないまま本番で実行することは避けましょう。AWSの更新手順

なお、上の例にある「apt-get update」は更新候補の一覧を取得する処理です。それだけでソフトウェア本体の更新が終わるわけではありません。実際に適用されたAPTの版まで、作業結果として確認することが大切です。apt-getの公式マニュアル

HTTPS化も有効。ただしAPTの更新は省略しない

配布元への通信をHTTPSにすれば、通信途中で内容を差し替えようとする攻撃への対策になります。ただし、配布先のミラー自体が悪意ある場合まで、HTTPSだけで解決するわけではありません。UbuntuはHTTPS化を緩和策として紹介しつつ、修正版の適用を強く勧めています。UbuntuのHTTPS化に関する説明

ミラーによってはHTTPSに対応していないため、設定を書き換えるだけで作業を終えず、更新一覧を正常に取得できるかも確認が必要です。署名や証明書の検証を無効にしてエラーを回避する対応は避け、保守担当者に正しい更新経路を確認してもらいましょう。

保守会社には、対象・適用結果・残る作業を確認する

Web事業者は、CVE番号を添えて次の点をまとめて確認すると、対応の抜けを見つけやすくなります。

  1. どこで使っているか。 本番だけでなく、開発・検証用サーバー、更新に使う環境、コンテナーイメージも確認したか。
  2. どの条件に当たるか。 OSとAPTの版、HTTPの配布元、ミラー・プロキシ、再試行の設定を調べたか。
  3. 何を更新したか。 修正済みAPTの版と適用日時、更新時の保護、必要な動作確認の結果を記録したか。
  4. 再作成時も修正が残るか。 古いイメージからサーバーやコンテナーを作り直したとき、未修正版に戻らないか。
  5. 不審な点がないか。 見覚えのないパッケージや設定変更などがあれば、ログを保全して調査する体制があるか。

最後の点は一般的な事故対応の確認です。修正版を適用したことは、過去に不正なコードが動いていないことの証明にはなりません。一方、今回の脆弱性が対象というだけで、侵入済みと決めつけることもできません。

まずは、自動更新の設定だけでなく、修正済みの版が実際に入っていることまで報告を受け取りましょう。外注やクラウドを使っている場合も、誰がOS側の保守を担当するのかを確認することが出発点です。

情報確認日：2026年11月7日。修正版とサポート条件は、作業前に各提供元の最新案内を確認してください。