あなたが確認した四十分は、間違っていた

8月14日、SecurityWeek の Ionut Arghire が、今年最大級の開発インフラ侵害について SOCRadar による再帰属を報じた。 SOCRadar はレコード単位のデータセットを保有しており、2,188 の組織それぞれについ て収集記録を持っていた。そして誰も問わなかった問いを立てた。各組織のデータは、 いつ出て行ったのか。

そのうち 2,085 組織では、収集は誰もが警告されたあの悪意あるパッケージが公開さ れるより前に終わっていた。95% である。SOCRadar の結論は一文で足りる。

「このタイミングは、LiteLLM のインストール時間帯ではなく、上流の Trivy 侵害と 一致する。誰もが報じたあの40分は、幕切れであって、芝居の全体ではない。」

研究者たちはペイロードを3月のうちに分解していた。SOCRadar が変えたのは時系列だ。 5か月のあいだ、業界は誤ったウィンドウに向けてインシデント対応を回し続けた。誰か が悪いものに名前を与えるまで何もできない制御を使って。

幕切れ

有名な四十分は LiteLLM のものだ。3月24日、バージョン 1.82.7 と 1.82.8 が 10:39 UTC に PyPI へ上がり、PyPI が隔離するまでおよそ四十分もった。当時の指針は、その 日の 16:00 UTC までに行ったインストールはすべて疑わしいものとして扱え、というも のだった。

このペイロードは、何を無効化するかという点で一度立ち止まる価値がある。正体は site-packages に置かれた .pth ファイル、litellm_init.pth である。Python は .pth ファイルをインタプリタ起動時に実行する。それを入れたパッケージを何かが import するかどうかとは無関係にだ。検査すべき setup.py もなければ、剥がすべき インストールスクリプトもない。だから --ignore-scripts も、インストールスクリプ ト実行モデルの上に築かれたあらゆる制御も、その脇を素通りする。The Hacker News は 8月12日に その仕組みを取り上げ、 エコシステム単位の識別子 CVE-2026-33634 に言及した。収集物の宛先は models.litellm[.]cloud だった。

攻撃者は盗んだ PyPI の公開トークンでそれらの wheel を押し上げ、LiteLLM 自身の リリースパイプラインを迂回した。ではそのトークンはどこから来たのか。

芝居の全体

Trivy である。Aqua Security のオープンソース脆弱性スキャナ。まさにこの種の問題を 見つけるために、数万のパイプラインが走らせているものだ。

Aqua の勧告 GHSA-69fq-xp46-6x23 は根本原因をぼかしていない。TeamPCP（Google の呼称では UNC6780）として追跡されて いる攻撃者が、2月下旬に pull_request_target ワークフロー経由で Trivy の GitHub Actions 環境から個人アクセストークンを抜き取った。Aqua は3月1日にそれを公表し、 資格情報をローテーションした。勧告はそのうえで、そのローテーションが「原子的では なかった（すべての資格情報が同時に失効されたわけではない）」と述べている。攻撃者 はローテーションの内側に居座り、Aqua が新しい秘密を発行するそばから回収していた。

19日後、攻撃者はそれを使った。3月19日、aquasecurity/trivy-action の77 個中 76 個のバージョンタグと、aquasecurity/setup-trivy の7 個すべてのタグを、 悪意あるコミットへ force-push した。その結果、@v0.28.0 に固定されたワークフロー が、リポジトリ上は何も変わって見えないまま新しいコードを取得した。侵害されたサー ビスアカウント aqua-bot を使い、攻撃者は Trivy v0.69.4 を GHCR、ECR Public、Docker Hub、deb、rpm に公開した。Docker Hub のイメージ v0.69.5 と v0.69.6 は、別途侵害された資格情報を使って3月22〜23日に続いた。

StepSecurity の解析 は、パイプラインがそれを実行した瞬間に、注入されたスティーラーが何をしたかを記述 している。

• /proc/*/environ を通じて、ランナー上のあらゆるプロセスの環境変数を読む。
• base64 エンコードされた Python を使い、/proc/<pid>/mem から GitHub Actions ランナーのワーカープロセスのメモリをダンプする。これによりランナーがログ上で マスクしている秘密が回収される。マスクはログのフィルタにすぎず、プロセスのメモ リはマスクされていない値を保持しているからだ。
• ファイルシステムを掃いて、SSH 秘密鍵、git の資格情報、AWS・GCP・Azure のトーク ン、Kubernetes のシークレット、Docker の設定、データベース資格情報、Terraform のステート、暗号資産ウォレットを集める。
• それらすべてを、ハードコードされた RSA-4096 公開鍵によるハイブリッド暗号で封 じ、scan.aquasecurtiy.org へ送り出す。

このホスト名をもう一度読んでほしい。ベンダー自身のドメインの、二文字が入れ替わっ たものだ。ドメイン評判フィードにとって、あるいは午前2時に外向き通信を流し読みする アナリストにとって、aquasecurity.org に見える相手と話しているスキャナは、その ページでもっとも目を引かない一行である。

アップロードが失敗した場合、スティーラーは被害者自身の GitHub アカウントに tpcp-docs という公開リポジトリを作り、戦利品をリリースアセットとして添付した。

SOCRadar が計測した最初の収集は、悪意あるビルドが公開された18分後だった。

パイプラインから出て行ったもの

Hudson Rock がそのアーカイブを入手し、Help Net Security が8月13日に その規模を報じた。 153 GB、433,909 ファイル、2,488 の企業ドメインに紐づく 118,829 件の CI ランナー ダンプ。CloudSEK の独立した集計はおよそ 434,000 ファイルで、露出はおよそ 2,500 組織、43万を超えるパイプラインに及ぶとした。Hudson Rock の CTO Alon Gal はこれを 「世界規模の倫理的開示の取り組み」と呼び、その規模は「必要とされる対応の種類とい う点で、我々をまったく新しい世界へ押し出す」と述べた。Kevin Beaumont の見立ては こうだ。「これは杜撰な AI セキュリティに起因する、巨大なサプライチェーン侵害だ。」

SOCRadar の組織別の内訳はさらに踏み込む。1,000 を超える組織が JWT と認証トークン を失った。数百が秘密鍵、AWS のアクセスキー、GitLab のトークン、OpenAI の API キー、 Slack の Webhook、GitHub Actions のトークン、Google の API キーを失った。ある組織 はおよそ 3,477 個の個別の秘密を失った。1,100 の組織がコミッターのメールアドレスを 露出させた。ランナーは GitHub Actions、GitLab CI、Jenkins、Bitbucket、CircleCI、 Buildkite だった。もっとも被害が大きかったのはドイツ、ブラジル、フランスで、収集 物は現在 Telegram で取引されている。

その連鎖上のどの制御にも、名前が要った

3月時点で存在していた防御を並べ、それぞれが動き出す前に何を必要としたかを書き出 してみよう。

勧告には、Aqua が侵害を特定することが要った。取り下げには、PyPI がパッケージを特 定することが要った。IoC のリストには、誰もが信頼するベンダー名の打ち間違いではな く敵対的なものとして scan.aquasecurtiy.org を読む人間が要った。「10:39 から 16:00 UTC のあいだにインストールしたか」というチェックリストには、正しい5時間が要 った。ドメイン評判には、そのドメインに評判があることが要った。2,085 の組織に対し て見ていた週が違うと告げた再帰属には、流出アーカイブが表に出てくることと、5か月後 に研究チームがそれに向き合うことが要った。

これらはどれも同定型の制御である。誰かがそのものに名前を与えたあとで、そのもの に対して動く。名づけはエコシステムが知識を共有するやり方であり、実際に機能してい る。だからこれは勧告を書く人々への苦情ではない。これは順序についての指摘だ。同定 型の制御は名づけのあとに到着する。そしてこのキャンペーンでは、各成果物が生きてい たのは3時間から12時間だった。公開から最初の収集までの18分が、その順序で十分だった のかという問いに答えている。

ここで結末を変える制御は、名前を必要としないもののほうだ。

神託ではなく、時計

Bromure Agentic Coding は、1 バイトも VM に届く前に、あらゆるパッケージ取得をホス ト側の MITM プロキシに通す。そして 年齢ゲートは、既定で有効になってい る唯一のサプライチェーン層である。これは、しきい値より若いパッケージバージョンを すべて拒む。既定は2日だ。

参照は一切行わない。メンテナについても、公開者についても、署名についても、名前に ついても、意見を持たない。公開タイムスタンプを読み、下限を適用するだけだ。その前 提はこうである。新鮮なリリースこそ1時間前に乗っ取られた可能性がもっとも高いもので あり、その窓が過ぎるのを待つことは、働いている開発者にとってほとんど何のコストに もならない。

このキャンペーンに対しては、それが戦いのすべてだ。LiteLLM 1.82.7 と 1.82.8 が存在 したのは四十分である。2日の下限は、VM の内側から見ればそれらが最初から存在しなかっ たことを意味する。プロキシは新しすぎるバージョンをレジストリのメタデータから取り 除き、latest とその他の dist-tag を、生き残っている最新バージョンへ向け直す。だ から pip install litellm もあらゆる semver 範囲も、エラーを出さずに 1.82.6 へ解 決し、エージェントが迂回する余地は何もない。汚染されたバージョンを厳密なピンで要 求すれば、成果物取得のバックストップが 451 を返し、その本文がパッケージの実際の年 齢を必要最小値と並べて示す。pip はそれをそのまま表示する。

Bromure Supply-Chain Security blocked this request: pypi package
[email protected] published 34 minutes ago — policy requires 2 days minimum

このゲートは、完全な公開時刻データを伴って npm、PyPI、Cargo、RubyGems、Packagist をカバーする。pip については、既定の PEP 503 インデックスがタイムスタンプを持たな いため、PyPI の JSON API に対してオンデマンドで照会する。すべての判断は発生した そばからセキュリティログ（ウィンドウ → サプライチェーンログ…）に記録される。

メモリダンプが手に入れるもの

スティーラーの最良の一手は、ログのマスクが隠していた秘密を回収するために、CI ラン ナーのワーカーのメモリを読んだことだった。それが効くのは、マスクが見た目だけのもの で、値そのものはプロセスが保持しているからだ。

同じものを Bromure のワークスペースに対して走らせれば、回収されるのはプレースホル ダーである。プロセスがプレースホルダーを保持しているからだ。 ワイヤ境界はこの製品の中心機構であ る。あなたが設定した資格情報はそれぞれ、VM の内側では構造を保った偽物として現れ、 本物の値は暗号化されたままあなたの Mac に残る。ホスト側のプロキシは、リクエストが VM を出たあとに、しかもその資格情報が発行された相手のホスト宛のリクエストであると きだけ、それをワイヤ上で差し替える。

スティーラー自身のリストを、Bromure の VM に対して順に当ててみよう。

Bromure は各偽物を、本物の値とインストールごとの 32 バイトのソルトから HKDF-SHA256 で導出する。だから自分の鍵をフィンガープリントするツール（Claude Code は鍵のハッシュをキャッシュする）が、セッションをまたいで資格情報が入れ替わるのを 見ることはない。切り忘れるスイッチも存在しない。プロキシは VM から網へ出る唯一の 経路なので、それを迂回したリクエストはプレースホルダーを携えたまま上流の認証に失敗 する。この境界は、構造上、閉じる方向に倒れる。

誰も見たことのなかったタイポスクワット

次は持ち出しだ。3月19日の時点で、scan.aquasecurtiy.org には評判も履歴もなく、誰 のブロックリストに載る理由もなかった。TeamPCP がそれを選んだのは、まさにそのため である。

Bromure の侵害検知は、そのどれも読まない。宛先の評判ではなく、あなたの資格情報 を見張る。ワークスペース自身のために発行された偽物から構築した Aho-Corasick オート マトンが、外向きのすべてのリクエストを、ヘッダも本文も含めて走査する。その偽物のひ とつが、発行されたスコープの外側にあるホスト宛のリクエストに現れたとき、プロキシは そのリクエストを持ち出しの試みとして扱う。

1. プロキシは HTTP 451 でリクエストを拒み、宛先へ1 バイトも転送しない。
2. Bromure はその場で VM を一時停止する。
3. 何が起きたかをアラートが名指しする。セッションの資格情報を、それが発行された相 手ではないホストへ漏らそうとする外向きの試み、と。

そのうえで Bromure はワークスペースを侵害済みとしてマークし、次回の起動時には、VM のディスクイメージと永続ホームを消去しなければ起動しないようにする。あなたのトーク ン、SSH 鍵、ワークスペース設定はそれを生き延びる。トレースインスペクタ（⇧⌘I）と bromure-cli trace leaks が問題のホストと当該リクエストそのものを示すので、依存関 係とプロンプト経由で注入された指示のどちらが原因かは、1分で判断できる。

amazonaws.com にスコープを限定した AKIA 形の発行物が、scan.aquasecurtiy.org 宛の POST に現れれば、そのオートマトンは最初の一回で作動する。検知器はそのドメイン を聞いたこともなく、聞く必要もない。知っているのは、この資格情報には正当な宛先の系 統がひとつしかないこと、そしてこれはそれとは別だということだけだ。有効化するものは 何もない。すべてのリクエストで動いている。

あなたがすでに持っている時系列

ここでの記録の問題は、インシデントより長く残る。

研究者たちは時系列を外側から再構成した。表に出て、入手され、ふるいにかけられて初め て、どのウィンドウが重要だったかを言えるようになった 153 GB の流出アーカイブから だ。被害者は自分たちの記録からは答えられなかった。その記録が、決め手となる二つの事 実を欠いていたからである。自分たちのパイプラインがどの成果物をいつ取得したか、そし て、その結果できたプロセスがどこへ通信を送ったか。

Bromure のワークスペースは、その記録を、動作の副産物として生み出す。あらゆる取得が ホストのプロキシを通るので、セキュリティログには年齢ゲート、OSV、socket.dev、451 の 各判断が生きたテールとして残る。あらゆるリクエストが同じプロキシを通るので、 bromure-cli trace ls はワークスペースごとにホスト、メソッド、ステータス、レイテン シ、swap×N / LEAK×N のフラグを返し、trace hostnames はセッションが接触した個 別のホストを列挙し、trace summary がそれらを集約する。そのすべては、保管時もあな たの Mac 上で、ボールトのマスターキーによって暗号化されたままである。

こうして、SOCRadar が8月に答えた問い、自分は収集されたのか、いつなのかは、あなた 自身が3月に、自分のデータに対して、誰かが正しい名前を公表するのを待つことなく実行 できる、2分の照会になる。

これがその論旨だ。エコシステムが物事に名前をつける速さを、誰も上げることはできない。 3月が見せたのは、ベンダー自身のインシデント対応が19日の尾と誤った帰属を残したという 事実である。あなたに変えられるのは、自分の結末が名前に依存するかどうかだ。レジスト リの前に時計を置き、コードを走らせるマシンにはプレースホルダーを置き、それが何を取 得しどこと話したかについて、自分自身のログを持つこと。

---

出典: SecurityWeek「Trivy, Not LiteLLM Behind the 2,500 Org Compromise」（2026年8月14日） · Aqua Security 勧告 GHSA-69fq-xp46-6x23 · StepSecurity「Trivy Compromised a Second Time」 · The Hacker News（2026年8月12日） · Help Net Security（2026年8月13日） · CrowdStrike「From Scanner to Stealer」