LiteLLMマルウェア攻撃:私が分単位で対応した記録から学べること
AIツールを使う前に知っておきたい、サプライチェーン攻撃の実態
1. イントロダクション
「AIツールを使っているだけなのに、なぜ攻撃されるの?」
そう感じる方も多いかもしれません。2024年末から2025年初頭にかけて、AIエンジニアの間で広く使われているツール「LiteLLM」に、悪意のあるコードが混入するという事件が発生しました。
この記事では、実際にその攻撃を検知・対応したエンジニアが公開した「分単位の対応記録」をもとに、何が起きたのか、なぜ危険なのか、そして私たちが日常的にAIツールを使う際に何を気をつけるべきかを、専門知識がなくても理解できるように丁寧に解説します。
「自分はエンジニアじゃないから関係ない」と思わないでください。AIツールの普及により、技術的な知識がない方でも間接的にこうしたリスクにさらされる時代になっています。この記事が、その入口を理解するための一助になれば幸いです。
2. 基礎知識・用語解説
まず、この事件を理解するために必要な言葉をひとつひとつ確認していきましょう。
LiteLLMとは?
LiteLLMは、OpenAIやAnthropicなど、さまざまなAI会社のサービスを「ひとつの窓口」からまとめて使えるようにするオープンソースのツールです。たとえば、ChatGPTとClaudeを切り替えながら使いたいとき、LiteLLMを使うと同じコードで両方を扱えるようになります。AIを使ったサービスを開発するエンジニアの間で非常に人気があります。
オープンソースとは?
ソフトウェアの設計図(ソースコード)が公開されており、誰でも無料で使ったり改良したりできるものを指します。透明性が高い反面、誰でも変更を提案できるため、悪意ある変更が混入するリスクも存在します。
マルウェアとは?
「悪意のあるソフトウェア(Malicious Software)」の略です。コンピュータに侵入して、情報を盗んだり、システムを壊したり、外部から操作できる状態にしたりするプログラムの総称です。
サプライチェーン攻撃とは?
直接ターゲットを攻撃するのではなく、そのターゲットが使っているツールや部品(=サプライチェーン)に悪意あるコードを仕込む攻撃手法です。今回のLiteLLM事件はこれにあたります。たとえるなら、食材そのものを汚染することで、そのレストランで食事した多くの人に影響を与えるようなイメージです。
パッケージ・依存関係とは?
現代のソフトウェア開発では、ゼロからすべてを作ることはほぼありません。他の人が作った部品(パッケージ)を組み合わせて開発します。この「どのパッケージを使っているか」という関係性を「依存関係」と呼びます。LiteLLMのような人気ツールは、多くのプロジェクトの依存関係に含まれているため、ここに問題が生じると影響範囲が非常に広くなります。
3. トレンド分析
事件の経緯:何が、いつ起きたのか
今回の事件は、LiteLLMのパッケージ配布システムに悪意あるコードが混入したことで発覚しました。Hacker NewsやRedditのセキュリティコミュニティでは、この件が急速に拡散し、多くのエンジニアが「自分のプロジェクトは影響を受けているか」を確認する動きが広がりました。
あるセキュリティエンジニアが公開した対応記録によると、最初の異変に気づいたのは、自動監視ツールが「通常とは異なる通信」を検知したことがきっかけでした。そこから分単位で以下のような対応が行われました。
- 0分監視ツールがアラートを発報。外部への不審な通信を検知
- 3分問題のあるパッケージのバージョンを特定開始
- 8分LiteLLMの特定バージョンに悪意あるコードが含まれていることを確認
- 15分影響を受けたシステムをネットワークから隔離
- 22分LiteLLMの開発チームおよびセキュリティコミュニティへ報告
- 45分クリーンなバージョンへのロールバック(元の状態への復元)完了
- 90分影響範囲の全体調査と関係者への通知
この迅速な対応が被害を最小限に抑えた大きな要因とされています。
なぜAI関連ツールが狙われるのか
Hacker Newsのスレッドでは、「なぜ今、AIツールが攻撃対象になっているのか」について活発な議論が行われました。主な理由として挙げられたのは以下の点です。
第一に、普及速度の速さです。 LiteLLMのような便利なツールは、リリースから短期間で数万のプロジェクトに組み込まれます。攻撃者にとっては、一度の仕込みで多数のターゲットに到達できる「効率的な」攻撃経路になります。
第二に、信頼の問題です。 オープンソースコミュニティでは、貢献者(コードを書いて提供する人)を基本的に信頼する文化があります。この信頼を悪用し、正規の貢献者を装って悪意あるコードを混入させる手口が増えています。
第三に、AIツールが扱うデータの価値です。 LiteLLMのようなツールは、企業の機密情報や個人データを含むAIへのリクエストを仲介します。ここに侵入できれば、非常に価値の高い情報にアクセスできる可能性があります。
コミュニティの反応
Redditのr/netsecやr/MachineLearningでは、「自分たちはどう対応すべきか」という実践的な議論が多く見られました。特に注目されたのは「ロックファイル(lock file)の重要性」です。これは使用するパッケージのバージョンを固定する仕組みで、今回のような攻撃への有効な対策として再注目されました。
4. Spectralの見解
「便利さ」と「安全性」のバランスを考える
今回の事件を受けて、私たちSpectralが最も伝えたいことは、「AIツールの便利さを否定するのではなく、正しく理解して使う」という姿勢です。
LiteLLMは非常に優れたツールです。今回の事件は、ツール自体の設計が悪かったのではなく、外部からの悪意ある介入によって引き起こされました。この違いを正確に理解することが重要です。
「分単位の対応」が示すもの
今回公開された対応記録で印象的だったのは、検知から対応完了まで90分以内に収めた点です。これは偶然ではありません。事前に「何かあったときにどう動くか」を準備していたからこそ実現できた速度です。
セキュリティの世界では、「攻撃を完全に防ぐことはできない」という前提に立つことが大切です。重要なのは、攻撃を受けたときにどれだけ早く気づき、どれだけ被害を小さくできるかです。これを「インシデントレスポンス(事故対応)」と呼びます。
AIを導入する企業が今すぐ考えるべきこと
私たちが企業のAI導入を支援する中で、技術的なセキュリティ対策と同じくらい重要だと感じるのが「人と組織の準備」です。
どんなに優れた監視ツールを導入しても、アラートが鳴ったときに「誰が」「何をするか」が決まっていなければ意味がありません。今回のエンジニアが迅速に動けたのは、技術的な準備だけでなく、対応フローが明確だったからです。
また、AIツールの導入を検討している企業の方々には、「そのツールはどこから来ているのか」「誰がメンテナンスしているのか」を確認する習慣を持つことをお勧めします。人気があるからといって、安全性が保証されるわけではありません。
オープンソースへの向き合い方
オープンソースは現代のソフトウェア開発に欠かせない存在です。しかし、「無料で使える=リスクがない」ではありません。今回の事件は、オープンソースの透明性という強みが、同時に弱点にもなりうることを示しています。重要なのは、使う側が適切な確認と監視を行うことです。
5. 実践的アプローチ
では、実際に私たちは何をすればよいのでしょうか。技術者でない方にも実践できることから、開発チームが取り組むべきことまで、段階的に整理します。
ステップ1:使っているツールを「把握する」
まず最初にすべきことは、自分たちが何を使っているかを把握することです。
企業でAIサービスを利用している場合、そのサービスがどのようなオープンソースツールに依存しているかを確認してください。ベンダー(サービス提供会社)に「使用しているオープンソースコンポーネントのリストを教えてください」と聞くことは、正当な要求です。
これを「SBOM(Software Bill of Materials:ソフトウェアの部品表)」と呼びます。食品の原材料表示と同じように、ソフトウェアにも「何が入っているか」を示すリストが存在します。
ステップ2:バージョンを「固定する」
開発チームに向けたアドバイスです。
使用するパッケージのバージョンを固定する「ロックファイル」を必ず使用してください。Pythonであればrequirements.txtやpoetry.lock、Node.jsであればpackage-lock.jsonがこれにあたります。
「最新版を自動的に使う」設定は便利ですが、今回のような攻撃が混入した最新版を自動的に取り込んでしまうリスクがあります。バージョンを固定し、アップデートは意図的・計画的に行うことが基本です。
ステップ3:「監視する」仕組みを作る
今回の事件で最も重要だったのは、「異変に気づく仕組み」があったことです。
具体的には以下のような対策が有効です。
- 依存関係の脆弱性スキャン使用しているパッケージに既知の問題がないかを自動チェックするツール(例:Dependabot、Snyk)を導入する
- 通信の監視システムが外部と行う通信を記録・監視し、不審なものを検

Author
森島拓生
Spectral 代表 / AI導入・エージェント設計
Spectral代表。AI Development & Consultingを軸に、非エンジニアとの対話から要件定義を構造化する「上流工程AI」や、AIエージェントによる業務自動化の設計・検証に取り組む。技術を導入して終わらせず、現場で継続して使える運用設計までを重視している。
AI導入について、もっと詳しく知りたい方へ
お問い合わせ