MENU
カンボジア×IT情報を発信！
  1. ホーム
  2. AIニュース
  3. AI開発基盤LiteLLMが侵害され、企業の認証情報が流出

AI開発基盤LiteLLMが侵害され、企業の認証情報が流出

AIニュース
AIブログアイキャッチ - AI開発基盤LiteLLMが侵害され、企業の認証情報が流出

こんにちは！AIフル装備 powered by みらいラボのモモです。

企業がAIを業務に組み込む動きが広がるにつれて、その裏側を支える開発ツールの安全性が新たな注目点になっています。AIモデルを呼び出す仕組みそのものが攻撃の入り口になれば、影響は一社にとどまりません。

今回取り上げるのは、複数のAIモデルを一つの窓口でまとめて呼び出せる「LLMゲートウェイ」ソフトウェアLiteLLMをめぐるサプライチェーン攻撃です。セキュリティ企業CloudSEKの調査により、2500社を超える組織と43万件超のCI/CDパイプラインが影響を受けた可能性があると2026年8月11日に公表されました。

この記事では、攻撃がどのように連鎖したのか、なぜ一つのツールの侵害がここまで広がったのか、そして企業が今すぐ確認すべき点を整理してお伝えします。読み終えたときに、自社の開発環境で何を見直すべきかが分かる内容を目指しました。

AIブログ4コマ漫画 - AI開発基盤LiteLLMが侵害され、企業の認証情報が流出
目次

背景——AIゲートウェイLiteLLMとは何か

まず前提として、LiteLLMがどのような立ち位置のソフトウェアなのかを確認しておきます。企業がAIを実務に使う際、複数のAIモデルを併用する場面は珍しくありません。

LiteLLMは、OpenAIやAnthropicなど異なる提供元のAIモデルを、同じ書式のAPIで呼び出せるようにする中継役のソフトウェアです。PyPI上での月間ダウンロード数は2026年8月時点で7億件を超えるとされ、多くの企業の開発基盤に組み込まれています。

こうした中継ソフトウェアは目立たない存在ですが、AIを使うほぼ全ての処理が通過する要所でもあります。だからこそ、そこが攻撃されたときの影響範囲は非常に大きくなります。

複数のAIモデルを束ねる基盤としての役割

LiteLLMを導入する企業は、モデルごとに異なるAPI仕様を個別に実装する手間を省けます。コスト管理やアクセス制御をまとめて行える利便性も評価され、スタートアップから大企業まで幅広く採用されてきました。

利用企業には今回の被害報告でNVIDIAやAWS、Cisco、Salesforceといった名前も挙がっています。単一の中継ソフトが幅広い業種の基盤になっていた実態が、被害範囲の大きさからも見えてきます。

LLMゲートウェイのような中継ソフトウェアは、企業がAI活用を本格化させた2025年以降、急速に採用が広がってきた分野です。特定のAIモデルへの依存を避けつつ、用途に応じて呼び出し先を切り替えられる柔軟性が評価されてきました。

利用料金の一元管理やアクセス権限の制御をまとめて行える点も、複数チームでAIを使う企業にとって導入の後押しになっています。便利さゆえに、多くの開発チームが検証よりも導入のスピードを優先してきた面も否めません。

セキュリティスキャナーTrivyとの接点

今回の侵害の起点になったのは、LiteLLM自体ではありませんでした。LiteLLMの開発チームがCI/CD(継続的インテグレーション)の中でコードの脆弱性を検査するために使っていた、オープンソースのセキュリティスキャナーTrivyが先に侵害されていたのです。

セキュリティを守るための道具が逆に攻撃の足がかりになったという構図は、開発現場に強い警戒感を広げました。攻撃グループTeamPCPは、この構図を悪用してLiteLLMの奥深くまで侵入しました。

攻撃グループTeamPCPは、同じ2026年3月のキャンペーンの中で、脆弱性管理ツールCheckmarx KICS（LiteLLM侵害の前日にあたる3月23日に発覚）も侵害しており、Trivy・KICS・LiteLLMの3件は並行する複数のベクターだったとされています。さらに同グループは2026年2月下旬にも一度Trivyを侵害しており、その際に完全には失効しなかった認証トークンが、3月の侵害につながる約20日間の窓を生んだと報告されています。

開発チームが信頼して導入する検査ツールを次々と標的にする手口は、TeamPCPに共通する特徴だと指摘されています。守りのための道具ほど深い権限でCI/CD環境に組み込まれているため、侵害されたときの影響が大きくなりやすいという構造的な弱点も浮かび上がっています。

今回の変化——Trivyから連鎖した侵害の全体像

ここからは、実際に何が起きたのかを時系列で見ていきます。攻撃はいくつもの段階を経て、静かに、しかし着実に進みました。

攻撃グループTeamPCPは、まずTrivy側で公開されているタグとバイナリそのものを侵害しました。LiteLLMのCI/CDパイプラインはTrivyをバージョン固定せずに取り込んでいたため、汚染されたスキャナーがそのままビルド環境に流れ込んだとみられています。

流れ込んだ汚染版TrivyはGitHub Actionsのランナー上で動作し、プロセスメモリを直接読み取ることでGitHubの秘密情報マスキングを回避し、PyPI公開用の認証トークンを平文で窃取したと報告されています。

トークン窃取から5日後、TeamPCPはこの認証情報を使って正規のメンテナーになりすまし、LiteLLMの正式なCI/CDを経由せずに、直接PyPIへ悪意あるパッケージをアップロードしました。バージョン1.82.7と1.82.8がそれに当たります。

攻撃の経路——Trivyから侵害が連鎖した仕組み

攻撃の全体像を把握するために、主要な出来事を時系列で整理します。侵害の発生から公表までに約5カ月かかっている点にも注目してください。

主要な攻撃タイムライン

時期出来事
2026年2月下旬前回インシデントで漏洩した認証トークンが完全には失効せず、侵入可能な窓が残る
2026年3月19日その窓を突いてTrivyの公開タグ・バイナリが侵害される（同日Trivy側が検知し除去）
2026年3月24日窃取した認証情報でLiteLLM 1.82.7/1.82.8をPyPIへ直接公開
同日・約40分後PyPIが異常を検知し該当パッケージを隔離
2026年8月11日CloudSEKが影響範囲の調査結果を公表

悪意あるパッケージがPyPI上に存在したのはわずか40分ほどでした。しかし自動化されたCI/CD環境では、依存パッケージが人手を介さず即座にダウンロード・実行されるため、短時間の公開でも被害が拡大しうる点が今回はっきり示されました。

  • 自社がLiteLLMを直接使っていなくても関係あるのか
  • 影響を受けたか、どう確認すればよいのか
  • パッケージを最新版に上げれば解決するのか

これらの疑問はもっともです。LiteLLMの公式Dockerイメージを利用していた場合は影響を受けていないとされていますが、PyPI経由でパッケージを直接インストールしていた場合は、該当バージョンを利用していないか確認が必要です。

影響有無の確認には、依存関係のログとビルド実行時刻の照合が欠かせません。単にバージョンを最新化するだけでなく、対象期間にアクセス可能だった認証情報の洗い出しまで行う必要があります。

今回の手口が厄介なのは、正規のビルドパイプラインを一切経由していない点です。通常であればコードレビューやテストを経てから公開されるはずのパッケージが、窃取したトークンを使って直接PyPIへ送り込まれたため、通常の品質管理では検知できませんでした。

被害の規模——2500社・43万パイプラインという数字の重み

CloudSEKの報告によれば、影響が及んだ可能性がある組織は2500社を超え、関連するCI/CDパイプラインは43万件規模に上るとされています。これは2026年に確認されたAI関連のサプライチェーン侵害としては最大級の規模です。

CloudSEKが公開した露出データセットには、AWS、Cisco Systems、Salesforce、Siemens AGなど、金融・通信・製造・防衛分野に及ぶ大手企業の名前が高確度の一致として挙がりました。ただしCloudSEK自身も「高確度はあくまで露出の一致度を示すものであり、侵害が実際に成立した証拠ではない」と明記しています。

被害範囲の内訳を見ると、テクノロジー企業だけでなく、金融や製造業など、AIを直接の主力事業としていない企業も多数含まれています。業務でAIを使うこと自体が当たり前になった結果、被害の裾野も業種を問わず広がったと言えます。

影響——AI開発企業への衝撃

侵害の技術的な仕組みが分かったところで、次に実際にどのような情報が奪われ、どんな二次被害につながったのかを見ていきます。

窃取が確認されたデータには、クラウドの認証キー、リポジトリのトークン、SSH鍵、Kubernetesのシークレット、パッケージ公開用の認証情報、環境変数、そしてAI提供各社のAPIキーが含まれていました。

特に今回はAI各社が発行するAPIキーそのものが盗まれた点が特徴的です。単なる社内システムの認証情報流出とは異なり、AIサービスの利用そのものが悪用されるリスクを伴います。

認証情報流出で何が奪われたか

報告されている攻撃の内部構造では、まずroot権限まで昇格したうえで、SSH鍵やクラウド認証情報などを広範囲に収集したとされています。その後、Kubernetesクラスター内に持続的なバックドアを設置する動きも確認されています。

  • 第1段階：root権限への昇格とSSH鍵・クラウドトークン・環境変数などの収集
  • 第2段階：Kubernetesクラスター内への持続的なバックドアの設置

この設計は、単発の情報窃取ではなく、侵入後も長期にわたって足場を維持する狙いがうかがえます。FBIも2026年7月、窃取された認証情報が今後さらに悪用される恐れがあるとして注意喚起のFLASH勧告を出しています。

攻撃者がここまで手間をかけて足場を残そうとした背景には、認証情報のローテーションが完了する前に別の侵入経路を確保しておく狙いがあったとみられます。単に情報を持ち去るだけでなく、発見・対処された後も影響を残す設計だったと言えます。

巻き込まれた大手企業と業界への波紋

今回の被害範囲には、AI開発を積極的に進める企業自身も含まれていました。AIチップを手がける企業やクラウド大手が名を連ねたことは、AI業界全体にとって皮肉な事態と言えます。

自社のAI活用を進める企業ほど、こうした中継ソフトウェアへの依存度が高くなりがちです。今回の一件は、便利さの裏にあるリスクを可視化した事例として、業界内で広く共有されています。

セキュリティ業界からの評価

複数のセキュリティ企業が今回の事案を詳細に分析し、公開しています。Kasperskyなどは、セキュリティスキャナー自体が攻撃の武器に転じた点を、本来守るはずの仕組みが牙を剥いた事例として位置づけています。

こうした分析が相次いで公表される背景には、同種の手口が他の開発ツールにも広がる懸念があります。一つのベンダーの対応だけでなく、業界全体でビルド環境の権限管理を見直す必要性が指摘されています。

一方で、TrivyやLiteLLMのような無償のオープンソースツールに、企業がどこまで運用体制の投資を割けるかという課題も指摘されています。無償で便利だからこそ、検証や監視が後回しにされやすい構造があります。

今後の注目点——公式対応と企業が取るべき備え

最後に、LiteLLM側の公式対応と、今回の事件から企業が学ぶべき点を整理します。従来型のサプライチェーン攻撃と比べても、今回は攻撃の入り口が一段階増えている点が特徴的です。

従来の多くのサプライチェーン攻撃は、対象ソフトウェア自体の依存関係を直接狙うものが中心でした。今回はセキュリティ検査ツールという、本来は守る側であるはずの仕組みが最初の侵入口になった点が、従来型との明確な違いです。

日本企業の多くも、コスト最適化やモデル切り替えの柔軟性を求めてLLMゲートウェイ型のツールを検討し始めています。今回のような事例を踏まえ、導入時点からセキュリティ体制まで含めて評価する視点が欠かせません。

LiteLLM公式の対応内容

LiteLLM側は公式インシデントレポートで、侵害の起点がCI/CDのセキュリティスキャンで使っていたTrivy依存関係にあったと明らかにしています。公式のLiteLLM Proxy Dockerイメージを利用していた顧客は影響を受けていないとも説明されました。

同社は影響を受けた可能性がある組織に対し、該当する期間にアクセス可能だったCI/CDシークレットや公開用トークン、クラウド認証情報のローテーション（再発行）を呼びかけています。

こうした対応は、侵害の起点が自社のコードではなく外部の依存関係にあった場合でも、影響を受けた顧客への説明責任を果たす姿勢として評価できます。同時に、依存するツールの安全性を完全にはコントロールできないという、現代的なソフトウェア開発の難しさも浮き彫りになりました。

企業が今すぐ確認すべきこと

ここでは、LiteLLMを利用している企業がまず確認すべき点を整理します。技術的な詳細に踏み込むよりも、優先順位をつけて対応することが重要です。

  1. 該当期間にLiteLLMのPyPIパッケージを直接取得していないか、依存関係ログを確認する
  2. CI/CDで使う公開トークンやクラウド認証情報を対象期間分ローテーションする
  3. Kubernetes環境で不審な権限昇格やポッドの展開履歴がないか点検する
  4. 利用しているセキュリティスキャナー自体の供給網（ビルド環境・配布経路）も定期的に見直す

これらの対応は、LiteLLMを直接使っていない企業にとっても参考になります。自社が使う開発ツールチェーンのどこかに、同じような「検査ツールが攻撃の起点になる」リスクが潜んでいないか、棚卸しをする良い機会だと言えます。

開発ツール全体で求められる備え

TrivyとCheckmarx KICSが同じキャンペーンで相次いで侵害されたように、開発ツールの供給網を狙う攻撃はLiteLLMだけの問題ではありません。ビルドパイプラインの奥深くに位置する道具ほど、日常的な監視の目が届きにくいという共通の弱点があります。

今後は、ソフトウェア部品表(SBOM)の整備や、CI/CD環境そのものへのゼロトラストの考え方の適用が、業界全体でどこまで進むかが注目されます。便利な自動化を維持しながら、供給網のどこに弱点が残っているかを継続的に点検する姿勢が求められています。

まとめ

今回は、AIモデルを束ねる中継ソフトウェアLiteLLMが、セキュリティスキャナーTrivyの侵害を経由してサプライチェーン攻撃を受け、2500社超・43万件規模のCI/CDパイプラインに影響が及んだ可能性がある件を取り上げました。

このニュースが重要なのは、攻撃の対象が「AIモデル」そのものではなく、AIを使うための土台となる開発ツールだった点にあります。AI活用が広がるほど、こうした土台の安全性が企業のリスク管理に直結するようになってきています。

今後は、CloudSEKやLiteLLM側からの追加情報、実際に被害を受けた企業側の対応状況、そして他のオープンソース開発ツールにも同様の侵害が広がっていないかという点に注目していきたいところです。セキュリティ検査ツール自体の供給網を守る動きが、業界全体でどこまで進むかも見ていく必要があります。

特に日本国内でもAIゲートウェイ型のツールを導入する企業が増えているため、今回のような事例は対岸の火事ではありません。国内企業がどう対応を進めるかも、引き続き注視したいところです。

読者の皆さんも、自社やチームが使っている開発ツールの供給網について、一度確認してみてはいかがでしょうか。

私自身、AIの便利さを日々実感している立場として、今回の件は他人事ではないと感じました。便利なツールに頼るほど、その裏側にある土台の安全性まで含めて選ぶ視点が必要だと思います。

参考サイトまとめ

AIニュース
AIセキュリティ CI/CD LiteLLM オープンソース サプライチェーン攻撃
よかったらシェアしてね！
  • URLをコピーしました！
  • URLをコピーしました！
Random Image

関連記事

コメント

コメントする

目次