PyPIのPyTorch Lightning 2.6.2/2.6.3に認証情報窃取の悪性コード、インポート時に自動実行です

今日の深掘りポイント

• 人気フレームワークの正規パッケージに悪性バージョンが混入し、importだけで開発者資格情報を抜かれる「静かな失血」が起きうる事案です。
• ML実験基盤やCIランナーはクラウド鍵やリポジトリトークンを抱えがちで、被害が一足飛びにサプライチェーン全体へ波及しやすいです。
• 供給側（レジストリ）防御だけでは限界があり、組織側で「依存関係の検証・署名・ネットワーク制御・鍵の短命化」を重ねがけする設計が現実解です。
• 依存更新の自動化は便利ですが、import時実行のような「実行時テストで初めて露見する」挙動に弱く、ネットワーク・DNS・eBPF観点のふるまい監視が差を生みます。
• 緊急対応は「該当バージョン除去→全秘密情報ローテーション→CI/CD・開発端末のネットワーク監査」を最優先に直列で回すのが肝要です。

はじめに

PyPIで配布されたPyTorch Lightningのバージョン2.6.2および2.6.3に、開発者の認証情報窃取を目的とする悪性コードが含まれていたことが判明しました。問題のコードはパッケージがインポートされた瞬間に自動で動き出すため、開発者は「単に依存関係を更新してテストを走らせただけ」で鍵やトークンを抜かれるリスクがありました。MLワークロードが動くGPUノードやCIランナーは、クラウドAPIキー・Gitトークン・SSH鍵など「価値の高い資格情報」が同居しやすく、侵害時の二次被害が大きくなりがちです。

本件は、サプライチェーン攻撃としての新奇性よりも、「浸透度の高い依存に対して即応が必要」な現場性の高さに重心があります。攻撃の成立確度も高そうで、組織としての行動可能性が十分にあるため、今日のうちに手を打てる設計に落とし込むことが重要です。本稿では確認済みの事実と、SOC運用・開発基盤運用に効く示唆を切り分けてお届けします。

参考: Sonatypeが今回の不正配布を調査・公表しています。詳細は同社の分析に基づきます。

• Sonatype: Malicious PyTorch Lightning packages found on PyPI（2026-05-01）
  https://www.sonatype.com/blog/malicious-pytorch-lightning-packages-found-on-pypi

深掘り詳細

事実関係（確認済み）

• 2026年4月30日、PyPI上で配布されたPyTorch Lightningのバージョン2.6.2および2.6.3に悪性コードが含まれていたことが報告されていますです。
• 悪性コードは「パッケージのインポートを契機」に自動実行され、開発者の認証情報を窃取する目的で作られていましたです。
• 供給網の信頼を逆手に取る手口であり、開発者・組織の環境に重大なリスクをもたらしますです。
• 以上はSonatypeの公開分析に基づく確認情報です（上記リンク参照）です。

注記: 本件が「正規メンテナのアカウント乗っ取り」かどうかは、一次情報としての明示が本稿時点では限定的であるため、編集部としては断定を避けます。配布アカウントの不正利用である可能性は十分に考えられますが、ここでは仮説として扱いますです。

見えてきた示唆（編集部のインサイト）

• import時実行は「インストール時の安全対策」をすり抜けやすいです。多くの組織がsetupスクリプト実行やビルドステップの安全化には投資していますが、テストや実行フェーズでの無害性検証やネットワーク制御は手薄になりがちです。今回の事例はその盲点を正確に突いていますです。
• ML/データ基盤は「鍵が同居」しやすいです。GPUノードやノートブック、実験トラッキング、分散トレーニングの制御面では、クラウド長期鍵、OIDCトークン、モデルレジストリのAPIキー、リポジトリPATが同一ワークロード上で利用されがちです。ひとつのimportで横断的に吸い上げられると、機密性・可用性への影響が連鎖的になりますです。
• レジストリ依存の「善意モデル」から「検証前提モデル」への移行が不可避です。どれほどレジストリ側が強化されても、短時間の侵入・汚染をゼロにするのは非現実的です。組織側で「依存ピン留め＋ハッシュ固定＋署名・アテステーション検証＋ネットワーク最小化＋鍵の短命化」をセットで回す設計が標準になっていくはずです。
• メトリクス観点では、直ちに対応すべき切迫性と、実運用に落とし込める具体策の多さが両立している案件です。新奇性で驚くよりも、今いる自分たちのCI/MLジョブで「インポート時に外へ出られる経路が残っていないか」を点検するのが合理的です。

攻撃手口の文脈（一般化と仮説）

以下は一般的に観測されるPyPI悪性パッケージの手口に基づく仮説であり、本件での全容を断定するものではありませんです。

• import時または初回ロード時に、環境変数、標準的な資格情報保存場所（例: SSH鍵、クラウドCLIの認証情報ディレクトリ）、git設定、ブラウザ/CLIのトークンストア等を走査し、HTTP(S)経由で外部へ送信する振る舞いが多く見られますです。
• 検知回避としてコードの難読化、base64エンコード、ランダムな関数名、例外捕捉での静かな失敗などが用いられる傾向がありますです。
• インシデント発覚後にバージョンを短い間隔で差し替える、メタデータを微修正して再公開する、といった「発見遅延」を狙う小刻みなリリース手口が繰り返されることがありますです。

脅威シナリオと影響

以下はMITRE ATT&CKに沿って、今回の性質から想定しうるシナリオを仮説提示します。自組織のアーキテクチャに当てはめて具体化していただくことをお勧めしますです。

• シナリオ1: 開発端末での依存更新 → クラウド鍵流出

  • 侵入ベクトル: Supply Chain Compromise（T1195.001/002、依存パッケージの汚染）です。
  • 実行: Command and Scripting Interpreter: Python（T1059.006）によるimport時コード実行です。
  • 資格情報アクセス: Unsecured Credentials（T1552系、環境変数・設定ファイルの参照）やCredentials from Password Stores（T1555系）の可能性があります。
  • 収集・送信: Data from Local System（T1005）、Exfiltration Over Web Service/Over C2 Channel（T1567/T1041相当）の経路が想定されます。
  • 事後: 盗まれたクラウド長期鍵でのリソース操作、IAM横展開、データ持ち出しが起こりえますです。

• シナリオ2: CIランナーでのユニットテスト時import → リポジトリ秘密情報流出

  • 実行: テスト実行時に当該パッケージがimportされ、自動実行されますです。
  • 資格情報アクセス: リポジトリPAT、短期OIDCトークン、コンテナレジストリトークンが窃取対象となりえますです。
  • 後続: Use of Access Tokens（T1550系）を通じて、プライベートリポジトリ読み取りや改ざん、リリースパイプラインの乗っ取りが可能になりますです。

• シナリオ3: GPUクラスタでの学習ジョブ → HPC/データ基盤への横断

  • 実行: 分散学習ワーカーやスケジューラノードでimportされた際に実行されますです。
  • 横展開: 有効なSSH鍵やクラスタトークンの窃取により、Lateral Movement（T1021/T1550系）が発生し、他ジョブ・他テナントへの影響に波及しますです。

影響評価の勘所として、被害のスコープは「どの環境で当該バージョンがimportされたか」に比例し、CIや実験基盤のネットワーク閉塞度・秘密情報の短命化度合いに反比例します。したがって、まずは「どこでimportが走ったか」を確定し、次に「その環境が持っていた鍵の棚卸しとローテーション」をセットで回すのが合理的です。

セキュリティ担当者のアクション

緊急対応と恒久対策を分け、今日できる具体策を列挙しますです。

• 緊急（インシデント対応）

  • 影響バージョンの即時排除と健全版への固定を行います。環境ごとにrequirements/lockfileを点検し、2.6.2/2.6.3が参照されていないか確認しますです。
  • 当該バージョンをimportした可能性のある全環境（開発端末、ノートブック、CIランナー、GPUノード、Airflow/Prefect等のジョブ実行基盤）を洗い出しますです。
  • 上記環境で利用された全ての資格情報（クラウド長期鍵、短期セッショントークン、Git/PAT、SSH鍵、モデルレジストリ/APIキー等）を優先順位を付けてローテーションします。短命トークンも念のため失効を強制し、再発行しますです。
  • ネットワーク・DNSログを遡及検索し、Pythonプロセスのimport直後に不審な外向き通信がないかを確認します。送信先ドメインやIPはベンダの公開IoC（Sonatypeの分析等）を参照のうえブロックリスト化しますです。
  • CIのキャッシュやPyPIキャッシュ、アーティファクトストアをクリーンアップし、危険版のホイール/ソースアーカイブを読み出せない状態にしますです。

• 予防（設計・運用の強化）

  • 依存のピン留めとハッシュ固定を徹底します。requirements.txtに--hashを併用する、pip-toolsでconstraintsを生成する、pipの--require-hashesを有効化するなどの「内容同一性の検証」を標準化しますです。
  • 署名・アテステーションの検証をパイプラインに組み込みます。Sigstore系のアテステーションやレジストリ由来のメタデータ検証をゲートにし、未知の頒布経路や未署名のアーティファクトを拒否しますです。
  • 内部ミラー/プロキシ（devpi/Artifactory等）で「許可リスト方式」を採用し、外部レジストリからの直接取得をCI・本番から排除します。新規ライブラリはミラー側で検疫・スキャンしてから開放しますです。
  • 実行時のネットワーク最小化を行います。依存解決フェーズ・ビルドフェーズ・テスト/実行フェーズをネットワークセグメントで分離し、テスト/実行フェーズは既知の宛先以外への外向きを明示的に遮断します。特に「import時の外向き通信」はeBPFやNDRで検知・遮断できるようにしますです。
  • 鍵の短命化とスコープ最小化を徹底します。長期アクセスキーの廃止、OIDCワークロードアイデンティティの採用、PATの期限設定と権限最小化、リポジトリシークレットの分割を進めますです。
  • 依存更新の運用ガードレールを設けます。Dependabot/RenovateのPRに対してSCA＋静的解析＋サンドボックス実行（ネットワーク遮断）を通し、import時の怪しい挙動（os/system/requests/socketの異常使用など）をチェックしますです。
  • 開発者教育を更新します。「importだけで動く」悪性コードの実例と、ローカル実験環境のネットワーク制御・資格情報の分離（プロファイル/権限分割、環境変数に長期鍵を置かない）の実践を取り入れますです。

• 監査のための即席チェックリスト

  • 2.6.2/2.6.3が使われた可能性のある実行ログとパッケージリストを収集しましたか、です。
  • 当該期間にCI/CD・GPUノードから外部への不審通信の有無を確認しましたか、です。
  • ローテーション対象の秘密情報を棚卸しし、完了・未了をトラッキングしていますか、です。
  • 依存ピン留めとハッシュ固定、内部ミラー経由の強制が構成管理に反映されましたか、です。
  • 次回以降の更新PRに対するゲート条件（署名/アテステーション検証、ネットワーク遮断サンドボックス）が自動化されましたか、です。

参考情報

• Sonatype: Malicious PyTorch Lightning packages found on PyPI
  https://www.sonatype.com/blog/malicious-pytorch-lightning-packages-found-on-pypi

最後に、今回のような事案は「どこまでレジストリを信じるか」という議論に帰結しがちですが、現実解は信頼の分散と検証の多層化です。レジストリの監督、社内ミラーの検疫、パイプラインの検証、実行時のふるまい監視、そして鍵の短命化が重なったとき、import時実行のような静かな攻撃はぐっと難しくなります。今日の点検と小さな自動化が、明日の広範なサプライチェーン侵害を防ぐ最短経路になりますです。