自己伝播型マルウェア・ワーム型攻撃事例
Pythonのpip/PyPIでは、npmの「Shai-Hulud」のような完全自動で拡散するワーム型攻撃は大規模には報告されていません。しかし、攻撃者はPyPI上でマルウェアを巧妙に配置し、感染を広げようとしています。例えばPhylumが2023年5月に報告した事例では、攻撃者Patrick Pogodaが多数のGitHubリポジトリにマルウェア依存関係を配置し、同じマルウェアを含むPyPIパッケージ（例：「pycoloringsaddition」）を繰り返しアップロード・削除していました。PyPI側でパッケージが削除されると、数分以内にわずか名義を変えた新パッケージ（「syscolouringlibary」など）を公開し、自身のリポジトリを一斉に更新して参照先を切り替え、感染を持続させていましたblog.phylum.ioblog.phylum.io。このようにパッケージ名のわずかな変更と自動化でマルウェアを「復活」させる手口が確認されています。
-
代表例：「pycoloringsaddition」→「syscolouringlibary」等（2023年5月、作者が自動的に新パッケージを公開し依存先を差し替え）blog.phylum.ioblog.phylum.io。
-
方法：setup.pyや初期化スクリプトに暗号化された悪性ペイロードを埋め込み、インストール時にユーザーのGitHubトークンや暗号ウォレット情報などを窃取。
-
その他のワーム型攻撃：npm環境のShai-Hulud攻撃が有名ですが、現時点でPyPIに同等規模の攻撃は観測されていません。ただしGitHub Actionsを悪用した大規模トークン窃取（GhostAction）はPyPI側にも波及しました（後述）。
トークン・クラウド認証情報を狙うPyPIパッケージ
PyPIには、インストールした環境から機密情報を窃取する悪意あるパッケージがいくつか見つかっています。著名な例としてはTyposquatting攻撃の一環で、人気パッケージを偽装した「fabrice」（fabricのスペルミス）があります。Socketの調査によれば、この「fabrice」は2021年3月に公開され、数万人にダウンロードされながらAWSアクセスキーとシークレットキーをboto3経由で収集し、攻撃者サーバーへ送信していましたthehackernews.com。Linux版ではシェルスクリプト、Windows版ではVisualBasicスクリプト＋Pythonスクリプトでペイロードを実行し、最終的にAWS認証情報を盗み出す仕組みです。Hacker Newsの報道では、「fabrice」がFabric（SSH実行ツール）の偽物であると解説されていますthehackernews.comthehackernews.com。
GitHub上のCI/CD環境などから窃取された秘密情報の内訳例。2025年9月に明らかになった「GhostAction」攻撃では、プロジェクトのGitHub Actions環境からPyPIトークンやAWSキーを含む3,325件以上のシークレットが漏洩し、その中にはDockerHubやGitHubのトークン、Cloudflareキーなども含まれていましたbleepingcomputer.com。
また、GitHub Actionsのワークフローを改竄してPyPIトークンを盗む「GhostAction」キャンペーン（2025年9月発覚）では、数百のリポジトリが改竄され、PyPIとnpmのトークンが攻撃者のサーバーに送信されましたbleepingcomputer.comblog.pypi.org。PyPI管理者は発覚後に影響トークンを全て失効させ、悪用された形跡は確認されませんでしたbleepingcomputer.comblog.pypi.org。なお、環境変数に機密情報を含む一般のプロジェクトからは、開発者のミスでGitHub PATが流出したケース（PyPI管理者アカウントのPATがコンテナ画像内に残存した事例）も報告されていますblog.pypi.orgblog.pypi.org。
PyPI/pipのセキュリティ機構（署名、検出、報告体制）
PyPIとpipは近年、サプライチェーン攻撃に対抗するための対策を強化しています。まず、アカウント認証面では、2023年までにPyPI上のメンテナー全員に2要素認証（2FA）の義務付けが発表されましたblog.pypi.org。PyPIはパッケージ公開にパスワードの代わりにAPIトークン（認証トークン）を用いる方式を採用し、最も重要なプロジェクトは2FAで保護されていますblog.pypi.org。さらにGitHub ActionsからPyPIへ公開する場合は、「Trusted Publishers（短命かつ限定範囲のトークン）」の利用を推奨するなど、トークン盗難リスク軽減策を提供していますblog.pypi.org。
ダウンロード時の検証機構としては、PEP 458/480で提案されたTUF（Update Framework）によるメタデータ署名も構想されていますが、現時点でPyPIでの導入は進行中です。署名ベースの配布（例：パッケージごとのGPG署名）は公式には廃止されました（削除の議論がPythonコミュニティで行われています）が、PSFは2FAとAPIトークンでアカウントの安全性を担保し、「信頼できるパブリッシャー」制度で公開権限を分離する方針ですpeps.python.orgblog.pypi.org。
不正検出・報告体制では、PyPI運営はセキュリティ研究者からの報告を積極的に受け付けています。Webインターフェースに「プロジェクトをマルウェアとして報告」ボタンが追加され、発見者は問題箇所（ファイル・コード）を指定して報告できますblog.pypi.org。また、API経由の報告機能も試験中であり、報告されたパッケージはPSF管理者が数日以内に審査・削除していますblog.pypi.org。加えて、pipコマンドには依存関係スキャンツール（例：pip-auditやsafety）を併用して既知の脆弱性を検査する運用が推奨されるなど、インストール前後の自動検査によるセキュリティ強化策も広まりつつあります。
DjangoなどWebアプリ関連パッケージのセキュリティ懸念
Webフレームワーク（Django, Flask など）やその周辺ライブラリは開発者が多く利用するため、攻撃者からの標的になりやすいです。たとえば、SC Mediaによれば、Jinja2/Djangoで使われる正規のテンプレートライブラリ「Coffin」を騙った悪意あるパッケージ（例：Coffin-Codes-Pro, Coffin-Codes-2022）が発見されており、これらはインストール時にGmailを経由して情報を盗み出し、WebSocketで不正操作を行う仕組みになっていましたscworld.com。また、脆弱性とは別ですが「Django-Mailer」の偽物「django-mail」や「django-mail」へのタイポスクワットを想定した攻撃可能性も指摘されており、開発者は依存パッケージの名称を慎重に確認する必要がありますbolster.ai。
最近の攻撃例としては、Zscalerが2025年8月に報告した2つの悪意あるパッケージ sisaws および secmeasure（共にサードパーティ製の文字列操作系ライブラリと偽装）が挙げられます。これらはTyposquatting的な名前ではないものの、初期化時にPasteBinからPythonスクリプトをダウンロードし、Windows環境でSilentSyncというRAT（リモートアクセス型マルウェア）を展開しますzscaler.comscworld.com。図示すると次のように、sisaws と secmeasure はメンテナー情報やパッケージ名が酷似しており（下図参照）、両者から同一の不正スクリプトが実行されます。どちらも既にPyPIから削除されていますが、Djangoに限らず**「必ずしもメジャー名ではなくても、一般的な機能名や用語を使った偽装パッケージ」に注意**が必要ですzscaler.comscworld.com。
Zscaler調査による悪性PyPIパッケージ sisaws（左）と secmeasure（右）のメタデータ比較例zscaler.comscworld.com。両者は異なる名前ながら同一人物が管理し、初期化時に同様の悪意あるコードを実行していました。
pip install・CI/CDパイプライン経由の感染リスクと対策
pip installは基本的に任意のパッケージのインストール時にsetupスクリプトを実行するため、攻撃者がsetup.pyやpyproject.toml内に悪意あるコードを書いていれば、任意コードが起動するリスクがあります。特にCI/CD環境での自動インストールでは、権限が高いとシステム全体が危険にさらされます。対策としては、以下が挙げられます：
-
仮想環境（venv/container）の利用：プロジェクトごとにPython仮想環境やコンテナを使い、ホスト環境への影響を分離する。
-
権限の最小化：CI/CDランナーやビルドサーバーではrootや高権限ユーザーで実行しない、ネットワークアクセスを制限するなど、侵害影響を局所化する。
-
依存関係の固定化：
requirements.txtやpoetry.lock、pip-toolsなどでバージョンを固定し、浮動バージョンやワイルドカードを避ける。これにより、同名の悪意ある新バージョンが勝手に取り込まれるリスクを減らす。 -
ハッシュ検証：
pip install --require-hashesを使い、インストール時にパッケージのハッシュをチェックする。未知のパッケージや改竄版は拒否される。 -
依存性スキャンと監査：
pip-auditやOSSセキュリティ製品で依存パッケージの脆弱性スキャンをCIに組み込む（サプライチェーン脅威検出）。 -
プライベートミラー・ミラーリング：社内PyPIミラーやインターネットフィルタで信頼されたパッケージソースのみを利用する。
-
CIの監査ログ：ビルドで実行されたpipコマンドやワークフローのログを監査・保管し、不審な動作の検知に備える。
加えて、PyPIへの依存公開には**「Trusted Publisher」（GitHubが提供する短命トークン）を使い、長期無効化しにくいトークンの使用を避けることが推奨されていますblog.pypi.org。さらに、ソフトウェアのサプライチェーン防御策として、攻撃者の侵入経路をモデル化し、依存ライブラリの第三者レビューや必要最低限の依存のみを選択するなどの脅威モデリング**も有効です。
まとめ
以上のように、Pythonエコシステムでも過去にTyposquatting型マルウェア（“fabrice”など）やワークフロー改竄によるトークン窃取（GhostAction）、巧妙化するパッケージレスキュー（復活）攻撃（Phylum報告）など多様な事例が報告されていますthehackernews.comblog.phylum.iobleepingcomputer.com。PyPI/pipのセキュリティ対策も強化されており、2FA義務化やAPIトークン化、報告ボタンの導入などが進められていますblog.pypi.orgblog.pypi.org。それでも、パッケージ管理では常に**「インストール前に公式性を確認し、インストール中に未知のネットワーク通信がないか注意し、定期的に環境を監査する」**といった基本対策が重要です。特にWebアプリケーションでは、広く使われるライブラリを介した攻撃（例：テンプレートエンジンや認証周りのライブラリ）にも警戒し、必要な最小限のパッケージに絞ることがリスク低減につながります。
参考資料: さまざまなセキュリティ研究者報告やメディア記事scworld.comthehackernews.comblog.pypi.orgblog.pypi.orgblog.pypi.orgを基にまとめました。各事例では発見時期・パッケージ名・手口・対処状況など具体的に報告されており、最新の脅威動向の把握に役立ちます。
