Artificial Intelligence (AI)
AIスタックのルートキー漏洩の可能性：litellmのPyPI侵害の実態
LitellmのPyPI侵害を解説します。侵害されたバージョンがクラウド認証情報、SSHキー、Kubernetesシークレットを窃取します。影響と緊急の対処方法を確認してください。
人気のPythonパッケージであるlitellmが、PyPI上で侵害されました。バージョン1.82.7および1.82.8には、クラウド認証情報、SSHキー、Kubernetesのシークレットを窃取する不正コードが含まれています。2026年3月24日以降に環境を更新している場合、認証情報はすでに第三者の手に渡った前提で対応する必要があります。直ちに作業を中断し、該当パッケージを削除したうえで、チームへ共有し、認証情報のローテーションを速やかに実施してください。
ずさんなハッカーがもたらした、ある朝の異変
こうした状況を想像してみてください。エンジニアがコーヒーを片手に業務を始め、開発環境を立ち上げた瞬間、マシンが突然クラッシュする。まさにそのような形で、litellmのPyPIサプライチェーン攻撃は発覚しました。ただし、攻撃に使用されたマルウェアには不具合があり、子プロセスを無限に生成するループ、いわゆるフォークボムを引き起こし、ホストマシンをダウンさせたのです。もし攻撃者のマルウェアのコードがもう少し巧妙であれば、この異常には気づかれず、現在も本番環境の機密情報が静かに抜き取られ続けていた可能性があります。今回は偶然にも発覚したに過ぎません。
調査機関「FutureSearch」によるセキュリティ分析によれば、攻撃者はlitellmプロジェクトのメンテナーアカウントを乗っ取りました。そして、通常のGitHubリリース手順を迂回し、改ざんされたバージョンを直接PyPIに公開しました。litellmは開発者と主要なLLMエンドポイントの間に位置するコンポーネントであるため、基本的なスクリプトから高度なコーディングエージェントに至るまで、幅広い環境で依存関係として取り込まれています。
その影響範囲は極めて広大です。このパッケージは、わずか1日で3,408,615回ダウンロードされ、過去1か月では9,500万回以上ダウンロードされています。AI関連の開発を行っている場合、このパッケージが環境に含まれている可能性は極めて高いといえます。
AIセキュリティも本質的にはソフトウェアセキュリティに過ぎない
高度なAIの脆弱性として、プロンプトインジェクション、データポイズニング、モデル反転といった話題が注目されています。しかし実際には、攻撃者はこの10年以上にわたり対処してきた、従来と同じインフラの弱点を突いています。
AIの技術スタックは、標準的で脆弱なオープンソース基盤の上に成り立っています。攻撃者は常に中心にある最も弱い部分を狙います。複雑なLLMの脱獄を仕掛けるよりも、汚染されたPythonの依存関係を使ってKubernetesクラスタを容易に掌握できるのであれば、そちらを選ばない理由はありません。AIをまったく新しい領域として扱い続けていますが、攻撃者は従来と同じサプライチェーン攻撃の手法を用いて侵入しているに過ぎません。
今回の事案は、最新バージョンへ無条件にアップデートすることの危険性も浮き彫りにしています。リリースされた直後に最新パッチを適用するという行為への過度な執着は、大きな脆弱性となり得ます。CI/CDパイプラインが隔離期間を設けずに最新リリースを自動取得する設計であれば、自ら侵害を自動化しているのと同じです。依存関係は暗号学的ハッシュで固定してください。そして、新しいリリースについては、まず他の環境でサプライチェーンマルウェアの有無が検証されるのを待つべきです。
クラウドネイティブな侵害の全体像
攻撃者は、Pythonインタプリタの起動時に隠されたスクリプトを自動実行させる既知の手法を悪用しました。侵害されたライブラリを明示的にインポートしなくても、無関係なスクリプトを実行するだけでマルウェアが発動します。
起動後、このペイロードは高度なクラウド特化型の情報窃取ツールとして動作します。AWS、GCP、Azureの設定情報を広範に収集し、内部のクラウドメタデータへ積極的に問い合わせることで、インスタンスロールの乗っ取りを試みます。
特に深刻なのはKubernetes環境です。マルウェアがサービスアカウントトークンを検出すると、クラスタ全体の乗っ取りへとエスカレーションします。そのトークンを利用して、すべてのネームスペースにわたるシークレットを窃取します。さらに、コンテナエスケープを実行し、分離されたPod環境から脱出して、基盤となるホストノードに永続的なバックドアを直接仕込みます。これは、受付用の入館証を渡したつもりが、実際にはマスターキーを複製され、サーバルーム内に拠点を築かれているようなものです。
最後に、データを暗号化したうえで攻撃者が管理するサーバへ送信し、さらにcheckmarx.zoneへの接続を確立します。これは信頼されたブランド名を意図的に悪用し、DNSの許可リストを回避するためのものです。
シークレット管理の盲点が露呈した構造的欠陥
今回の事案は、ソフトウェアの構築方法における深刻な設計上の問題を浮き彫りにしています。オープンソースのレジストリを無条件に信頼しているだけでなく、一度境界が突破された後は、攻撃者にとって極めて容易に侵入を拡大できる構造になっています。こうした攻撃経路については、日々実際に悪用されている状況を踏まえ、継続的に調査・発信を行っています。
このマルウェアは、環境変数を取得し、ディレクトリ内の深い階層にある.envファイルを探索する挙動を持っています。もし現在も長期間有効な認証情報を環境変数に保存していたり、暗号化されていないシークレットを本番環境のディスク上に残している場合、インフラへのアクセスを自ら攻撃者に引き渡しているのと同じです。これらの脆弱性については、DevOpsのリスクや環境変数の潜在的な危険性に関するレポートでもすでに指摘しています。
こうした背景から、TrendAI Cloud Risk and Exposure Management（CREM）が重要となります。クラウド環境の露出リスクを事前に可視化し、適切に管理していれば、サービスアカウントトークンが窃取された場合でも、被害は局所的にとどまり、クラスタ全体の重大な侵害には発展しません。ペイロードが実行される前に、影響範囲を最小化する設計が求められます。
セキュリティ対策が本当に機能する場所
完璧なアーキテクチャは存在しません。ゼロデイのサプライチェーン攻撃がプロキシレジストリをすり抜けた場合に備え、多層的な防御を構築しておく必要があります。
TrendAI Code Securityは、ビルド段階でコンテナイメージをスキャンし、侵害されたライブラリを検知することで、悪意あるペイロードが実行される前に阻止します。しかし、ゼロデイ攻撃がパイプラインを通過してしまった場合、静的スキャンだけでは不十分です。実行時の挙動を監視するセーフティネットが不可欠です。そこで、Container SecurityやVision Oneが重要な役割を果たします。実際の実行挙動を監視し、コンテナ内の一見無害なPythonスクリプトが突然Azureの認証情報を取得したり、Kubernetesのサービスアカウントトークンを読み取ったり、バックグラウンドデーモンのインストールを試みた場合、XDRエージェントがその異常な挙動を検知し、攻撃者によるデータの持ち出しが行われる前にプロセスを停止します。
インフラを守るための重要なアラート機能を提供します。しかし忘れてはならないのは、防災設備を導入するだけでは不十分であり、建物そのものを耐火構造で設計する責任は利用者側にあるという点です。
今すぐチームに確認すべきこと
スタック内でlitellmを使用している場合、既知の侵害指標（IoC）に基づき、エンジニアリングチームおよびセキュリティチームに対して以下の対応を直ちに指示してください。
- 環境の完全なクリーンアップ。litellm_init.pthの有無を確認し、すべてのパッケージマネージャのキャッシュを削除すること。
- 永続化の痕跡を調査。不審なsysmon.serviceデーモンや、/tmp/pglog、/tmp/.pg_stateといった疑わしい一時ファイルをSOCで確認すること。
- Kubernetesクラスタの監査。kube-systemネームスペース内で、node-setup-*パターンに一致する異常な特権Podが存在しないか確認すること。
- 外向き通信の遮断。checkmarx.zoneおよびmodels.litellm.cloudへのすべての外向き通信をブロックすること。
- 侵害前提での対応。SSHキー、クラウド認証情報、データベースパスワードを直ちにローテーションすること。
- FutureSearch: litellm PyPIサプライチェーン攻撃（英語）
- Trend Micro: DevOpsの「地雷原」に潜む脅威を分析
- Trend Micro: 環境変数による機密情報保持の隠れた危険性を分析
参考記事
Your AI Stack Just Handed Over Your Root Keys: Inside the litellm PyPI Breach
By: Fernando Tucci
翻訳：与那城 務（Core Technology Marketing, Trend Micro™ Research）