世界を動かす技術を、日本語で。

LiteLLMマルウェア攻撃に対する私の分単位の対応

概要

  • 2026年3月24日に発生した litellm 1.82.8 サプライチェーン攻撃 の調査・対応記録
  • AIツール により、マルウェアの発見・公開までが 72分 で完了
  • Claude Code による自動化された分析・報告プロセス
  • 被害内容 は認証情報の窃取・永続化・自己増殖型フォークボム
  • 再発防止策 と、AI活用の今後の課題提起

litellm 1.82.8 サプライチェーン攻撃 調査・対応記録

  • 2026年3月24日、 litellm v1.82.8 がPyPIにアップロード、 GitHubタグ未存在
  • futuresearch-mcp-legacy が依存関係として感染バージョンを取得
    • uvx 経由でlitellmをダウンロードし、マルウェア混入
  • マルウェアによる永続化試行
    • ~/.config/sysmon/sysmon.py作成(書き込み中断で0バイト)
  • 11,000プロセスのフォークボム発生
    • 強制再起動で永続化失敗、マルウェア部分的に無効化
  • Claude Codeによる初動調査
    • 当初は無限ループと誤認、後にマルウェアと判明
  • litellm_init.pthの発見
    • Python起動時に自動実行、 認証情報窃取・K8s横展開・情報流出
  • Docker隔離環境で感染再現を確認
    • pthファイル含有の新規ダウンロードで感染を再現
  • 公開までの流れ
    • Disclosureブログ記事をClaude Codeが自動生成し、3分で公開・PR作成・マージ
    • r/Python, r/netsec, r/LocalLLaMAに共有
    • 最初の症状発生から公開まで72分

マルウェアの詳細

  • .pthファイル による自動実行機構
    • Python起動時に毎回実行、 SSH鍵・AWS/GCP認証・K8sトークン・DBパスワード等を収集
    • RSA暗号化 でhttps://models.litellm.cloud/ へ情報送信
  • 永続化手法
    • systemdサービス(~/.config/sysmon/sysmon.py)を用意
  • 自己増殖
    • subprocess.run([sys.executable, ...])で子プロセスを生成、 無限再帰的に.pthが再実行
    • これにより フォークボム 発生
  • Kubernetesクラスタへの横展開
    • 特権Pod作成で他ノードへ感染拡大

AIツールによる対応の変化と今後の課題

  • AIツールの進化 で、専門知識がなくても迅速なインシデント対応が可能
    • MacOSのシャットダウンログ解析やDockerコマンド等の詳細知識が不要
    • AIが技術的作業を代行、人間は意思決定や公開対応に専念
  • Claude Code は疑念を持つことで初めてマルウェア検出へ至った
    • AIモデルへのセキュリティ意識強化 の必要性
  • 今回の事例で AIと人間の協働 による迅速な被害抑制が実現

再発防止策・推奨事項

  • Cursorの自動アップデート無効化 (Settings → "update.mode": "manual")
  • プロセス数制限 (.zshrcにulimit -u 2048追加)
  • 不要なMCPサーバーの削除
  • futuresearch-mcp-legacyの無効化またはAPIキー設定
  • 不審なPythonパッケージの監視強化

AI活用とセキュリティ教育の今後

  • フロンティアラボはAIモデルに攻撃検知能力を持たせるべきか?
    • 人間の健全な懐疑心とAIの自動化能力のバランス
  • AI主導の対応プロセス が今後の標準となる可能性
  • セキュリティ教育 は「人間が冷静に状況を伝え、AIが技術部分を担う」方向へシフト

関連情報:

Hackerたちの意見

カラムです。火曜日にlitellmの脆弱性を最初に発見して報告した開発者です。リアルタイムで何が起こっているのかを理解する過程のトランスクリプトを共有します。編集はほとんどなく、少しの情報は隠しています。後から思考過程を振り返る必要はありませんでした。それは、クロードが何が起こっているのかを理解するために書き留めたものと全く同じです。私はMLエンジニアなので、クロードが誰に連絡すればいいか、時間が重要なアクションのステップバイステップガイドを示してくれたのは、セキュリティ研究者でない人にとっては大きな変化でした。セキュリティコミュニティは、こういう脆弱性を見つけて報告する非専門家が増えることをポジティブに捉えているのか、それとも厄介だと思っているのか、気になります。

セキュリティ研究者ではないけど、これは明らかにポジティブだと思う。武器競争のもう一方の側も強くなっているし、責任感のある人たちがガードレールを追加しているから、悪党側よりも強いと言えると思う。プレゼンも素晴らしいね <3。

最近、オープンソースプロジェクトが脆弱性報告やPRで溢れているという話を聞いたけど、今回はAIの助けがあったおかげで、根本原因を特定して迅速に報告できたのが明らかに良かったね。

ほぼ同じタイミングで、ほぼ同じ方法で発見したみたいだね。もし.pthファイルがフォークボムのような動作を引き起こさなかったら、もう少し長い間発見されなかったかもしれない。クロードに誰に連絡すればいいか教えてもらうのは良い考えだったね。PyPIに関連する誰かに連絡する方法が全く分からなかったから、まずメンテナーにメールを送って、Hacker Newsに投稿したよ。私はセキュリティコミュニティの一員ではないけど、こういうことを見つけた人は誰でも報告できるべきだと思う。深刻なセキュリティ脆弱性の報告を制限する意味はないよね。

警鐘を鳴らしてこれを共有してくれてありがとう。とても洞察に満ちてるし(プレゼンも美しい!)

脆弱性開示のプログラムマネージャーとして、時には周辺的に、時には主要に関わっているけど、$0.02の意見を述べるよ。これは信号とノイズの問題なんだ。ほとんどのトラブルは、底辺の人たちが何でも脆弱性だと呼んでお金を求めてくることから生じている。月に一度くらい、誰かが無料ツールを使って、出力のスニペットを盲目的に送ってくることがあって、残りはお金と引き換えに約束するんだ。あるいは、高品質な情報を持ってくるように丁寧にリマインドされた後にCFOや法務部にメールを送って、無視されるまで待つこともある。あなたの報告は高品質だったけどね。僕は来た報告は全部読んでいて、良いものはすぐに修正の優先度を上げていた。ビジネスを止めずに修正や緩和ができる方法があればすぐに対応して、CISOやCTO、該当するエンジニアリングマネージャーに連絡するよ。

いいまとめだね…特にClaudeがこういうことに関してすごく良いと思ったよ。これが良いことかどうかは、全体的にはプラスだと言えるかな。あなたの報告が大きな問題を救ったかもしれない!私たちは、なぜ/何が起こったのかをブログに2回書いたよ…2回目はLiteLLMの問題に基づいているんだ。

素晴らしいまとめだね、シェアしてくれてありがとう!こんな深いサプライチェーンの脆弱性はこれからも増えていくと思う。セキュリティコミュニティにとって価値があることだと思うよ。クリフ・ストールが天体物理学者からローレンス・バークレー研究所のシステム管理者に転身して、75セントの会計の不一致を追跡して外国のスパイ活動を特定したことを思い出してね。

セキュリティの仕事をしている者として、Claudeの助けでこれを発見できたのはすごいことだと思う。でも、「Cursorを再び開いたら悪意のあるパッケージがトリガーされた」というメッセージはちょっと衝撃的だね。理想を言えば、マルウェアを疑った瞬間、そのマシンは隔離されて、セキュリティ担当者に連絡されるべきだったよ。

GitHubやnpm、PyPiなどのパッケージレジストリは、リアルタイムでセキュリティ分析を行えるようにファイアホースを公開することを検討すべきだと思う。確実にこの攻撃をすぐにキャッチできるスキャナーがあるはずで、彼らには更新情報を受け取る方法が必要なんだ。

これについてずっと考えてるんだ。すでに私たちのモノレポのすべての部分に依存関係のクールダウンを追加したよ。次に考えるべき明らかなことは「次の人に責任を押し付けてるだけじゃないか?」ってこと。でも、君が指摘しているように、自動スキャナーがこのケースの.pthファイルのような明らかな兆候を拾うのに十分な時間を与える必要があるんだ。

PyPIはまさにその通りのことをやっていて、すごく効果的なんだよね。セキュリティパートナーはパッケージをスキャンして、招待制のAPIを使って報告できるんだって。

こういうことのためにスキャンインフラを提供する法的責任があるべきだと思う。潜在的な経済的損害は壊滅的になりうるからね。47,000人以上が感染したことを考えると、これがlitellmストーリーの終わりだとは思えないな。

自分のツール https://github.com/simonw/claude-code-transcripts を使って、ブログ記事に埋め込まれたデータを構築するのを初めて見たよ。これは面白い使い方だね。普段はGistでHTMLページとして共有してるんだけど、例えば https://gisthost.github.io/?effbdc564939b88fe5c6299387e217da...

うちの会社ではこれをめっちゃ推してるよ!CCがうちのブログに合わせてスタイルを整えようとしたけど、ちょっと失敗だったかな。標準の体験に対する新たな感謝を感じたよ。それに、Claudeの調査の個別のサブページも含めようとしたんだけど、マルウェアを探すためにマシン全体をひっかき回すことになっちゃった。詳細なログの無限ページをどうやって整理するか、何かシステマティックな方法を考えたことある?

AIやLLMの一番の良いところは、こういうペイロードのリバースエンジニアリングと分析が民主化されていることだと思う。手で学ぶのはすごく難しいスキルで、知的好奇心からすぐに報われることはあまりないからね。でも、今は簡単に正しい方向に導いてもらえるよ!

以前、YouTubeでCTFのウォークスルーを見て楽しんでたんだけど、試してみようと思ってたんだ。でも、ロックピッキングと同じカテゴリに入る気がする。LARPするのは楽しいけど、普段の仕事で遭遇することはなさそうだね。

このケースはリバースエンジニアリングとは関係ないよ、基本的なシステム管理の話。AIが「正しい」方向を指し示すのを見てみて:何が起こったかというと、exec(base64.b64decode('...'))のパターンはマルウェアじゃなくて、Pythonのツール(Claude CodeのBashツールも含む)がコードスニペットをpython -cに渡す方法なんだ。デフォルトでは、cmdline経由でPythonに渡されるbase64文字列は非常に疑わしいと見なされるべきだよ。それに、/tmp、/var/tmp、/dev/shmから実行されるものもね。データをhttps://models.litellm.cloud/にRSAで暗号化してエクフィルされるけど、もし@opがLuluやLittleSnitchをインストールしてたら、怪しいアウトバウンド接続に気づいてブロックしてたかも。とはいえ、分析のためにバイナリをClaudeにアップロードするのは別の話だね。

11,000のプロセスフォークボムがなかったら、どれくらい時間がかかったかなって思う。

それなんだよね、依存しているパッケージをインストールしようとしたときに、ほぼ瞬時に気づいた。始まった瞬間にラップトップがハードロックして、感染する前に止まったけど、もしフォークボムが遅くなっていたら、もっとダメージを与えていたかも。

多くの開発者は、pip installがファイルをディスクに置くだけで、実行はインポート時に行われると思ってるけど、.pthファイルはPythonの起動時に毎回実行されるから、インポートは必要ないんだ。npmのpostinstallのような一回限りのインストールフックじゃなくて、持続的なんだよ。

マルウェアスクリプトの内容を実行せずに印刷できますか? PyPIからDockerコンテナでこれをダウンロードして、ファイルが見えるか確認してもらえますか?コンテナ内でうっかり実行しないように気をつけて!個人的には、LLMエージェントは責任感を持っていないことを念頭に置くべきだと思うから、もし彼らがうっかりスクリプトを実行したり、実行するコマンドを発行したら大変なことになるよ。サンドボックス環境でpypiからダウンロードするのは1-2コマンドでできるから、テキスト予測マシンに渡すものには気をつけないとね。

それについても心配してた。何かをやめるように言うと、最初から言わない方が良かったってことが多いよね。なんか、執着しちゃうみたい。

この攻撃には、あまり魅力的じゃない「依存関係のアップグレードの前に24時間待つ」という解決策で対処してるけど、幸いにもuvで既にサポートされてるんだ。

大企業が信頼できないオープンソースコードを実行するための選択肢は次の通り:1) Google方式:すべてをソースからビルドする。ソースは公開リポジトリからミラーコピーされる。(毎回ソースを監査・信頼する)2) 会社が管理するミラーからのインポートのみ許可。すべてのインポートされたパッケージは何らかの形で署名される必要がある。ここでは(1)が安全だね。(2)は依存関係をあまり攻撃的に更新しない場合や、内部の自動または手動スキャンでバージョンアップ時に問題をキャッチできる場合にのみ安全だよ。小規模なショップや個人にとっては、運が悪いけど、最善の対策は依存関係を固定して、Fibonarのような人たちが攻撃をキャッチするのを待つことだね... Bazelは(1)を実現する一つの方法だけど、現実的にはすべてをソースからビルドするためのバンド幅がないなら、外部ソースに依存することになるから、特定のパッケージが影響を受けたら運が悪いことになるよ。

ちょっと混乱してるんだけど、実際に誰かにその脆弱性についてメールしたことあるの?AIはセキュリティのメールに何度も連絡することを勧めてるけど、タイムラインを読んでる限り、そういうことがあったとは思えないんだ。ただブログ記事が作られて、Redditで共有されて、関連する人たちが間接的に行動を起こしたってだけみたい。これがタイムラインに載ってないことを願ってる。