CVE-2026-109518 Debian APT｜攻撃条件と安全な更新手順

はじめに

2026年11月4日、Debian は APT の脆弱性 CVE-2026-109518 を修正するセキュリティアドバイザリー DSA-6607-1（Debian 13 trixie 向け）と DLA-4880-1（Debian 12 bookworm 向け）を公開しました。HTTP 通信を操作できる攻撃者が、APT による検証を通過したパッケージを別の内容に置き換え、root 権限でコードを実行できる可能性がある問題です。

APT はリポジトリの署名とパッケージのハッシュで正当性を確認しているため、「署名検証があるのになぜ成立するのか」「HTTPS なら関係ないのか」「コンテナや CI/CD では何を更新すればよいのか」と判断に迷う方も多いと思います。本記事では、一次情報で確認できる範囲に限定して、攻撃の成立条件、影響確認、安全な更新手順を整理します。

結論として、Debian 13 trixie は apt 3.0.4、Debian 12 bookworm は apt 2.6.2 で修正されています。攻撃には、APT と配布元の間の HTTP 通信を操作できる立場と、ダウンロードの再試行（Acquire::Retries が 0 以外）が必要です。ホストの apt を更新するだけでなく、APT を使うコンテナイメージと CI/CD のビルド環境も修正版へ更新する必要があります。

CVE-2026-109518 の概要と影響を受ける APT バージョン

CVE-2026-109518 は、APT の HTTP ダウンロード処理で、リダイレクトと再試行の組み合わせによりハードリンクが不適切に再利用される脆弱性です。CVE レコードは Canonical が CNA として公開しており、Debian と Ubuntu の双方の APT が対象として記載されています。

脆弱性の基本情報

CVE レコードの CISA ADP（Vulnrichment）が付与した SSVC では、2026年11月4日時点で Exploitation が「none」と評価されています。ただし、これは評価時点の情報であり、悪用や PoC が存在しないことを保証するものではありません。公開後も CISA KEV と各ベンダーの情報を確認してください。

Debian 各系列の修正版

Debian Security Tracker では、2026年11月5日時点で次の状態が示されています。

Debian 12 bookworm 向けの修正は、通常の DSA ではなく LTS アドバイザリー（DLA-4880-1）として提供されています。forky や sid を利用している場合は、公開後の更新も含めて Security Tracker で最新の状態を確認してください。

参考: Debian Security Tracker（CVE-2026-109518）
https://security-tracker.debian.org/tracker/CVE-2026-109518

Debian 11 以前と既定の再試行設定

CVE レコードによると、攻撃には Acquire::Retries が 0 以外であることが必要です。この値が既定で 3 になっているのは Debian 12 bookworm と Ubuntu 22.04 LTS 以降であり、それより古いリリースは既定構成では影響を受けないとされています。

参考: CVE-2026-109518（CVE Record）
“requires the client to have a non-zero Acquire::Retries configuration setting”
（クライアント側で Acquire::Retries が 0 以外に設定されている必要がある）
https://www.cve.org/CVERecord?id=CVE-2026-109518

ただし、Debian 11 以前でも設定ファイルやコマンドラインで再試行を有効にしている場合は、条件を満たす可能性があります。古い系列を「既定なら対象外」と判断する場合も、後述の手順で実際の設定値を確認することを推奨します。

DSA-6607-1 に含まれる別の修正と Ubuntu の扱い

DSA-6607-1 では、CVE-2026-109518 に加えて複数の境界外アクセスの問題も修正されています。Debian Package Tracker に掲載された apt 3.0.4 の変更履歴でも、deb の制御ファイル処理、gpgv の鍵 ID 処理、tagfile などの修正が CVE-2026-109518 とは別の項目として記載されています。これらは本記事で扱うリダイレクト・再試行の問題とは別の修正であり、同じ攻撃条件で成立するものではありません。

Ubuntu でも USN-8996-1 で修正版が公開されています（例: Ubuntu 24.04 LTS は 2.8.4ubuntu0.1）。Ubuntu の apt はバージョン番号に ubuntu や +esm を含む独自の体系で提供されるため、Debian の修正版番号と比較せず、USN-8996-1 の表で判断してください。

APT の署名検証があっても攻撃が成立する理由

この脆弱性は、検証の仕組みそのものを破るものではありません。検証を通過したファイルと、実際にインストールされるファイルの内容が一致しなくなる点が問題の本質です。

APT がパッケージの正当性を確認する仕組み

APT は、個々の .deb ファイルの電子署名を直接検証しているわけではありません。正当性の確認は、次の 2 段階で行われます。

リポジトリの署名検証

InRelease などのリポジトリのメタデータに付けられた署名を、信頼済みの鍵で検証します。これにより、パッケージ一覧（Packages ファイル）とそのハッシュ値が正規の配布元のものであることを確認します。

パッケージのハッシュ検証

ダウンロードした .deb ファイルのハッシュ値を、署名済みのパッケージ一覧に記載された値と照合します。一致しなければ、そのファイルはインストールされません。

この仕組みにより、通常は HTTP で取得したパッケージを経路上で改ざんされても、ハッシュの不一致として検出されます。CVE-2026-109518 は、この照合が終わった後にファイルの中身が変わり得る点を突くものです。

リダイレクトと再試行で検証済みファイルが置き換わる流れ

Ubuntu の USN-8996-1 は、原因を次のように説明しています。

参考: Ubuntu Security Notice USN-8996-1
“incorrectly handled hard links when encountering redirects and retrying package downloads”
（リダイレクトの発生時とパッケージダウンロードの再試行時に、ハードリンクを不適切に処理していた）
https://ubuntu.com/security/notices/USN-8996-1

DSA-6607-1、APT 開発者による deity メーリングリストでの説明、Canonical の公開情報を合わせると、攻撃は次の要素がつながることで成立します。実装の詳細は公開情報で確認できる範囲に限定し、以下は編集上の整理として示します。

1. パッケージのインストールに伴い、APT が HTTP で複数の .deb ファイルを取得します。
2. 通信経路上の攻撃者（または悪意あるミラーやプロキシー）が HTTP リダイレクトを返し、別々のパッケージのダウンロードが同じ URI を指すようにします。
3. APT は同じ URI になった 2 つのダウンロードをまとめて扱い、その過程でハードリンクが再利用されます。
4. 一時的な HTTP エラーなどでダウンロードが失敗すると、APT が Acquire::Retries に従って再試行します。
5. 再試行時のファイル処理が不適切なため、検証を通過したファイルの内容が、攻撃者の用意した内容で上書きされます。
6. APT は検証済みとして扱ったファイルをインストールし、実際には攻撃者のパッケージが展開されます。

CVE レコードの CWE に TOCTOU（検査時と使用時の不一致）が含まれているのは、この「検証した時点のファイル」と「使用する時点のファイル」がずれる構造を示しています。Debian Package Tracker の apt 3.0.4 の変更履歴では、CVE-2026-109518 の修正として「methods/*.cc: Open target files exclusively」が記載されています。ダウンロード処理が、ダウンロード先のファイルを排他的に開くよう変更されています。

root 権限でのコード実行につながる理由

.deb パッケージには、インストール時に実行されるメンテナースクリプト（preinst、postinst など）を含めることができます。APT と dpkg は root 権限で動作するため、攻撃者のパッケージがインストールされると、そのスクリプトも root 権限で実行されます。Canonical の解説でも、この経路でシステム全体の侵害につながると説明されています。

攻撃成立条件の整理

この脆弱性は、インターネット上の Debian サーバーへ外部から無条件に攻撃できるものではありません。次の条件がすべてそろう必要があります。

攻撃者が通信を操作できる立場には、同一ネットワーク上の中間者だけでなく、侵害されたミラーやキャッシュプロキシーも含まれます。社内ミラーや CI 用のキャッシュプロキシーを HTTP で利用している構成では、その運用主体と保護状態が評価の対象になります。

HTTPS と APT の署名検証、修正版の違い

HTTPS、APT の署名・ハッシュ検証、APT の修正版は、それぞれ防ぐ対象が異なります。どれか 1 つで他を代替できるものではありません。

参考: Canonical（Ubuntu Blog）
“The use of TLS via HTTPS protects against this vulnerability”
（HTTPS による TLS の利用は、この脆弱性に対する防御になる）
https://ubuntu.com/blog/apt-vulnerability-fixes-available

Canonical は同じ記事で、修正後の HTTPS 化は将来に向けた予防策であり、署名による検証のほうが配布元からのエンドツーエンドの保護として強固であるとも説明しています。HTTPS の利用は更新を安全に行うための緩和策であり、apt の更新を不要にするものではありません。また、HTTP を使っていることだけで攻撃が成立するわけでも、APT の署名検証が無意味になったわけでもありません。

HTTPS の効果は、TLS が終端する位置に左右されます。TLS を復号するプロキシーや社内ミラーを経由している場合、その先の区間が HTTP であれば、プロキシーやミラー自体が「通信を操作できる立場」になり得ます。設定ファイル上の URI だけでなく、実際にどこで TLS が終端しているかを確認してください。

自社環境が影響を受けるかの確認手順

ここで紹介するコマンドは、いずれも設定やパッケージを変更しない確認用のものです。APT のコマンドと設定は、Debian 13 trixie の公式マニュアル（apt-cache(8)、apt-config(8)、apt.conf(5)、apt-transport-http(1)）に基づいています。Debian 12 bookworm では、同じマニュアルの bookworm 版で確認してください。筆者の実機での検証結果ではないため、出力形式は環境によって異なる場合があります。

cat /etc/os-release
apt-cache policy apt

grep -rhE '^\s*(deb |URIs:)' /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null
apt-config dump | grep -i proxy

apt-config dump | grep -i retries
grep -rn -i retries /etc/apt/apt.conf /etc/apt/apt.conf.d/ 2>/dev/null

grep -rn -E '\bapt(-get)?\b' --include='Dockerfile*' --include='*.sh' .
docker run --rm --entrypoint "" IMAGE:TAG dpkg-query -W -f='${Version}\n' apt

APT を安全に更新する手順と適用後の確認

脆弱な apt で修正版の apt を取得する段階にもリスクが残るため、更新時は通信経路と再試行の扱いに注意します。この章の手順は、パッケージや設定を変更します。

更新時の暫定緩和策

更新時に利用できる緩和策は 2 つです。どちらも恒久的な修正ではなく、修正版の apt を適用するまでのリスク低減を目的とします。

Acquire::Retries=0 の一時指定

CVE レコードは 0 以外の再試行設定を攻撃条件としているため、更新コマンドに -o Acquire::Retries=0 を付けると、この条件を満たさなくなります。Canonical も、更新中に一時的に 0 とすることを緩和策として示しています。一方で、再試行されないため、ネットワークが不安定な環境では更新が失敗しやすくなります。

HTTPS による取得

APT ソースの URI を https:// に変更すると、経路上の HTTP 操作を防げます。利用しているミラーが HTTPS に対応していない場合は apt-get update がエラーになるため、変更後にエラーの有無を確認します。Canonical が示している sed による一括置換は Ubuntu のアーカイブ向けであり、Debian の環境へそのまま適用しないでください。

Debian サーバーとコンテナの更新手順

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

apt-cache policy apt

docker build --pull --no-cache -t IMAGE:TAG .

RUN apt-get -o Acquire::Retries=0 update \
 && apt-get -o Acquire::Retries=0 install -y --only-upgrade apt

更新前にインストールしたパッケージが改ざんされていないかを確認したい場合は、HTTP 経由かつ管理外のネットワークで行った更新を /var/log/apt/history.log から洗い出し、優先して調査対象にすることをおすすめします。

まとめ

CVE-2026-109518 は、APT の署名・ハッシュ検証を通過したパッケージが、HTTP リダイレクトと再試行の処理によって置き換えられ得る脆弱性です。攻撃には通信を操作できる立場が必要ですが、Debian 12 以降は既定で再試行が有効なため、apt の更新とコンテナイメージの棚卸しを優先して進めることを推奨します。

• Debian 13 は apt 3.0.4、Debian 12 は apt 2.6.2 で修正済み
• 攻撃には HTTP 通信の操作と再試行の有効化が必要です。
• 検証後のファイル置換が問題で、署名検証の仕組み自体は有効です。
• HTTPS は緩和策であり、apt の更新を不要にするものではありません。
• 更新時は Acquire::Retries=0 の一時指定がリスク低減につながります。
• コンテナイメージと CI のベースイメージは個別の更新が必要です。

以上、最後までお読みいただきありがとうございました。