pipに脆弱性、閉域網へのパッケージ持込が直撃

Python のパッケージインストーラ pip に、ディスク上の任意の場所へファイルを書き込まれる絶対パストラバーサルの脆弱性（CVE-2026-13346）が公表されました。修正版は pip 26.2（2026年7月29日公開）です。

悪用には「悪意のあるパッケージインデックス」からの取得が必要で、悪性パッケージ単体では成立しません。ただし公式アナウンスは、実質的に影響を受けるのは pip download を --only-binary 付きで実行するケースだと名指ししています。これは閉域網へパッケージをまとめて持ち込むときの定番手順そのものです。「開発部門の話」で片付けると、自社の持ち込み手順書が該当していた、という形で刺さります。

この記事でわかること

CVE-2026-13346 の中身と、悪用に必要な条件
「悪意のあるインデックス」を社内環境に読み替えると、どこが該当するのか
2026年に3件続いた pip のパストラバーサルの構造
情シスとして今すぐ確認・是正すべきこと

pipとは何か——「うちはPython開発をしていない」が通じない理由
何が起きたのか（CVE-2026-13346）
1. 「悪意のあるインデックス」が前提とは、どういう意味か
なぜ pip download --only-binary が名指しされたのか
2026年、pip のパストラバーサルはこれで3件目
現場目線の課題——pip はバージョン管理の網から漏れる
情シスはどうすべきか
まとめ
出典

pipとは何か——「うちはPython開発をしていない」が通じない理由

pip とは、Python のパッケージ（ライブラリやツール）をリポジトリから取得してインストールするための、公式のインストーラです。開発者が pip install requests のように実行する、あのコマンドを指します。

問題は、pip が「入れた覚えがなくても入っている」ソフトウェアだという点です。Python 公式ドキュメントによれば、Python 3.4 以降は ensurepip という仕組みにより、CPython のメンテナンスリリース・機能リリースに pip の最新安定版がバンドルされています。Python が入っている端末やサーバには、原則として pip も同梱されています。仮想環境（venv）を作れば、そこにも展開されます。

結果として、運用スクリプト用に Python を入れたサーバ、CI/CD のビルド用 Docker イメージ、データ分析用に配った業務端末など、「Python 開発環境として台帳に載っていない」場所にも pip は存在します。推測で判断せず、実機で確認してください。バージョンが 26.2 未満なら対象です。

バージョン確認: python -m pip --version（python3 -m pip --version の環境もあり）
実体の所在: Windows は where pip、Linux/macOS は which -a pip pip3
venv を多用している場合、親の Python を上げても各 venv 内の pip は古いまま残ります

何が起きたのか（CVE-2026-13346）

pip が、パッケージインデックスから返された二重にエンコードされたパッケージURLを誤って処理していました。リンクからファイル名を決める処理でURLパスを2回デコードしてしまうため、本来通らないはずのパス表現が通り、wheel（ビルド済み配布物）のインストール時であっても任意の場所にファイルが置かれ得ます。公式アナウンスの原文は次の通りです。

pip would incorrectly handle doubly-encoded package URLs from indexes allowing for files to be installed to arbitrary locations on disk even when installing wheels.

項目	内容
CVE番号	CVE-2026-13346（CWE-36 絶対パストラバーサル）
影響を受けるバージョン	pip 26.2 より前のすべて
修正版	pip 26.2（2026年7月29日公開）。最新は 26.2.1（2026年8月4日）
深刻度	CVSS v4.0: 5.6（中）／AV:N/AC:H/AT:P/PR:H/UI:A/VC:N/VI:H/VA:N。JVN iPedia は CVSS v3 基準値 6.5 と評価
公表日	2026年7月29日（oss-security / Python security-announce）
修正内容	ファイル名決定時にURLパスを二重デコードしないよう修正（pypa/pip PR #14110）

CVSS v4 のベクタは AC:H（攻撃条件が高い）、AT:P（前提条件が必要）、UI:A（利用者の能動的な操作が必要）が並び、緊急パッチを当てて回るクラスではありません。注意すべきはスコアではなく、影響条件が特定の運用手順とぴったり噛み合っている点です。

「悪意のあるインデックス」が前提とは、どういう意味か

答え: 細工した wheel を公開リポジトリに置くだけでは成立せず、pip が問い合わせる「インデックス側の応答」を攻撃者が操作できる必要がある、という意味です。脆弱性の入り口が、パッケージの中身ではなくインデックスが返すURLだからです。

ただし「PyPI 公式を使っているから関係ない」と読むのは早計です。実務では pip とパッケージ提供元の間に自社の資産が挟まっています。

社内プライベートPyPIミラー／リポジトリ管理製品（devpi、Nexus、Artifactory など）— --index-url で参照させていれば、それが「インデックス」です
キャッシュ用プロキシ・中継サーバ— 上流を透過する構成では、上流や経路の汚染が素通りします
設定で固定された参照先— pip.conf / pip.ini、環境変数 PIP_INDEX_URL、Dockerfile 内の指定。誰がいつ設定したか追えていないことがあります

つまりこの条件は外部の攻撃者専用ではなく、社内ミラーが侵害された場合や、設定ミスで意図しない参照先を向いていた場合にも成立し得ます。配布経路そのものを差し替える攻撃は現実に起きており、当サイトでも配布版がすり替えられた事例を取り上げました。

なぜ pip download --only-binary が名指しされたのか

理由は消去法です。信頼できないインデックスからソース配布物（sdist）を入れる行為は、インストール時にビルドスクリプトが実行されるため元々危険で、この脆弱性の有無にかかわらず安全ではありません。だから「wheel だけに限定していれば安全なはず」という前提が崩れるケースこそが要点だ、という整理です。

そして pip download --only-binary=:all: は、閉域網・オフライン環境へパッケージを持ち込む手順の定番です。インターネットに出られる作業端末で依存関係をまとめて取得し、媒体やファイル授受サーバ経由で内部へ運ぶ——工場系ネットワーク、金融、自治体、医療などで広く使われています。

この手順が該当するとどうなるか。影響を受けるのは、まだ「内部に入れる前の作業端末」です。持ち込みチェックの目線は通常「持ち込むファイルが安全か」に向いており、ダウンロード作業そのものが端末を汚すというシナリオは手順書の想定外になりがちです。開発・運用担当の端末が起点として狙われる構図は、Ray の脆弱性が悪用された事例とも重なります。

2026年、pip のパストラバーサルはこれで3件目

CVE	概要	影響／修正
CVE-2026-1703	細工された wheel の展開時に、インストール先ディレクトリの外へファイルが展開され得る（プレフィックス配下に限定）	26.0 未満／pip 26.0で修正（CVSS v4: 2.0）
CVE-2026-8643	wheel メタデータの entry point 名に `../` や絶対パスを使い、scripts ディレクトリ外へスクリプトを生成・上書きできる	26.0.1 で確認／Red Hat は上流修正版を「未特定」とし RHSA を発行（Important 相当）
CVE-2026-13346	インデックスからの二重エンコードURLの処理誤りにより、任意の場所へファイルが置かれ得る	26.2 未満／pip 26.2で修正（CVSS v4: 5.6）

3件に共通するのは、pip が外から受け取った文字列（ファイル名・URL・メタデータ）を書き込み先パスの決定に使っているという構造です。入り口は違っても、結果は同じ「任意の場所へのファイル書き込み」で、上書き先が起動時に読まれるスクリプトや設定ファイルであればコード実行に発展し得ます。なお CVE-2026-8643 は上流の修正版が明示されていないため、ディストリ提供の pip を使う環境ではOSベンダーの更新情報を基準に判断してください。

現場目線の課題——pip はバージョン管理の網から漏れる

正直なところ、pip のバージョンを継続的に把握できている組織は多くないはずです。pip は「製品」として認識されていないからです。Python のバージョンは資産管理で追っていても、その中の pip を台帳の項目に持つ組織はまれで、脆弱性情報が流れてきても引く先がありません。

しかもバージョンは場所ごとにバラバラになります。OS標準の pip、pyenv で入れた Python の pip、venv ごとの pip、Docker イメージに焼き込まれた pip。同じサーバ内で複数バージョンが同居し、片方だけ更新済み——が普通に起きます。「Python を上げたから大丈夫」は通用しません。

そして一番もどかしいのが、作業端末に目が届きにくいことです。「インターネットに出られる端末で取得して持ち込む」運用は現場担当者の裁量で回っていることが多く、pip のバージョンまで管理下に置けているケースは少数派でしょう。閉域網への持ち込み手順書自体、一度作られると数年見直されません。限られた人員で全端末の細部まで追うのは現実的ではない、という前提から出発せざるを得ないのが実情です。

情シスはどうすべきか

自前で長いチェックリストを作るより、まず次の3点に絞るのが現実的です。

pip を 26.2 以降にする。python -m pip install --upgrade pip で更新できます。ディストリ提供の pip は OSベンダーの更新に従ってください。CI/CD の Docker イメージは、ベースイメージ更新かビルド時の pip 更新で確実に反映させます。
インデックスの参照先を棚卸しする。pip config list、pip.conf / pip.ini、環境変数 PIP_INDEX_URL、Dockerfile・CI 設定の --index-url / --extra-index-url を洗い出し、「誰が管理するどのサーバを向いているか」を1枚にまとめます。今回の入り口はここです。
閉域網への持ち込み手順書を読み直す。pip download --only-binary が書かれているなら、その作業端末の pip バージョンを確認対象に加えます。

中長期的には、こうした「台帳に載らない部品」を継続的に把握する仕組みが要ります。経済産業省は「ソフトウェア管理に向けたSBOMの導入に関する手引 ver2.0」を公開しており、部品構成の把握と脆弱性管理の回し方が実務ベースで整理されています（経済産業省の公表ページ）。体制づくりから始めたい場合は、IPA の中小企業の情報セキュリティ対策ガイドラインが型を示してくれます。あわせて、「出所の分からないインデックスURLを手順書にコピペしない」といった行動はツールでは止めきれないので、IPA の対策のしおりのような教材で開発・運用担当にも定期的に触れてもらうのが結局は近道です。

まとめ

pip 26.2 未満は CVE-2026-13346 の対象。インデックスからの二重エンコードURLの処理誤りで、wheel インストール時でも任意の場所にファイルが置かれ得ます。修正版は pip 26.2。
実質的な影響は pip download --only-binary に集中する。閉域網へのパッケージ持ち込み手順が該当しやすく、影響を受けるのは持ち込む前の作業端末です。
2026年で3件目という構造を見る。pip を「バージョン管理対象の部品」として台帳に載せ、インデックス参照先の棚卸しとセットで進めるのが実効的です。