APTにroot権限のコード実行につながる脆弱性 更新時の再試行制御と修正版を確認

UbuntuとDebianは2026年11月4日、パッケージ管理システムAPTの脆弱性CVE-2026-109518を修正しました。HTTPでパッケージを取得し、ダウンロードのリトライが有効な構成では、通信経路を操作できる攻撃者が未検証のパッケージをインストールさせ、root権限でコードを実行できる可能性があります。対象サーバーの管理者は、APT自体の更新を優先してください。

特に重要なのは、修正版を取得する作業にも今回の条件が関わる点です。公式は更新時にAcquire::Retries=0を指定する方法を案内しています。EC2の稼働インスタンスはイメージの更新を待たず対処し、Ubuntu・Debianを使うコンテナは修正済みAPTを含むイメージへ再ビルド・再配備します。

本稿は11月7日に確認した新規の修正情報です。根拠はCanonicalのAPT修正解説、Ubuntuの通知、Debianの勧告、AWSの告知です。以下では公式の条件と更新方法を整理し、運用上の確認方法は本サイトの提案として示します。実機で攻撃を再現した報告ではありません。

攻撃にはパッケージ取得とHTTP通信の操作が必要

対象は、外部から接続されるWebサービスの待ち受けポートではなく、APTクライアントがパッケージを取得する経路です。APTが.debをインストールする際に、攻撃者がクライアントとアーカイブサーバーの間のHTTP通信を操作できることが条件です。悪意あるミラーやプロキシも、この条件に含まれます。インターネットへ公開したサーバーだけを探す調査では対象を落とします。

Canonicalは、HTTPリダイレクトとダウンロード再試行の際にハードリンクを適切に扱わないことが原因と説明しています。Debianの勧告も、同じURIへ誘導された二つの取得処理が統合され、再開時のファイル処理によって検証後のパッケージを置き換えられ得るとしています。単に署名のないリポジトリーを登録した場合だけの問題ではありません。

通常、APTのアーカイブ検証は配布物の完全性を確かめる仕組みです。今回の問題は、その検証がある運用でも成立し得ます。インストール時にはパッケージの管理用スクリプトがroot権限で実行されるため、取得ファイルの置換がシステムの侵害につながります。ただし、攻撃可能性の説明と実際の侵害確認は別です。確認した公式資料から、このCVEの実環境での悪用は確定できません。

初期設定で影響する版と変更済み設定を分ける

必要条件の一つはAcquire::Retriesが0以外であることです。UbuntuのCVE情報は、Debian 12とUbuntu 22.04 LTSから既定値が3になったと説明しています。それ以前のリリースは初期設定では影響しませんが、管理者や構築ツールが値を変更していれば、古いOSという理由だけで対象外にできません。

Canonicalによる評価はHigh、CVSS v4.0は7.7です。この数値を認証不要の公開サーバー向けRCEと同じ条件として読まないでください。通信を操作できる位置、HTTPの取得元、リダイレクトと再試行、パッケージのインストールが関係します。APTライブラリーのHTTPバックエンドを使うため、apt-getへコマンド名を変えるだけでは回避になりません。aptやaptitude、APTを使うGUIも確認対象です。

HTTPを使わない取得経路や、APTとは異なる仕組みのsnapによるインストールまで一括して影響ありとするのも不正確です。一台のUbuntu端末に複数の配布方式があれば、どのアプリを使うかではなく、どの経路で.debを取得・導入するかを調べます。HTTPSへの切り替えは通信経路上の改変への緩和策になりますが、APTの修正適用を置き換えるものではありません。

UbuntuとDebianの修正版をリリースごとに照合する

Ubuntuの修正番号はUSN-8996-1、Debianの状況はDebian Security Trackerで確認できます。次は11月7日の確認時点の修正版です。系列が違う数字を大小だけで比較せず、使用するOSリリースに対応する行を使ってください。

OSリリース	APTの修正版
Ubuntu 22.04 LTS	2.4.15ubuntu0.1
Ubuntu 24.04 LTS	2.8.4ubuntu0.1
Ubuntu 26.04 LTS	3.2.1ubuntu0.1
Ubuntu 26.10	3.3.3ubuntu0.1
Debian 12 bookworm	2.6.2
Debian 13 trixie	3.0.4

Ubuntu 20.04 LTSの修正は2.0.12+esm1、18.04 LTSは1.6.19+esm1で、通知にはUbuntu Proの提供条件があります。16.04と14.04にはLegacy Supportの条件も示されています。修正版が存在することと、自分の契約・リポジトリーで取得可能なことを分けて確認します。非公式のパッケージで数字だけを合わせる対応は避けてください。

DebianのDSA-6607-1はtrixieを対象に3.0.4を案内し、トラッカーはbookwormのセキュリティ更新2.6.2も修正済みとしています。同じCVEへの配布であっても、通知の対象系列は異なります。OSを別のメジャー版へ上げる手順と、現在の系列に修正を適用する手順を混同しないことが大切です。

修正版の導入中は再試行を止める

まずOSリリースと導入済みAPTを記録します。次は管理者が対象ホストで確認するための例です。apt listの式はCanonicalの解説にあるもので、APTソースパッケージに由来する導入済みパッケージを確認します。出力の版を上の表と照合し、関連ライブラリーも確認対象にします。

cat /etc/os-release
apt list --installed '?source-package(^apt$)'

Canonicalは全体を更新できる場合、次の方法を案内しています。Acquire::Retries=0はこのupgrade呼び出しで取得の再試行を止める指定です。永続設定を必ず変更するという指示ではありません。システム全体の更新になるため、変更対象とサービスへの影響を確認し、組織の保守手順で実施してください。

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

全パッケージの更新を同時に行えない場合、Canonicalは対象コンポーネントを絞る方法も示しています。必要な修正を取り込むための選択肢であり、その後の通常のセキュリティ更新を省く理由にはなりません。

sudo apt update && sudo apt install -o Acquire::Retries=0 --only-upgrade '?source-package(^apt$)'

更新できないときは、ネットワーク障害を避けるためにリトライ回数を戻して同じ操作を続ける前に、取得元、到達性、利用できる修正パッケージを調べます。署名エラーや証明書エラーを無効化して通す方法は使いません。作業後は導入済み版を再取得し、更新コマンドを入力した事実だけで完了にしないでください。

HTTPS化ではミラーと設定形式を確認する

APTの取得元は/etc/apt/sources.listと/etc/apt/sources.list.d/配下にあり、.list形式とDEB822の.sources形式があります。CanonicalはUbuntuアーカイブのHTTP URLをHTTPSへ変える例を公開していますが、その置換例はすべての第三者ミラーを対象にするものではありません。一部のコミュニティーミラーにはHTTPS非対応のものもあります。

本サイトでは、変更前に設定を控え、実際のミラーがHTTPSを提供するかを確認してから変更することを勧めます。変更後のapt updateでエラーが出た場合は、URLの誤り、ミラーの対応、証明書の検証、プロキシの経路を切り分けます。エラーの原因を残したまま、TLS検証を弱めて成功表示だけを得る対応は避けます。

HTTPSは通信途中の保護、アーカイブの署名・ハッシュ検証は配布物を確認する仕組みで、目的が重なっても同じものではありません。公式資料は修正後も署名による検証が重要であると説明しています。今回の対応は「HTTPを一文字変えればすべて完了」ではなく、修正済みAPTの導入を中心に考えてください。

稼働ホストと次に起動するイメージを別に直す

AWSの2026-172-AWS告知は、EC2上の自己管理Ubuntu・Debianの更新責任が利用者にあると明示しています。古いイメージから起動していても、対象ホストで修正を適用すれば、そのホストの対処は進められます。更新済みAMIの公開予定を待つことを、稼働中サーバーの修正の前提にしないでください。

コンテナについては、AWSは修正済みAPTを含むイメージへの再ビルドと再配備を求めています。ホストを更新しても、別のファイルシステムを持つイメージ内のAPTが更新されたことにはなりません。CIでパッケージを追加する段階、共通ベースイメージ、次回の自動増設で使うテンプレートも確認対象として残します。

本サイトの運用提案は、対象ごとにOSリリース、APTの導入版、取得元、更新結果、イメージ識別子を記録することです。たとえば本番VMの対処が終わっても、翌日の再配備が未修正イメージへ戻るなら、環境全体の対処は完了していません。稼働中と将来起動するものを分けると、残作業を具体的に示せます。

修正は今後のこの攻撃経路を塞ぐ作業です。すでに不審なパッケージ導入や侵害が疑われる場合、APTを更新しただけで過去の被害が解消したとは判断できません。取得・導入履歴など必要な記録を保全し、組織の初動対応へ切り替えます。本稿は侵害を判定する検査手順や、特定の利用組織に被害があったという報告ではありません。

関連記事

• UbuntuのPHP修正パッケージと適用状況の確認：別の脆弱性を扱う既存記事です。アプリケーション側の更新は、今回のAPT自体の修正と分けて管理します。