- PyPI経由で配布されたLiteLLM 1.82.8の悪意あるパッケージ感染をリアルタイムで検知・分析した分単位の対応ログ
- 感染はCursor IDEの自動更新中に発生し、
litellm_init.pthファイルが実行されて認証情報の窃取とシステム感染を引き起こした
- 悪性コードはSSHキー・クラウド認証情報の収集、Kubernetesへの拡散の試行、フォークボムの生成など複合的な動作を実行
- PyPIセキュリティチームとLiteLLMメンテナーに即時報告され、パッケージ隔離とCVE登録につながった
- Claude CodeなどのAIベースのコード分析ツールが攻撃検知に重要な役割を果たし、AIエコシステムのサプライチェーンセキュリティ強化の必要性を示した
LiteLLMサプライチェーン攻撃対応記録
- LiteLLM 1.82.8がPyPI経由で配布された悪意あるパッケージであることが判明し、感染検知から隔離までの過程を分単位で記録した対応ログ
- 感染はCursor IDEの自動更新プロセスで発生し、Claude Codeとuvパッケージマネージャー経由でインストールされた依存関係のうち
litellm_init.pthファイルが実行され、システム感染を引き起こした
- 攻撃は認証情報の窃取、システム永続化の設置、Kubernetesへの拡散の試行、フォークボム(fork bomb) を含む複合的な動作で構成
- PyPIセキュリティチームとLiteLLMメンテナーに即時報告され、パッケージ隔離とCVE発行につながった
- AIベースのコード分析ツールがリアルタイムの悪性動作の検知と分析に重要な役割を果たした
初期検知とシステム異常の兆候
- 11:13 UTCごろ、macOSノートPCで11,000個以上のPythonプロセスが生成され、システムが停止状態に入った
exec(base64.b64decode('...'))形式のコマンドが繰り返し実行され、CPUとメモリを飽和させた- 強制終了後に再起動したところ、永続化(persistence) に関する痕跡は見つからなかった
- 当初はClaude Codeの内部ループや
uv runスクリプトのエラーによる非悪性のループ現象と判断された
- その後、
htopのスクリーンショットとログからbase64エンコードされたPythonスクリプトが繰り返し実行されていた事実が確認された
感染原因の特定
- 11:40ごろ、インストール済みのPythonツール内で**
litellm_init.pthファイル**が発見され、悪性動作であることが判明
.pthファイルはPython起動時に自動実行され、すべてのPythonプロセスで動作する- SSHキー、クラウド認証情報、データベースパスワード、環境変数、シェル履歴などを収集
- 収集したデータはRSA暗号化後に
https://models.litellm.cloud/へ送信された
~/.config/sysmon/sysmon.pyへの永続化設置を試みたが、強制再起動によって中断された
- 感染はCursor IDEの自動更新(10:58 UTC) 中に発生
futuresearch-mcp-legacy拡張機能がuvxを通じてlitellm 1.82.8をダウンロード- このバージョンはPyPIにのみ存在し、GitHubリリースタグがない
- PyPIへのアップロード時刻は10:52 UTCで、感染直前に配布されたことが確認された
悪性コードの構造
- 第1段階(
litellm_init.pth): Python起動時に自動実行され、base64エンコードされたペイロードをデコードして実行
- 第2段階: RSA公開鍵を含み、窃取データの暗号化に使用
- 第3段階(B64_SCRIPT): 実際の認証情報収集と送信を実行
- 永続化の設置:
sysmon.pyをsystemdサービスとして登録しようと試行
- Kubernetes拡散コード:
alpine:latestイメージを使い、各ノードにprivileged podを作成しようと試行
- フォークボムの原因:
subprocess.Popen([sys.executable, "-c", ...])の呼び出しが子プロセスでも.pthを再実行し、無限ループが発生
被害範囲と対応措置
-
露出した認証情報
- SSHキー、GCloudおよびKubernetes認証情報、
.envファイル内のAPIキー、Supabase・ClickHouse・Grafanaのパスワードなど
- 即時対応の推奨
- すべてのSSHおよびクラウド認証情報をローテーション
.envおよび.mcp.json内の秘密鍵を再発行~/.cache/uvキャッシュを削除- PyPIセキュリティチーム(
security@pypi.org)およびLiteLLMメンテナーへ報告
-
Kubernetesクラスター点検結果
- 悪性pod(
node-setup-*, sysmon)は未発見
- macOS環境で実行されたため、クラスター内部への拡散は失敗
- ただし、
~/.kube/configが露出した可能性があるため、認証情報のローテーションが必要
PyPIおよび公開対応
- 11:58 UTC、Docker隔離環境でPyPIからlitellm 1.82.8をダウンロードし、悪性
.pthファイルの存在を再確認
- PyPIセキュリティチームとBerriAI/litellmリポジトリへ即時報告
- その後、PYSEC-2026-2 (CVE) として登録
- 12:01 UTC、FutureSearchブログにサプライチェーン攻撃を公開する記事を作成・配信
- 12:04 UTC、r/Python、r/netsec、r/LocalLLaMA、r/MachineLearning、r/devopsコミュニティへの共有を提案
- Pythonおよびセキュリティコミュニティで迅速な対応を促進
事件の意味
- AIベースのコード分析ツールClaude Codeがリアルタイムで悪性動作を識別し、セキュリティ研究者が介入する前段階で警告を生成
- サプライチェーン攻撃がAI開発者エコシステムを直接狙った事例であり、PyPIアカウントのセキュリティと自動更新検証の強化の必要性を浮き彫りにした
- AIツールが単なる開発支援を超え、サイバー脅威の検知と対応の自動化に活用できることを示した事例
1件のコメント
Hacker Newsのコメント
私はlitellmの脆弱性を最初に発見して報告した開発者です。
当時の状況をそのまま記録したリアルタイム分析の対話記録を共有しました。
Claudeが誰に連絡すべきか、どの順番で対応すべきかを段階的に案内してくれたので、非セキュリティ専門家にとっても大いに役立つ体験でした。
このように非専門家が脆弱性を発見して報告することが、セキュリティコミュニティの助けになるのか、それとも混乱を招くのか気になります。
ただし「Cursorを再び開いた途端に悪意あるパッケージが実行された」という部分は少し危険に見えます。
疑いが生じた時点で、まず端末の隔離とセキュリティチームへの連絡をすべきでした。
.pthファイルがfork bombのように動作しなければ、発見はもっと遅れていたかもしれません。
Claudeに連絡経路を尋ねたのは良い判断でした。
PyPI関連の連絡先が分からなかったので、メンテナーにメールを送り、Hacker Newsにも投稿しました。
セキュリティコミュニティに属していなくても、このような深刻な脆弱性の報告は誰でもできるべきだと思います。
問題の大半は、金目当てで何でも脆弱性だと主張する人たちによるものです。
しかし、あなたのレポートは品質が高く、こうしたものはすぐにパッチ優先順位に載せます。
業務中断なしで解決可能なら即時対応し、深刻な場合はCISOやCTOにすぐ報告していました。
あなたの報告のおかげで、より大きな事故を防げたわけです。
私たちも関連内容を2回に分けてブログにまとめました。
grith.aiのブログ記事
しかし今回の事例は、AIの助けで原因分析と報告がはるかに速くなった好例だと思います。
自分のclaude-code-transcriptsツールが、ブログ記事にデータとして埋め込まれているのを見たのは初めてです。
普段はGistのHTMLページとして共有していましたが、この使い方は興味深いです。
ブログのスタイルに合わせようとして失敗しましたが、基本体験の重要性を改めて感じました。
Claudeが私のコンピュータ全体をスキャンするかのようにログを拾っていくので、自動ログ編集システムが必要だと感じました。
緊急デバッグ中にチームと協業するとき、特に不便です。
「悪意あるスクリプトの内容を実行せずに出力できるか？」のような依頼は危険です。
LLMエージェントには責任という概念がないため、誤って実行命令を出すと大きな事故につながりかねません。
PyPIからファイルを取得するときは、必ずサンドボックス環境で行うべきです。
「やるな」と言われると、かえってそこに執着してしまう傾向があります。
PyPIが「デジタル認証（digital attestation）」をサポートしていると聞きましたが、このパッケージは署名されていたのでしょうか。
PyPI Trusted Publishersの文書
GitHub、npm、PyPIのようなパッケージレジストリは、**リアルタイムのセキュリティ分析用イベントストリーム（firehose）**を提供すべきだと思います。
この種の攻撃は、自動スキャナが即座に検出できたはずです。
セキュリティパートナーがパッケージをスキャンし、招待制APIで報告できます。
PyPIブログ記事 を参照してください。
関連記事
自動スキャナが.pthファイルのような異常兆候を検知する時間を稼ぐのが目的です。
経済的被害があまりに大きくなり得ますし、litellmの感染者だけでも4万7千人を超えています。
「ブログ記事作成、PR、マージまで3分以内」という部分が最も衝撃的でした。
読む時間より速いペースで、不安を覚えます。
1万1千プロセスのfork bombがなければ、この攻撃はずっと長く潜伏していたかもしれません。
もしbombの速度がもっと遅ければ、被害ははるかに大きかったでしょう。
大企業が信頼できないオープンソースコードを実行する方法は2つあります。
現実的には(1)が最も安全です。
中小企業や個人にとっては、**依存関係の固定（pinning）**と十分な待機時間が最善の防御策です。
Bazelを使えば(1)に近づけますが、多くは外部ソースに依存せざるを得ません。
PyPIが報告後30分でパッケージを隔離したのは本当に迅速な対応でした。
AI/LLMの最大の利点の一つは、リバースエンジニアリングの民主化です。
以前は学びにくく、見返りも少ない技能でしたが、今ではAIが方向を示してくれます。
exec(base64.b64decode(...))パターンは、Pythonツールがコードを受け渡す際によく使う方式ですが、
基本的に**/tmpや/var/tmp、/dev/shmで実行されるコード**は非常に疑わしく見るべきです。
もしLuluやLittleSnitchのようなネットワーク監視ツールがあれば、異常トラフィックを防げたでしょう。
ただし、Claudeにバイナリをアップロードして解析させるのは別の危険があります。