Python のレガシー・パッケージに潜む脆弱性：放棄されたドメインとブートストラップ・スクリプト

Legacy Python Package Vulnerabilities Enable PyPI Attacks Through Domain Takeover

2025/11/27 gbhackers — Python のレガシー・パッケージに潜む脆弱性について、ReversingLabs の研究者たちが警鐘を鳴らしている。この脆弱性は、Python Package Index (PyPI) のユーザーを、ドメイン侵害によるサプライチェーン攻撃の脅威にさらすものである。それらの脆弱なコードは、最近のプロジェクトではほとんど使用されていないが、古い本番システムに残り続けているため、依然としてリスクは消え去っていない。

この調査で用いられた RL Spectra Assure コミュニティ提供の機械学習モデルは、既知のマルウェアに類似したパッケージの動作を検知するようにトレーニングされており、複数の PyPI パッケージで配布されている危険なブートストラップ・ファイルにフラグを付けるものである。

それらのレガシー・スクリプトは、Python の依存関係を取得し、インストールを自動化してきた。今回のケースでは、長期間にわたって使用されていない distribute パッケージのインストーラーが、”python-distribute.org” ドメインから直接取得されている。

重要なことは、このドメインが Python コミュニティにより管理されなくなり、広告収入を目的として売りに出されている点である。したがって、このドメインを攻撃者が購入すると、影響を受けるブートストラップ・ファイルを実行している開発者に対して、悪意のスクリプトが配信される可能性が生じる。

過去と現在において、それらのスクリプトと関連する人気パッケージとして挙げられるものには、Tornado (非同期ネットワーク)／pypiserver (プライベート PyPI サーバ)／slapos.core (分散 OS オーバーレイ)／roman (数値変換)／xlutils (Excel ファイル編集)／testfixtures (ユニットテスト) などがある。

pypiserver のように、最近になってスクリプトが削除されたパッケージもあれば、Makefile などのように、自動化ファイルにスクリプトの痕跡が残っているパッケージもある。ユーザーやビルド・システムが、レガシーなブートストラップ・ルーチンを実行した場合にのみ発生する危険性が、いまも残っていることになる。

Python パッケージの問題の根源

ReversingLabs のレポートによると、パッケージ化と依存関係の解決は、オープンソースである Python の開発の中心として存在してきた。

初期の Python は distutils (現在は Python 3.12 で削除) を提供していたが、その機能がニーズに追いつかなくなり、代替として setuptools などのツールが登場した。開発上の論争により、setuptools からのフォークとして distribute が生まれたが、2013 年には再び統合された。

その一方で、distutils2 による近代化の試みと、その後の放棄などもあり、エコシステムでは複数のソリューションが複雑に絡み合い、それぞれが互換性を維持しようとし、そして時には失敗する状態になった。

その結果として、インストールを容易にするためのブートストラップ・スクリプトが急増し、依存関係を取得するための URL を、ハードコーディングするという形態が生じてきた。

コミュニティによる監視やタイムリーな移行が行われなかったことで、最終的に “python-distribute.org” ドメインは失効した。2014 年以降において、このドメインは無断で取得され、その使用状況や所有権を公式に監視する者は誰もいない。

ドメインの乗っ取りは既知の攻撃ベクターである。2023年には、npm パッケージ fsevents が同様の手口の標的となり、深刻なインシデントに至った。そのときの攻撃者は、バージョン 1.0.0 〜 1.2.11 でハードコードされていた、すでに失効していたクラウド・ドメインを登録し、そこから悪意のペイロードを配信した。この脆弱性は、CVE-2023-45311 として文書化されている。

RL Spectra Assure の研究者たちが示す Python 悪用のシナリオが、slapos.core のブートストラップ・スクリプトを標的とする PoC エクスプロイトとして提供されている。

いまの PyPI における大半の開発者は、より安全なデフォルトとして認識される setuptools に移行しているが、脆弱なパターンの残骸も依然として広く流通している。つまり、古いドメインが悪意のある者の手に渡った場合には、現実的なリスクがもたらされる可能性がある。

より広範なサプライチェーンリスク

オープンソース・モデルはコード共有により成り立っているが、この事例が示すように、ハードコードされたドメインは依然として隠れた落とし穴である。

Python モジュール imp は、何らかのソースをモジュールとしてロードするために使用されるものだ。Python 実行時に “-d” フラグを設定すると、ブートストラップ・スクリプトが distribute を使用するようになる。

古い依存関係やツールのサポートが終了した際に、関連するインフラの適切な廃止／移行が行われないと、ユーザーは気付かないうちに深刻な脅威にさらされることになる。

PyPI に関して、現時点で “python-distribute.org” の悪用は実証されていないが、攻撃者がサプライチェーンを悪用する機会を狙うことは、過去の事例から明らかであり、特に警戒が必要である。

レガシー・コードと放棄されたインフラは、常にソフトウェア・サプライチェーンに危険をもたらす。

オープンソースのメンテナとユーザーは、ドメイン侵害攻撃を防ぐために、古くなったドメインとブートストラップ・ルーチンの依存関係を定期的に監査し、非推奨とされるプラクティスからの移行を積極的に進めるべきだ。

現代のエコシステムを悩ませているレガシー・コードの亡霊から身を守る上で、”python-distribute.org” のエピソードは、すべての開発者に行動を促す警告となる。

Indicators of Compromise (IoCs) 

Package Name	Version Range
pypiserver	>=1.1.1, <2.4.0
slapos.core	>=0, <=1.19.0
roman	>=2.0.0, <3.2
xlutils	>=1.6.0, <2.0.0
testfixtures	>=2.3.4, <3.0.2
imio-pm-locales	>=4.1.18.1, <4.2.20
pyquery	>=1.2.10, <2.0.0

Python の古いパッケージに残されたブートストラップ・スクリプトが、失効したドメインへの依存を続けていることが、深刻な問題を生み出します。つまり、管理されなくなったドメインを攻撃者が取得すると、そこから悪意のコードが配信される仕組みが成り立ちます。依存関係をハードコードしていた過去の設計や、移行が進まなかった経緯が重なって、現在もリスクが残っていると、この記事は指摘しています。ご利用のチームは、ご注意ください。よろしければ、Python での検索結果も、ご参照ください。