2026年、Python パッケージセキュリティが直面する課題

2026年3月24日、AIアプリケーションの構築にLiteLLM（月間ダウンロード数9,500万件を誇るPythonパッケージ）を使用していた開発者たちは、知らぬ間に悪意あるコードをインストールしていました。TeamPCPという名の脅威アクターグループがPyPIの配布パイプラインを侵害し、悪意あるバージョン1.82.7および1.82.8をパッケージインデックスに送り込んでいたのです。その手口は巧妙でした。使われたのは.pthファイルという、Pythonインタープリタの起動のたびにコードを自動実行させる、あまり知られていない仕組みです。侵害された2つのバージョンのいずれかをインストールした場合、明示的なインポートを行わなくても悪意あるコードが密かに実行されてしまいました。

これはもはや例外ではありません。一つのパターンとなっているのです。

実際に何が起きているのか

ReversingLabsの報告によると、2026年には悪意あるオープンソースパッケージが73%増加しました。LiteLLMへの攻撃は、TeamPCPによるより広範なキャンペーンの一環でした。同グループはAqua SecurityのTrivyやCheckmarxのKICSなど、広く信頼されているオープンソースのセキュリティツールを組織的に侵害した後、PyPIでホストされているAIインフラストラクチャ用ライブラリへと標的を移していきました。

LiteLLMに対する攻撃の流れは、今や見慣れたパターンをたどっていました。TeamPCPはメンテナーのPyPI公開用認証情報を入手すると、公式パッケージとほとんど見分けがつかない悪意あるバージョンを送り込み、AWS、GCP、Azureの各トークン、SSH鍵、クラウドアカウントの認証情報といった価値の高い機密情報を窃取するよう設計された多段階のペイロードを埋め込みました。Zscaler ThreatLabzによると、この汚染されたパッケージが隔離されるまでに公開されていた時間はおよそ3時間でした。しかしその3時間だけで、数万に及ぶ企業環境に到達するには十分だったのです。

そして被害はLiteLLMだけにとどまりませんでした。2026年4月下旬には、PyTorch Lightningのバージョン2.6.2および2.6.3に、インポート時に実行される認証情報窃取マルウェアが仕込まれていたことが判明しました。たった一つの悪意あるワークフローファイルによって、CI/CDパイプライン全体の機密情報が露出してしまったのです。

AI開発環境がとりわけ狙われやすい理由

サプライチェーン攻撃そのものが厄介な存在であることは言うまでもありません。しかし、AI開発環境を標的としたサプライチェーン攻撃は、それ以上に深刻です。

AI・ML環境では、開発、研究、クラウドインフラ、データアクセス、モデルの公開、自動化といった要素が同一のワークスペース内に混在しています。標準的なウェブアプリケーションであれば、Pythonパッケージが侵害されてもデータベースの認証情報が盗まれる程度で済むかもしれません。しかし同じ攻撃がAI開発環境で発生すれば、モデルの重み、学習データ、複数のクラウドプロバイダーにまたがるトークン、CI/CDパイプラインの機密情報、本番環境のAPIキーが、たった一つの感染した依存関係から同時に流出しかねないのです。

ほとんどのセキュリティチームが見落としているもう一つの側面があります。開発者がAIコーディングアシスタントを使ってコードを書く際、これらのアシスタントは特定のパッケージを参照するpip installコマンドやimport文を頻繁に提案します。開発者がその提案を信頼し、示されたパッケージ名をそのままインストールしてしまい、なおかつ攻撃者がすでにその名前で悪意あるパッケージを登録していた場合、攻撃者が開発者と直接やり取りすることなく攻撃は成立してしまいます。研究者たちはこの手法を「スロップスクワッティング」と名付けました。最近の研究では、約20万件のPythonプロンプトを調査した結果、主要なLLMのすべてがPyPI上に存在しない架空のパッケージ名を生成していることが判明しています。これは、個々のモデルのアップデートだけでは完全には解消できない、持続的な攻撃対象領域を生み出しています。

開発者たちは何も間違ったことをしているわけではありません。彼らはただ、生産性を高めてくれるツールを使っているだけです。問題は、そうしたツールの土台にあるセキュリティ前提そのものが崩れていることにあります。

今すぐ重要となる3つの対策

1. 依存関係をピン留めし、整合性を検証する

requests>=2.0のような可変バージョン指定子は、requests==2.31.0のような厳密な指定とは異なり、パッケージマネージャーが悪意あるコードを含む更新版を気付かぬうちに取り込むことを許してしまいます。AI開発環境内のすべての依存関係を厳密なバージョンにピン留めし、既知の正当なハッシュ値と照合してチェックサムを検証してください。この対策だけでも、LiteLLM攻撃による被害範囲を、明示的に侵害されたバージョンへとアップグレードした環境のみに限定でき、制約なしにpip install litellmを実行したあらゆる環境が被害を受ける事態は防げていたはずです。

2. 開発パイプライン内のインストール後フックを監査する

LiteLLMへの攻撃では、Pythonの.pthファイルという仕組みを使ってペイロードが埋め込まれていました。これは、いかなるimport文が実行されるよりも前に、インタープリタの初期化中に自動実行されるコードです。インストール後フックや.pthファイルの改ざんは、以前から知られている攻撃手法の一種ですが、開発者の環境における対策の徹底度合いにはばらつきがあります。インストール後スクリプトを含むパッケージについては、開発者のマシンに届く前にレビューを義務付けてください。SocketやSonatypeといったツールは、インストール前にPyPIパッケージの悪意ある挙動をリアルタイムで分析してくれます。これはあれば望ましいという程度のものではありません。AIツールの導入が進む速度を考えれば、基本的な対策として位置づけるべきものです。

3. 漏えいが疑われた場合は、直ちにクラウド認証情報をローテーションする

LiteLLMのペイロードがAWS、GCP、Azureの各トークンを狙って標的にしたのは、これらの認証情報がクラウド環境間の横展開を可能にするからにほかなりません。3月24日の露出期間中に開発パイプラインでLiteLLMを取得していた場合は、その環境からアクセス可能なすべてのクラウド認証情報を侵害された可能性があるものとして扱い、ローテーションを実施してください。また、クラウドプロバイダーの監査ログを確認し、開発者が意図的に発行したものとは合致しない活動パターンがないかを調べてください。それは、盗まれたトークンが別の場所にいる攻撃者によって使用されていることを示す痕跡です。

セキュリティチームへの示唆

TeamPCPによる一連のキャンペーンは、このパターンの終わりを意味するものではありません。むしろ、AIインフラストラクチャがひとつの標的カテゴリーとして成立することを証明した事例と言えます。LiteLLMやPyTorch Lightning、そしてその間に存在するさまざまなツールは、AIチームが日常的に依存しているパッケージです。攻撃者はそのことを熟知しています。開発者が迅速に動くこと、AIツールの導入がセキュリティレビューのサイクルを上回るペースで進んでいること、そして悪意ある.pthファイルがほとんどのエンドポイント検知製品にとって検知不能であることを、彼らは知っているのです。

上記の対策は、いずれも複雑なものではありません。新たなベンダーや新しいプラットフォームを必要とするものでもありません。求められているのは、AI開発環境におけるPythonパッケージのインストールを、本番環境へのデプロイと同じ厳格さで扱うことです。なぜなら2026年の今、開発者のローカル環境と本番インフラストラクチャとの距離は、これまでになく縮まっており、攻撃者もすでにそのことに気づいているからです。

開発者はツールを信頼しています。その信頼が正当なものであるかどうかを、確かめる必要があります。