Ars Technica、サプライチェーン攻撃後の大規模なLiteLLM認証情報流出を報道
Ars Technicaによると、侵害されたAIパッケージを通じて盗まれたデータの中に、2,500以上の組織に関連する認証情報が含まれていた。報じられた規模により、3月のLiteLLMインシデントは一時的なパッケージ障害から、長期化し得る認証情報危機へと様相を変えている。
攻撃者はLiteLLMの公式リリース2件を改ざんし、PyPIとして知られるPython Package Indexを通じて配布した。悪意あるコードは、感染システムからクラウドキー、リポジトリトークン、SSH認証情報、データベースパスワード、AIサービスで使われるシークレットを探索した。
攻撃はLiteLLMから始まったわけではない。これは、信頼されたセキュリティツール、開発者のワークフロー、パッケージ公開アカウントを経由したキャンペーンの一部だった。侵害された各リンクは、攻撃者がソフトウェアサプライチェーンの別の部分へ到達するのに役立つ認証情報を提供したと報じられている。
新たに報告されたデータは、影響範囲についてより明確ではあるものの、なお不完全な像を示している。研究者らは、数十万件のファイルまたはパイプライン記録を2,500以上の組織と結び付けた。ただし、盗まれたデータにドメインが含まれているからといって、記載されたすべての組織が不正アクセスを受けたことを証明するものではない。
この区別は重要だ。確認済みのパッケージ侵害は2026年3月に発生し、研究者らがより広範なデータセットを公開したのは数カ月後だった。セキュリティチームは今、攻撃中に収集された認証情報が有効なままだったのか、悪用されたのか、あるいは攻撃者が利用する前にローテーションされたのかを判断しなければならない。
Ars Technicaが示す、流出データから分かること
最新の展開は新たな汚染パッケージではなく、当初の侵入が初期見積もりをはるかに超えていたことを示唆する証拠だ。
認証情報露出に関する報告によると、セキュリティ研究者らは攻撃者に帰属するとされる膨大な収集データを調査した。この資料には、2,500以上の組織に関連するシークレットが含まれていたと報じられている。
この収集データには、クラウドアクセスキー、ソースリポジトリトークン、SSHキー、Kubernetesシークレット、環境変数、パッケージ公開認証情報、AIプロバイダーキーが含まれていた。これらは公開ディレクトリから集められた単なるアカウント名ではなく、運用上の認証情報だ。
露出したクラウドキーは、ホスト型インフラへのアクセスを与え得る。リポジトリトークンは非公開ソースコードを露出させたり、不正な変更を許したりする可能性がある。パッケージ公開認証情報があれば、攻撃者は信頼されたプロジェクト名で悪意あるソフトウェアを配布できる。
Kubernetesシークレットは別の侵入経路を生む。Kubernetesはコンテナ化アプリケーションを管理するシステムであり、そのサービスアカウントには広範なインフラ権限が付与されることがある。過剰な権限を持つ盗難トークンは、攻撃者が1つのワークロードからクラスター全体へ移動するのを助けかねない。
研究者らはこのデータを、およそ434,000件の継続的インテグレーション／デリバリー記録とも関連付けた。CI/CDパイプラインはソフトウェアのテスト、ビルド、デプロイを自動化し、その過程で認証情報を一時的にメモリへ読み込むことが多い。
この数字を434,000件の侵害が確認されたものと解釈すべきではない。1つの組織が多数のジョブ、ランナー、リポジトリ、反復的なパイプライン実行を運用している場合がある。複数のキャンペーン段階で盗まれたデータ内の重複記録も、件数を押し上げ得る。
報じられたデータセットは、約195 TBに及ぶファイル収集データと結び付けられていた。すべてのバイトを固有の認証情報として表現するのは誤解を招く。この種の収集物には、シークレットに加え、重複したシステムファイル、ソースツリー、ログ、アーカイブ、メモリキャプチャが含まれる場合がある。
より妥当な結論は、認証情報の数ではなく到達範囲に関するものだ。攻撃者は、価値ある認証情報が存在する多数の開発環境からデータを収集したように見える。資料の規模は、検証と被害者通知も複雑にしている。
CloudSEKは、組織が自社ドメインが分析済み資料に含まれているか確認できる検索可能な露出確認サービスを作成した。一致が見つかれば調査を開始すべきだが、攻撃者がその組織のネットワークへ侵入したことの決定的証拠ではない。
同様に、影響を受けたパッケージをインストールした組織にとって、不一致はほとんど安心材料にならない。データセットは不完全である可能性があり、ドメインがマシン由来の成果物に現れないこともあり、攻撃者インフラが被害者を記録する前に障害を起こすこともある。
したがって、この報道はあらゆる疑問を解決することなく、インシデントの緊急性を高めている。組織は実際の露出状況を確立するため、ローカルのインストール記録、ネットワークテレメトリー、クラウド監査ログ、認証情報履歴を必要とする。
信頼されたAIパッケージが配信手段になった
LiteLLMの侵害が危険だったのは、攻撃者が盗みたい認証情報そのものの近くで日常的に動作するからだ。
LiteLLMは、異なる大規模言語モデルサービスを呼び出すアプリケーション向けに共通のインターフェースを提供する。開発者は個別の統合を維持する代わりに、1つのプロキシまたはPythonライブラリを通じてリクエストをルーティングできる。
この利便性により、LiteLLMはOpenAI、Anthropic、クラウドホスト型モデル、その他のプロバイダー向けAPIキーの近くに置かれる。本番環境のデプロイでは、データベース、オブザーバビリティプラットフォーム、クラウドストレージ、内部サービスにもアクセスできる場合がある。
攻撃者は2026年3月24日、悪意あるLiteLLMバージョン1.82.7および1.82.8を実際のPyPIプロジェクトへ公開した。これらはスペルミスを利用した模倣パッケージではなかった。ユーザーがすでに信頼していた配布チャネルを通じて届けられた。
Wizは、これらのバージョンが約8時30分UTCに出現し、PyPIが11時25分UTCにプロジェクトを隔離したと報告した。悪意あるパッケージの分析では、Wizが観測したクラウド環境の36％でLiteLLMが見つかったことも示されている。
バージョン1.82.7は、ソフトウェアがLiteLLMのプロキシコードをインポートした時、またはプロキシを起動した時にペイロードを有効化した。バージョン1.82.8では、litellm_init.pthというPython起動ファイルが追加された。
Pythonはsite-package環境を初期化する際に.pthファイルを処理する。そのため、悪意あるコードは、アプリケーションがそのセッション中にLiteLLMを一度もインポートしなくても、Pythonが起動するたびに実行される可能性があった。
この仕組みは、依存関係の露出に関する一般的な前提を崩す。開発者が明らかに侵害されたコマンドを起動する必要は必ずしもなかった。該当バージョンをインストールするだけで、環境内に自動実行フックが配置され得た。
その後、マルウェアはメモリ、環境変数、設定ディレクトリ、シェル履歴、一般的な認証情報保存場所を探索した。収集した資料を暗号化してから、LiteLLMの正規ドメインを模倣した攻撃者管理インフラへ送信した。
標的データにはAWS、Google Cloud、Microsoft Azureの認証情報が含まれていたとされる。窃取ツールはさらに、Kubernetesトークン、Docker設定、データベースパスワード、暗号資産ウォレット、秘密鍵、CI/CDシークレットを探した。
Datadogのキャンペーン調査は、影響を受けたバージョンをインストールしたあらゆるシステムを、完全な認証情報露出として扱うよう助言している。この立場は、発見されたすべてのシークレットが攻撃者に届いた証明ではなく、マルウェアの収集挙動を反映したものだ。
LiteLLMのメンテナーは、侵害されたバージョンを削除し、メンテナー認証情報をローテーションしたと述べた。また、依存関係が固定されていたため、プロキシDockerイメージのユーザーは影響を受けなかったとしている。
メンテナーらはMandiantを起用し、リポジトリとビルドシステムを確認する間、リリースを停止した。公開された対応では、この公開アカウントの侵害を、先行するTrivyインシデントで露出した認証情報と結び付けている。
こうした封じ込め措置は、新たな感染を減らした。しかし、すでに送信されたデータを回収することも、盗まれたすべての認証情報を自動的に無効化することもできなかった。そのため、対処はパッケージのアンインストールをはるかに超える必要があった。
本当の対立は、信頼された自動化と限定的なアクセス権限の間にある
このインシデントは、自動化されたソフトウェア配信の速度と、どの依存関係にも無制限の認証情報を継承させるべきではないというセキュリティ原則を対立させている。
現代のビルドパイプラインは、多数の外部プロジェクトからコード、ツール、コンテナ、アクションを取得する。自動化はリリースの再現性を高めるが、各依存関係は組織の実効的なセキュリティ境界の一部となる。
Trivyはこの問題をよく示している。これはコンテナやソフトウェア成果物の脆弱性を見つけるために使われるセキュリティスキャナーだ。検査にはソースコード、レジストリ、ビルド出力へのアクセスが必要なため、チームはスキャナーに広範な可視性を与えることが多い。
3月19日、攻撃者はTrivyのリリースおよびGitHub Actionsエコシステムの一部を侵害した。Datadogによると、悪意あるコンポーネントはGitHubホスト型ランナーのメモリをスクレイピングし、一般的な認証情報保存場所を探索した。
その後、攻撃者は盗んだアクセス権を他のプロジェクトやパッケージシステムで再利用したように見える。キャンペーンは、悪意あるLiteLLMリリースがPyPIに現れる前に、Checkmarx関連のアクションと拡張機能へ到達した。
この一連の流れは、通常のセキュリティモデルを逆転させる。安全でないソフトウェアを検出するためのスキャナーが、広く利用される別のパッケージを侵害するのに役立つアクセスの上流供給源となった。
このキャンペーンはまた、署名済みまたは公式のパッケージ名だけでは信頼性の判断を終えられない理由を示している。本物のレジストリに配置されていることは、成果物の出所を確認するものだ。公開者アカウントやビルドパイプラインが安全なままであったことを保証するものではない。
自動アップグレードは緊張を高めた。チームは、小規模なバージョン更新には互換性のある修正が含まれると期待し、パッチリリースを素早く反映させることが多い。攻撃者は、正規プロジェクトを通じて悪意あるバージョンを公開することで、この期待を悪用した。
バージョン固定はこの経路を遅らせられるが、完全な防御ではない。特にレジストリ上の識別情報やリリース番号が通常どおりに見える場合、チームは汚染されたバージョンを意図して承認してしまう可能性がある。
暗号学的ハッシュ検証は、正確な成果物を確認するため、より強い制御を提供する。ただし、インストール前にどのハッシュが信頼できるかを誰かが確立しなければならない。同じ侵害チャネルから悪意あるハッシュをコピーすれば、攻撃をそのまま維持するだけだ。
プライベートパッケージミラーは、外部成果物が本番環境へ到達する前にレビューと遅延を追加する。ただし、これも保護、監視、最新状態の維持が必要な別の機密サービスを生み出す。
より深い制御は認証情報の分離だ。ビルドジョブ内で実行される依存関係には、その特定のタスクに必要な権限だけを与えるべきである。短命な認証情報は、盗まれたコピーが継続的なアクセスを与える前に期限切れになるべきだ。
ワークロードアイデンティティは、静的シークレットをジョブまたはサービスに紐付く一時的な認証情報に置き換える。このアプローチは、侵害されたランナーから収集されるファイルや環境変数の価値を下げる。
組織には、独立したビルド段階も必要だ。スキャンジョブに、パッケージ公開、クラウドアカウント管理、本番データベースへのアクセス、無関係なリポジトリの変更まで許可する必要はほとんどない。
多くのパイプラインはいまも、利便性のためにこれらの権限を組み合わせている。1つのプロセスがあらゆるデプロイメントサービスへ到達できる場合、1つの汚染された依存関係がソフトウェア更新を組織全体のアイデンティティインシデントへ変え得る。
LiteLLM攻撃がこの弱点を生み出したわけではない。AIミドルウェアがアプリケーション、モデルプロバイダー、クラウド、データベース、オブザーバビリティシステムの間に位置するとき、この弱点がどれほど急速に深刻化するかを露呈させた。
LiteLLMをアンインストールするだけでは不十分だった
悪意あるパッケージを削除すれば実行経路の一つは止められるが、そのコードが動作していた間にコピーされたシークレットが失効するわけではない。
認証情報の窃取は、通常のマルウェア駆除とは異なる対応課題を生む。マシンを再構築すればバックドアは排除できるが、攻撃者が別のシステムからも使える有効なキーを保持している可能性は残る。
影響を受けたすべての環境で、認証情報の棚卸しが必要になる。セキュリティチームは、露出期間中にメモリ、ファイル、環境変数、シェル履歴、マウントされたサービスアカウントのディレクトリに存在したシークレットを特定しなければならない。
ローテーションの対象には、クラウドアクセスキー、AIプロバイダーのキー、データベースのパスワード、リポジトリトークン、SSHキー、Kubernetesサービスアカウント、パッケージレジストリの認証情報、Webhookシークレット、署名用マテリアルを含めるべきだ。
順序も重要である。チームはまず不審なアクセスを制限し、証拠を保全し、代替のIDを作成する。その後、依存するサービスを更新してから露出した認証情報を無効化すれば、制御不能な障害を起こさずに済む。
クラウドの監査ログは、盗まれたキーが通常と異なる場所から使用されたかどうかを明らかにできる。リポジトリの履歴からは、想定外のクローン、トークン作成、ワークフロー変更、リリース活動、権限変更を確認できる。
パッケージメンテナーには追加の責任がある。感染したランナー上に公開トークンが存在した場合、そのトークンで到達可能なすべてのパッケージをレビューする必要がある。攻撃者はアクセス権の悪用を待つことができる。
.pth を使った永続化手法は、Python環境そのものを直接検査すべきことも意味する。LiteLLMをアンインストールしても、site-packages に独自作成された起動ファイルは削除されない可能性がある。
公開されたインシデントタイムラインでは、litellm_init.pth の確認と、影響を受けたシステムに存在したすべての認証情報のローテーションが推奨されている。また、攻撃者が制御する models.litellm.cloud エンドポイントも特定している。
防御側は、既知のコマンドインフラへの接続をネットワークログで検索すべきだ。プロセス記録、異常なPython起動、アーカイブ作成、想定外に高権限なKubernetes Podも確認する必要がある。
ただし、数か月の経過は可視性の空白を生む。保持期間が短ければ、調査開始が遅れた時点でエンドポイントやネットワークの記録が消去されている可能性がある。
この空白こそ、今回報告されたデータ公開がいま重要である理由だ。3月時点で明白な侵入を見つけられなかった組織も、回収された資料に自社ドメインが現れれば新たな手掛かりを得られるかもしれない。
それでも、調査担当者は研究者の検索ツールを最終的な権威として扱うべきではない。ドメインの一致は、公開設定、クローンされたソースコード、ベンダーへの言及、顧客リストに由来する場合がある。
反対の誤りも同様に危険だ。即座にデータ流出を証明できないからといって、一致を軽視すべきではない。認証情報ログ、インストール記録、依存関係のロックファイルは、より強い証拠を提供できる。
チームは間接的なインストールも確認すべきだ。別のフレームワーク、社内ツール、テスト環境がパッケージを導入していたため、開発者自身はLiteLLMを選択したことを覚えていないかもしれない。
ソフトウェア部品表は、こうした関係を追跡する助けになる。部品表には、アプリケーションまたはビルド成果物に含まれるコンポーネントとバージョンが記録される。
ただし、完全なコンポーネント一覧であっても、実行中にどの認証情報が参照可能だったかは明らかにできない。依存関係の証拠は、実行時のIDおよびアクセス記録と組み合わせる必要がある。
調査メモ、認証情報のタイムライン、是正判断を残す必要がある開発者にとっては、検索可能な技術ナレッジベースが、断片化した証拠を減らす助けになる。機密のシークレットそのものを一般的なメモにコピーしてはならない。
数字だけでは証明できないこと
報告された規模は憂慮すべきものだが、入手可能な証拠だけでは、2,500件の完了したネットワーク侵入や195TB分の固有の認証情報を裏付けることはできない。
Ars Technicaは、この新たな規模をセキュリティ研究者による分析に帰している。根本にあるパッケージ侵害は、複数の技術調査とLiteLLMメンテナーの対応によって独立に裏付けられている。
その後に示された被害組織数は、研究者が盗まれた成果物を組織にどう対応付けたかに左右される。公開報道は、すべての一致を再現したり、顧客、ベンダー、開発者、参照された第三者を区別したりするには、まだ十分な詳細を提供していない。
企業ドメインがソースコードに現れても、そのコードが当該ドメイン所有者のシステムから取得されたことの証明にはならない。テストフィクスチャ、メールアドレス、依存関係メタデータ、ドキュメントには、いずれも外部の名称が含まれ得る。
研究者は複数のシグナルによって帰属を強化できる。これには、内部ホスト名、非公開リポジトリのパス、クラウドアカウント識別子、組織固有のトークン、ランナー名、一致するタイムスタンプが含まれる。
それでも、「影響を受けた」という表現は複数の状態を指し得る。ある組織はマルウェアを実行していたかもしれず、別の組織はすでに失効済みのキーを露出していたかもしれず、さらに別の組織はコピーされたドキュメント内にのみ現れた可能性がある。
434,000という数字にも文脈が必要だ。これがファイル、レコード、パイプライン実行を表すなら、同数の異なる侵害済みパイプラインとして提示すべきではない。
報告された195TBの収集データにも、同様の注意が必要である。生の窃取アーカイブには、重複したディレクトリ、大きなバイナリ、モデルファイル、キャッシュ、ソースリポジトリ、ログが含まれ得る。
195TBすべてを「認証情報」と呼ぶのは、こうした違いを劇的な見出しへと圧縮してしまう。認証情報の占める容量は小さい一方、それらを取り巻く環境は非常に大きくなり得る。
表現を最大限に煽らなくても、実務上のリスクは深刻なままである。有効なクラウド管理者キーを一つ含む小さなテキストファイルは、機密性のないビルド成果物を何TBも集めたものより重大になり得る。
名前が挙がった組織にも公正な扱いが必要だ。露出データセットに現れたことは、過失、継続中の侵害、または本番システムからのデータ窃取を立証するものではない。
掲載された組織の一部は、当初の対応時に認証情報をローテーションしていた可能性がある。また、別の組織名やドメインは、当該組織自身ではなくベンダーの環境内に現れたものかもしれない。
攻撃者がデータセットを保有していることと、それを使用したことは別の問題である。研究者はこのキャンペーンに関連する資料を入手または分析したと報じられているが、公開証拠は、すべての認証情報がどの程度広範に悪用されたかを示していない。
認証情報の有効性は時間とともに変化する。一時トークンは数分で失効し得る一方、古いSSHキーや固定API認証情報は数か月から数年にわたり機能し続ける可能性がある。
最も重大な不確実性は、長期間有効なシークレットに関するものだ。露出した組織が明白なAIキーだけをローテーションしていた場合、攻撃者は忘れられたデプロイトークンやサービスアカウントを通じてアクセスを維持しているかもしれない。
したがって、この公開は、確認済みのマルウェアイベントに裏付けられた調査上の手掛かりとして扱うべきである。データセット内のすべてのドメインに対する最終的な侵害判断にしてはならない。
この均衡の取れた枠組みは、二つの失敗を避ける。誇張された被害者数が証拠を追い越すことを防ぎ、不確実性が何もしないための言い訳になることも防ぐ。
危機が封じ込められたかを示す三つのシグナル
次の段階は、認証情報のローテーション、独立して検証された被害組織の調査結果、パッケージ公開セキュリティにおける測定可能な改善にかかっている。
第一のシグナルは、3月の封じ込め期間後に認証情報が悪用された証拠である。クラウドプロバイダー、パッケージレジストリ、影響を受けた組織は、盗まれたIDが後続のアクセスを可能にしたかどうかを開示すべきだ。
休眠中の公開トークンが使用されたことが確認されれば、このキャンペーンが長期的なサプライチェーン脅威を生んだという見方は強まる。悪用が観測されないことは当面の懸念を和らげるが、それは監査範囲が十分な場合に限られる。
第二のシグナルは、露出データセットの独立した検証である。より多くの組織が、研究者による一致結果をインストールログ、クラウド識別子、ネットワークテレメトリーと比較すべきだ。
一貫した確認は、報告された規模を支持することになる。広範な誤一致や重複レコードが判明すれば、確認済みのLiteLLM侵害自体を覆すことなく、推定される影響範囲は狭まる。
第三のシグナルは、より安全な公開および実行時制御の採用である。PyPIの信頼された公開モデルは、再利用可能なアップロード認証情報ではなく、短命なIDトークンを使用する。
より広範なサプライチェーンレビューでは、信頼された公開、成果物ハッシュの検証、制限されたサービスアカウント、想定外のPython起動ファイルの監視が推奨されている。この文書は、AIミドルウェアを下流の認証情報が集中する地点として特定している。
開発者は完璧な被害者リストを待つべきではない。LiteLLM 1.82.7または1.82.8をインストールした人は、その環境を露出済みとして扱い、アクセス可能だったすべての認証情報が変更済みであることを確認すべきだ。
セキュリティチームは、3月19日以降のTrivy関連の露出も確認すべきである。このキャンペーンの連鎖は悪意あるLiteLLMリリースが現れる前に始まっており、一つのパッケージだけに注目すると上流の侵害を見落としかねない。
影響を受けたバージョンが見つからない組織も、依存関係ポリシーを見直すべきだ。次の汚染されたパッケージが、LiteLLM、Python、あるいは同じ永続化メカニズムを使うとは限らない。
Ars Technicaの報道から得られる中心的な教訓は、その巨大な数字が示唆するものより限定的で、かつ行動に移しやすい。信頼された自動化が、価値の高いIDを第三者コードの隣に置き、一つの侵害された連鎖が多くのシステムに及んだ。
今日、具体的に一つ問いかけてほしい。最も強い権限を持つビルド認証情報を読み取れる外部パッケージはどれか。答えが明確でないなら、次の通常アップデートが隠れた信頼をインシデントに変える前に、そのアクセスを可視化すべきだ。
