LiteLLM×TeamPCP続報：434K CI/CD暴露の被害全貌とFBI警告・自システム確認コマンド

2026年3月にAIプロキシOSS「LiteLLM」がPyPIで侵害された事件は、当時「配布パッケージにマルウェアが混入した」と報じられた。だがそれは氷山の一角だった。8月に入り、TeamPCPと名乗る攻撃グループによる一連のサプライチェーン攻撃の被害規模が実測として公表され、CloudSEKは「434,000のCI/CDパイプライン・2,500組織超」の潜在暴露を報告、FBIも窃取された認証情報の長期悪用を警告している。

本記事は、当サイトが3月に速報したLiteLLM 1.82.7/1.82.8がPyPIで侵害 — サプライチェーン攻撃で緊急アップデート推奨の続報として、①被害規模の実測と「なぜ数値が出典で割れるのか」、②連鎖（カスケード）の時系列、③IOC、④後続のCVE波、⑤実際に動かして検証した自システム確認コマンドを、一次ソース（GitHub Advisory・Datadog・CloudSEK・PyPI）に絞って整理する。セキュリティ全般の地図はサプライチェーンセキュリティ2026｜攻撃手法・防御ツール・実践チェックリストを参照してほしい。

TeamPCPとLiteLLM事件——いま分かっている被害全貌

3月の初報時点で分かっていたのは「LiteLLMの1.82.7と1.82.8がPyPIで侵害され、認証情報を盗む」ことだった。8月までに明らかになったのは、それが単発の事件ではなく、Trivyを起点に開発ツール群へ連鎖したTeamPCPキャンペーンの一部だったこと、そして被害の潜在規模が数十万CI/CDパイプライン級だったことだ。

そもそもなぜLiteLLMのようなAIプロキシが標的になったのか。LiteLLMは複数のLLMプロバイダを束ねる「AIゲートウェイ」として、多数の組織で各社のAPIキーやクラウド資格情報が集まる結節点になっている。攻撃者から見れば、1つのライブラリを汚染するだけで、それを使う全組織の「AI関連の鍵束」に手が届く——投資対効果が極めて高い標的だ。近年、AIインフラ（プロキシ・ゲートウェイ・エージェント実行基盤）が戦略的なサプライチェーン標的になりつつあるのは、まさにこの「鍵が集まる場所」という性質による。LiteLLM事件は、AIスタックの利便性の裏で、資格情報の集中がそのまま攻撃価値の集中になっていることを可視化した事例でもある。

攻撃の入口は皮肉なものだった。TeamPCPはまずセキュリティスキャナ Trivy を侵害し（CVE-2026-33634）、汚染されたTrivyが各所のCI/CDランナー環境で正当な読み取り権限を持って動いたことで、LiteLLM自身のCI/CDパイプラインからPyPIパブリッシュ用トークンが盗まれた。盗まれたトークンで悪意ある 1.82.7 / 1.82.8 がPyPIに公開された——つまり「防御ツールが侵害の踏み台になった」構図だ。

この構図が示す教訓は重い。多くの組織はCIに脆弱性スキャナやSBOM生成ツールを「安全のために」組み込むが、それらはリポジトリのソース・環境変数・クラウド資格情報に広い読み取り権限を持って動く。そのツール自体が汚染されれば、権限はそのまま攻撃者のものになる。TeamPCPはこの「信頼された自動化」の連鎖を突き、Trivy→Checkmarx→LiteLLM→Telnyxと、1つの資格情報窃取を次の侵害の足がかりに変えていった。防御の自動化が増えるほど、その自動化自身が新たな攻撃面になる——というのが今回の中核的な学びだ。

時系列（タイムライン）：Trivyから連鎖したサプライチェーン攻撃

TeamPCPの動きは1つの侵害が次を呼ぶ「カスケード」だった。この litellm サプライチェーン侵害を単独の点で見ると規模を見誤る——起点のTrivyから終点のTelnyx SDKまでを1本のタイムラインで追うと、なぜ被害が数十万CI/CD級に膨らんだのかが見えてくる。主要な出来事を時系列で並べる（日付は各社レポートおよびPyPI実データに基づく）。

PyPIの実データでも裏が取れる。クリーンな直前版 1.82.6 は3月22日にアップロードされ、汚染版 1.82.7 / 1.82.8 は現在PyPIから削除されて存在しない。復旧版 1.83.0 は3月31日にアップロードされている。

被害規模の実測と「数値が割れる」理由

ここが本続報の主役だ。被害規模の数値は出典ごとに違う。無理に1つへ丸めず、報告元ごとに併記する。

3点、読み解く際の注意がある。

・これは“確認された侵害”ではなく“潜在的な暴露の推計”：ダンプに資格情報が現れた≠その組織が侵害された、ではない。各社とも「露出した可能性」を数えている
・数値は独立した実測ではない：多くの媒体が報じているが、元をたどると CloudSEK（434K/2,500）と Hudson Rock（153GB/2,488ドメイン）の2社に集約される。The Hacker Newsの「2,100組織超」はCloudSEKより低い
・Hudson Rockの数値は自社サービスへの導線を伴う：被害照会サービスへ誘導する文脈で公表されている。数値自体はCloudSEKが独立に同規模（434K）を出しているため捏造ではないが、特定企業名の“暴露リスト”は「ダンプに登場した」という主張であって侵害の確認ではない

実務上は、この「潜在暴露」をどう自組織の判断に落とすかが問題になる。他社の集計値（434Kや2,500）は自社が影響を受けたかどうかの証拠にはならない——それらはあくまで攻撃の総量を示すマクロな指標だ。自組織の判断は、次節以降のIOC点検と「露出期間中に自社のCIランナーやリポジトリで汚染版に触れ得たか」という具体的な確認に基づいて行う。逆に言えば、数千組織という数字に萎縮するのでも楽観するのでもなく、自分の環境で1.82.7/1.82.8に触れる経路があったかを淡々と潰すのが正しい向き合い方だ。報道の大きな数字と、自組織のリスク評価は分けて扱う。

3段構成のマルウェアとIOC

汚染版に仕込まれたコードは3段構成だった。特に 1.82.8 は litellm_init.pth を site-packages に置き、litellmをimportしなくても任意のPython実行で自動発火するため、1.82.7より危険度が高い。

・①資格情報の収集：SSH秘密鍵・.env・AWS/GCP/Azure資格情報・.kube/configとKubernetesシークレット・DBパスワード・シェル履歴・暗号ウォレット等を走査。GHSAは「機微な資格情報とファイルを収集し、リモートAPIへ送信」と記述。送信は AES-256（データ）＋RSA-4096（セッション鍵）で暗号化しHTTPS POST
・②Kubernetes横展開：クラスタの各ノードへ特権Podを展開
・③systemd永続化：sysmon.service を仕込み、C2をポーリングして追加ペイロードを取得

送信データが暗号化されている点も検知を難しくしている。収集した資格情報はAES-256で暗号化し、そのセッション鍵をRSA-4096でさらに暗号化してHTTPS POSTで送るため、ネットワーク監視で「平文の秘密鍵が流れる」ような分かりやすい兆候は出ない。平文の窃取パターンではなく、下記のC2ドメインへの通信そのものを痕跡として探すのが現実的だ。また3段構成のうち③のsystemd永続化は、パッケージをアンインストールしても~/.config/systemd/user/に残るため、「litellmを消したから大丈夫」という思い込みが最も危険な穴になる。

主なIOC（Datadog Security Labsが確認、複数社が裏付け）：

なお同じキャンペーンで侵害された Telnyx SDK では、ペイロードを WAV音声ファイル（ringtone.wav）にステガノグラフィで隠す手口も確認されている（16バイトのフレームごとに8バイトのXOR暗号化データ＋8バイト鍵）。C2ドメインが正規サービス名をタイポスクワットしている点（checkmarx.zone）と併せ、TeamPCPは検知回避に相応の手間をかけている。IOCは「怪しいファイル名」だけでなく、一見無害な拡張子・正規に似たドメインまで視野に入れて探す必要がある。

後続CVE波：CVE-2026-42208（事前認証SQLi・CISA KEV）

供給チェーン侵害とは別系統で、4月にLiteLLMプロキシ本体の脆弱性も相次いで公表された。最重要は CVE-2026-42208——事前認証（valid APIキー不要）のSQLインジェクションで、プロキシのDBを改変され得る。NVDはCVSSを9.8とする（一部集計では9.3と表記）。公開から1〜2日（約26〜36時間）で実環境での悪用が観測され、5月8日にCISA KEVへ追加された。影響は v1.81.16〜v1.83.6、修正は v1.83.7-stable、LiteLLMは v1.83.10-stable 以降を推奨する。公開から実悪用まで1〜2日という速さは、「パッチが出てから週末をまたいで適用しよう」という悠長な運用では間に合わないことを意味する。CISA KEV入りは連邦政府機関に期限付き対応を課すが、民間でもインターネットに露出したLiteLLMプロキシは最優先で更新すべき対象だと考えたほうがよい。事前認証で悪用可能＝攻撃にvalid APIキーが要らないため、認証を掛けていても油断できない。

このほか、4月のハードニング告知で CVE-2026-35029（/config/update 悪用による権限昇格→RCEの恐れ）・CVE-2026-35030（enable_jwt_auth 有効時のみの認証バイパス。既定オフ）・GHSA-69x8-hrgq-fjj8（無塩SHA-256パスワードハッシュ／要APIキー）が開示された。「3月のパッケージ汚染は直したから安心」ではなく、プロキシ本体も新しい安定版へ上げる必要がある。

影響範囲：誰が・どのバージョンが対象か

影響を受ける条件は「供給チェーン侵害」と「プロキシ本体のCVE」で別なので、影響範囲を分けて整理する。

回避不能な条件として、1.82.8を入れた環境は litellm を import していなくても litellm_init.pth 経由でコードが発火済みの可能性がある点に注意する。バージョンを上げるだけでは.pthは残るため、後述のIOC除去とセットで対応する。

TeamPCP被害の自システム確認コマンド（実測済み）

以下は当環境で実際に実行し、構文と挙動を確認したコマンドだ。進行中のサプライチェーン事案では「載せて終わり」にせず動かして精度を確かめる方針に従っている。攻撃者が仕込むファイルパスでの探索を主軸に、まず未fetchブランチの取りこぼしを防ぐ。

# 0) 供給チェーン確認の先頭に置く（未fetchのリモートブランチを対象に含める）
git fetch --all --prune

# 1) 稼働環境に汚染版が入っていないか
pip show litellm 2>/dev/null | grep -i version
pip freeze | grep -i litellm

# 2) lockfile / requirements に汚染版が固定されていないか（全ブランチ横断）
grep -rnE "litellm==1\.82\.(7|8)" . --include=requirements*.txt \
  --include=poetry.lock --include=uv.lock --include=Pipfile.lock

次に、uninstallでは消えない永続化IOCとバックドアを点検する。litellm_init.pth はアンインストール後も残るため、バージョンを上げただけでは不十分だ。

# 3) 永続化 .pth（どのPython実行でも自動発火する）
find / -name 'litellm_init.pth' 2>/dev/null

# 4) systemd バックドアと状態ファイル
systemctl --user status sysmon.service 2>/dev/null
ls -la ~/.config/sysmon/sysmon.py ~/.config/systemd/user/sysmon.service \
       /tmp/pglog /tmp/.pg_state 2>/dev/null

# 5) C2への通信痕跡（DNS/プロキシログを検索）
grep -REi "models\.litellm\.cloud|checkmarx\.zone|83\.142\.209\.203" \
  /var/log 2>/dev/null

いずれか1つでも該当したら、その環境でlitellmが参照できた全ての資格情報は窃取済みと仮定し、次節の恒久対策へ進む。何も出なければ（当記事の検証環境ではlitellm未導入・IOCなしを確認）直接被害の可能性は低いが、CI/CDランナー側の点検は別途必要だ。

CI/CDランナーの点検が特に重要なのは、今回の窃取の主戦場が開発者のローカルPCではなくエフェメラルなCIランナーだったからだ。ランナーは実行のたびに使い捨てられるため、侵害の痕跡（IOCファイルやプロセス）が残りにくい一方、実行中は環境変数やOIDCトークン、クラウドの一時資格情報を潤沢に持つ。したがって「ローカルにIOCが無い＝安全」とは言えない。ランナーで過去に汚染版をpip installし得たか（キャッシュ・lockfile・ビルドログ）を洗い、疑わしければそのランナーが握っていた資格情報を期間ごとローテーションする。恒久対策としては、依存のハッシュピン留め（pip install --require-hashes）で「同じバージョン名でも中身が変わる」差し替えを検知し、Socketやpip-auditのような供給チェーン監視を導入して、パブリッシュ直後の悪性バージョンを自動で弾く体制にしておくとよい。

ローテーションは優先順位をつけて進めると現実的だ。まず「一度露出したら被害が連鎖しやすい」もの——パブリッシュ用トークン（PyPI/npm）、クラウドのルート/管理者級キー、CI/CDのOIDC・長命トークン、Kubernetesの管理者資格情報——を最優先で無効化・再発行する。次にAIプロバイダのAPIキー、DBパスワード、Dockerレジストリトークンを回す。単純な失効だけでなく、失効前に発行されたセッションやリフレッシュトークンが生きていないかも確認する。TeamPCPのように「盗んだ鍵で次を侵害する」相手には、取りこぼした1本の鍵が再侵入の入口になるため、ローテーションは「全部・同時に」が原則だ。

まとめ

LiteLLMの3月PyPI侵害は、Trivyから連鎖したTeamPCPキャンペーン（Google追跡名 UNC6780）の一部であり、8月に公表された被害の潜在規模はCloudSEKで434,000 CI/CDパイプライン・2,500組織超に及ぶ。ただしこの数値は“潜在暴露の推計”で出典により幅があり、確認された侵害数ではない——ここを分けて読むのが本続報の要点だ。やるべきことは明確で、①汚染版(1.82.7/1.82.8)を排除し安全版（1.82.6 か 1.83.0 以降、さらにCVE-2026-42208修正済みの v1.83.10-stable 以降）へ、②litellm_init.pth・sysmon.service 等のIOCを点検、③FBIが長期悪用を警告した資格情報を全ローテーションする。初報はLiteLLM 1.82.7/1.82.8がPyPIで侵害と開発者が分単位対応を公開した記録、同時期の連鎖事例はaxiosマルウェア混入事件も併せて参照してほしい。

参照ソース

・GitHub Advisory GHSA-5mg7-485q-xm76 — 汚染版・3段マルウェア・安全版（1.82.6/1.83.0）・資格情報ローテーション指示の一次情報
・Datadog Security Labs（TeamPCPキャンペーン解析） — IOC（ファイル・サービス名・C2）と検出クエリ
・CloudSEK — 434,000 CI/CD pipelines / 2,500 companies — 被害規模の実測（潜在暴露の推計）
・PyPI — litellm リリース履歴 — 1.82.6/1.83.0 の実在と汚染版の削除確認