サプライチェーンこそが攻撃対象領域である
2026年3月19日、TeamPCPと名乗る脅威グループが、Aqua Securityのtrivy-action GitHubリポジトリにある77個のバージョンタグのうち76個を強制プッシュで書き換えました。Trivyは、業界で最も広く導入されているオープンソースの脆弱性スキャナーです。新しいタグは、認証情報を窃取するマルウェアを含む悪意あるコミットを指し示していました。ほとんどのCI/CDパイプラインは、固定したコミットSHAではなく可変のバージョンタグでGitHub Actionsを参照しているため、ビルドパイプラインでTrivyを実行しているすべての組織は、即座に侵害されたコードを実行し始めたのです。スキャンは依然として成功したように見えました。スキャナーは依然として脆弱性を報告しました。同時に、ランナー環境のあらゆるシークレットを密かに収集していたのです。1
5日後の3月24日、TeamPCPはそれらのCI環境の1つから窃取したPyPI公開トークンを使い、クラウド環境の36%に存在する人気のAIプロキシライブラリLiteLLMのバックドア入りバージョンを2つ公開しました。2 バージョン1.82.8には、あらゆるPython起動時に、どのimportよりも前、どのアプリケーションレベルのサンドボックスよりも前に自動実行される.pthファイルが含まれていました。そのペイロードは、SSH鍵、クラウド認証情報、データベースパスワード、暗号通貨ウォレット、CI/CDシークレットを根こそぎ回収し、ハードコードされたRSA公開鍵で暗号化した上で、前日に登録された攻撃者管理下のドメインへアーカイブを流出させたのです。3
PyPIは46分後に両バージョンを隔離しました。その時間枠の中で、46,996件のインストールが発生していました。4 LiteLLMのメンテナーは自身のGitHubアカウントを削除し、すべての鍵をローテーションし、Mandiantに調査を依頼したのです。5
セキュリティスキャナーはスキャンしました。ビルドパイプラインはビルドしました。パッケージマネージャーはインストールしました。すべてのコンポーネントは、信頼された通りのことを正確に実行したのです。
要約
- 連鎖の流れ:Trivy(セキュリティスキャナー)が3月19日にGitHub Actionsのタグハイジャック経由で侵害。LiteLLM(AIプロキシ)が3月24日に、Trivy感染CI環境から窃取されたPyPIトークン経由で侵害。46分間で46,996件のダウンロード。4
- 手法:バージョン1.82.8はPythonの
.pthメカニズムを悪用し、感染システム上でLiteLLMをimportすることなく、python3を呼び出すたびに認証情報窃取プログラムを実行します。3 - 影響範囲:2,337個のPyPIパッケージがLiteLLMに依存。そのうち88%は、侵害バージョンのインストールを許容するバージョン指定をしていました。Google ADK、Stanford DSPy、MLflow、Guardrails AI、Cisco AI Defense SDKへの下流影響が確認されています。4
- キャンペーン:TeamPCPは1週間で5つのエコシステムを襲いました。GitHub Actions、Docker Hub、npm(CanisterWorm、28個以上のパッケージ)、Open VSX(Checkmarx KICS)、そしてPyPI(LiteLLM)です。6
- 構造的な教訓:連鎖の各リンクは、認可されたスコープの範囲内で動作していました。認可された操作の組み合わせが、認可されていない振る舞いを生み出したのです。これは、エージェントレベルでサイレントエグレスを可能にし、CI/CDレベルでClinejectionを可能にするものと同じ合成ギャップです。サプライチェーン攻撃とは、合成攻撃なのです。
- できること:依存関係を不変の参照に固定しましょう。公開用認証情報をCIランナーから分離しましょう。OSレベルで外向きネットワークリクエストを監視しましょう。
pip installをコード実行として扱いましょう、実際そうなのですから。
セキュリティスキャナーがビルドパイプラインに侵入する
攻撃は2026年2月下旬、TrivyのGitHub Actions環境における設定ミスから始まりました。攻撃者は脆弱なpull_request_targetワークフローを悪用し、Aqua Securityのaqua-bot個人アクセストークンを流出させました。Aquaは3月1日に一部の認証情報をローテーションしましたが、そのローテーションは不完全だったのです。TeamPCPは有効なトークンを保持し続けていました。1
3月19日、彼らはそれらのトークンを使ってtrivy-actionリポジトリの77個のバージョンタグのうち76個、そしてsetup-trivyの7個すべてのタグを強制プッシュで書き換え、あらゆる可変タグ参照を悪意あるコミットへ向け直しました。さらにリリースオートメーションを発動させ、悪意あるTrivyバイナリをv0.69.4として公開したのです。1
ペイロードは、Runner.Workerプロセスのメモリをダンプし、SSH鍵、クラウド認証情報、Kubernetesシークレット、Docker設定、Git認証情報、.envファイルを収集する認証情報窃取プログラムでした。データはAES-256と4096ビットRSA鍵で暗号化された後、攻撃者管理下のサーバーへ流出しました。悪意あるコードは、正規のTrivy機能と並行して実行されていました。スキャンは成功し、脆弱性は報告され、窃取プログラムはバックグラウンドで動いていたのです。7
3月19日から23日にかけて、trivy:0.69.4、trivy:0.69.5、trivy:0.69.6、trivy:latestタグのDocker Hubイメージが侵害されました。CrowdStrike、Microsoft、Wiz、Palo Altoが数日以内に技術分析を公表しています。789
皮肉は構造的なものです。最もセキュリティ意識の高い組織ほど、最も曝露していたのです。脆弱性スキャンを重視するがゆえにCIでTrivyを動かしていたのなら、そのビルドパイプラインこそが認証情報を収集していた当のものだったというわけです。
スキャナーから窃取プログラム、そしてAIプロキシへ
LiteLLMのCIパイプラインはTrivyを実行していました。具体的には、ci_cd/security_scans.shがAquaのリポジトリからバージョン固定なしにaptでTrivyをインストールしていたのです。10 侵害期間中、あるCI実行が毒入りTrivyバイナリをインストールし、GitHub Actions環境からPYPI_PUBLISH_PASSWORDを収集しました。
3月23日、攻撃者はlitellm.cloudを登録。3月24日10:39 UTCに、窃取した認証情報を使ってlitellm==1.82.7をPyPIに公開。バージョン1.82.8はその後10:52 UTCに続きました。4
2つのバージョンは異なる攻撃手法を使用していました。バージョン1.82.7はペイロードをproxy_server.pyに埋め込み、import litellm.proxyでトリガーされます。バージョン1.82.8はsite-packages/に.pthファイルを追加し、あらゆるPythonインタプリタ起動時にトリガーされるようにしました。.pthメカニズムはパス設定のための正規のPython機能です。site-packages/に置かれた.pthで終わるファイルはすべて、Pythonのsite.pyによってインタプリタ初期化中に自動実行されます。ほとんどのPython開発者はこの機能の存在を知りません。3
両バージョンのペイロードは、環境変数、SSH鍵、AWS/GCP/Azure認証情報、Kubernetes設定、データベースパスワード、暗号通貨ウォレット、CI/CDシークレットを収集しました。ランダムなセッション鍵を用いてAES-256-CBCで集めたデータを暗号化し、そのセッション鍵をハードコードされた4096ビットRSA公開鍵でラップし、HTTPS POST経由でアーカイブを流出させたのです。窃取されたデータを復号できるのは攻撃者だけでした。3
1.82.8のマルウェアにあったバグが、この攻撃を可視化することになりました。.pthファイルが子Pythonプロセスを生成し、それが再び.pthファイルをトリガーして、指数関数的なフォーク爆弾を生じさせたのです。Andrej KarpathyがX上でこのバグを指摘しました。このフォーク爆弾がなければ、窃取プログラムは感染したあらゆるシステムのあらゆるPython呼び出しで静かに実行され、検出まで数週間かかっていた可能性があります。4
PyPIは11:25 UTCに両バージョンを隔離しました。総曝露時間は46分。総ダウンロード数は46,996件です。4
影響範囲
LiteLLMは1日約340万回ダウンロードされています。Wizの報告によれば、クラウド環境の36%に存在するとのことです。2 46分間の曝露時間で十分だったのです。
FutureSearchがPyPIのBigQueryダウンロードログを分析したところ、攻撃期間中のバージョン1.82.8は、安全なバージョンの6倍ダウンロードされていました。ダウンロードは(ロックファイルを使う)uvよりも(最新版に解決する)pipに大きく偏っていました。46,996件のダウンロードのうち23,142件はpipによるv1.82.8のインストールで、それぞれがインストール自体の最中にペイロードを実行していました。.pthファイルがpip自身のPythonプロセス中に発火するためです。4
PyPI上の2,337個のパッケージがLiteLLMに依存しています。そのうち88%(2,054個のパッケージ)は、侵害バージョンのインストールを許容するバージョン指定をしていました。下流の曝露は次の通りです。4
| プロジェクト | 月間ダウンロード数 | 影響 |
|---|---|---|
| CrewAI | 590万 | リスクあり |
| Browser-Use | 420万 | リスクあり |
| Opik(Comet) | 350万 | 2つのCIワークフローが侵害バージョンを実行したと確認済み |
| Mem0 | 270万 | リスクあり |
| DSPy(Stanford NLP) | 160万 | <=1.82.6に固定 |
| Agno | 160万 | リスクあり |
| Google ADK | – | 確認済み:litellmがすべてのインストールを破壊 |
| MLflow | – | <=1.82.6に固定 |
| Guardrails AI | – | 緊急勧告発出 |
| Cisco AI Defense SDK | – | 緊急勧告発出 |
LiteLLM CloudおよびDockerプロキシユーザーは、依存関係がrequirements.txtで固定されていたため影響を受けませんでした。「固定されている」か「固定されていない」かの違いが、侵害された側と無事な側を分けたのです。5
1週間で5つのエコシステム
TeamPCPはPyPIで止まりませんでした。キャンペーンは5つのパッケージエコシステムを立て続けに襲ったのです。6
GitHub Actions(3月19日):76個のtrivy-actionタグと7個すべてのsetup-trivyタグが乗っ取られ、悪意あるTrivyバイナリv0.69.4からv0.69.6までが公開されました。
Docker Hub(3月19日〜22日):aquasec/trivy:latestおよびバージョン固有のタグとして侵害されたTrivyイメージが公開され、mirror.gcr.ioにも伝播しました。
Open VSX(3月23日):Checkmarx KICSのGitHub Actionが侵害され、35個のタグが12:58から16:50 UTCの間に乗っ取られました。2
npm(3月23日〜24日):自己伝播型ワームのCanisterWormが28個以上のnpmパッケージに展開されました。
PyPI(3月24日):LiteLLMのバージョン1.82.7と1.82.8が、認証情報窃取ペイロードと共に公開されました。
各エコシステムの侵害は、前の侵害から収集した認証情報を使用していました。このキャンペーンは信頼関係の悪用を連ねた有向グラフであり、各侵害ノードが次への鍵をもたらしていたのです。
サプライチェーン攻撃とは合成攻撃である
TeamPCPキャンペーンの構造的パターンは、エージェントセキュリティやサイレントエグレスの文脈で説明したものと同じパターンです。個別に認可されたコンポーネントが合成されて、認可されていない振る舞いへと至るというものです。
TrivyはCIで動くことを認可されていました。CIは公開用認証情報を保持することを認可されていました。パッケージマネージャーはパッケージをインストールすることを認可されていました。各.pthファイルはPythonのパスを設定することを認可されていました。連鎖のすべてのリンクは、定義されたスコープ内で動作していました。それらの認可された操作の合成が、大規模な認証情報流出を生み出したのです。
Clinejection攻撃はCI/CDレベルで同じパターンを示しました。issueタイトルがClineの自動化パイプラインに敵対的なテキストを注入し、それがnpmのpreinstallスクリプトを実行し、それがビルドキャッシュを汚染し、ワークフロー間のアーティファクトを汚染したのです。各ステップは個別に認可されていました。11
MCPToxベンチマークはエージェントレベルでそれを示しました。ツール説明に埋め込まれた悪意ある命令が、エージェントを誘導して、サーバー上にすでに存在する正規のツールを使って認証情報を流出させるのです。エージェントは毒入りツール自体を実行することは決してありません。エージェントは毒入りの説明を読み取り、自身の認可されたツールを使って攻撃を遂行します。12
サイレントエグレスはランタイムレベルでそれを示しています。Webページメタデータ内の敵対的命令が、エージェントに対して、そのエージェントが行う権限を持つ外向きのHTTPリクエストを通してランタイムコンテキストを流出させるよう誘導するのです。13
攻撃対象領域は、単一の脆弱なコンポーネントではありません。攻撃対象領域とは、信頼されたコンポーネントの合成そのものなのです。個々のリンクを守ることは、連鎖を守ることにはなりません。Trivyが脆弱性だったのではありません。LiteLLMが脆弱性だったのでもありません。脆弱性とは、可変のバージョンタグと固定されていない依存関係によって媒介された、両者の間の信頼関係だったのです。
本当に効くもの
この攻撃の各段階を防ぐことができた防御策は、地味なものです。そして多くの組織が省略しているものでもあります。
不変の参照に固定する。 LiteLLMはバージョン固定なしでaptを通じてTrivyをインストールしていました。security_scans.shが特定のバージョンやコミットSHAに固定していれば、毒入りv0.69.4バイナリが実行されることはなかったでしょう。GitHub Actionsは可変タグではなくコミットSHAを参照すべきなのです。uses: aquasecurity/[email protected](侵害)とuses: aquasecurity/trivy-action@57a97c7(安全)の違いは、公開用認証情報を失うかどうかの違いなのです。1
公開用認証情報をCIランナーから分離する。 PYPI_PUBLISH_PASSWORDは、Trivyが動いていたGitHub Actionsランナー内で環境変数としてアクセス可能な状態でした。公開用認証情報が、サードパーティのaction依存関係を持たない別のワークフローに分離されていれば、Trivyの侵害がPyPIへのアクセスをもたらすことはなかったでしょう。PyPIのTrusted Publishers(OIDC)は、保存されたトークンを完全に不要にします。5
外向きネットワークリクエストを監視する。 認証情報窃取プログラムは、攻撃の24時間前に登録されたドメインmodels.litellm.cloudへHTTPS POST経由でデータを流出させていました。新たに登録されたドメインへのリクエストをフラグする外向き監視があれば、これを捕捉できたはずです。私自身のフックシステムは、許可リストにないドメインへの外向きリクエストをブロックしており、この流出を遮断できたであろう同じパターンなのです。14
私も本番環境で同じ教訓を痛い目で学びました。信頼していたCloudflareキャッシュパージ経路が、認可されたAPI呼び出しを発火させたにもかかわらず、周囲のガードレールが緩すぎたために誤った結果を生んだのです。その失敗を機に、ドメイン許可リストだけでなく、影響の大きい操作の周りに破壊的アクションの承認機能とプリフライトフックを追加することにしたのです。
pip installをコード実行として扱う。 site-packages/内の.pthファイルは、あらゆるPython起動時に実行されます。オプトアウトの手段はありません。サンドボックスもありません。認証情報にアクセスできるCI環境でpip installを実行するということは、パッケージ内のすべての推移的依存関係に任意コード実行権を与えているのと同じことなのです。緩和策は、認証情報アクセスのない環境でpip installを実行し、それからインストール済みパッケージを必要とする環境にコピーすることです。
ロックファイルを使う。 FutureSearchの分析によれば、(ロックファイルを使う)uv経由のダウンロードは、(最新版に解決する)pip経由のダウンロードに比べて、侵害バージョンをインストールする可能性が大幅に低かったのです。ロックファイルは完全な防御ではありませんが、最も一般的な曝露を防ぎます。固定されていない>=バージョン制約が、密かに侵害されたリリースへアップグレードしてしまうことです。4
不都合な含意
TeamPCPキャンペーンは、サプライチェーンセキュリティがアプリケーションセキュリティ、ネットワークセキュリティ、エンドポイント保護の後ろに控える副次的な関心事ではないことを示しています。ツールアクセスを持つAIエージェントを運用している組織にとって、サプライチェーンは主要な攻撃対象領域なのです。
CI環境でpip installを呼び出したり、URLを取得したり、MCPサーバーをインストールしたりするAIエージェントは、実行時に信頼関係を合成しています。各操作は認可されています。ですが合成はそうではないかもしれません。展開と防御のパラドックスがこれを加速させています。組織は、エージェントが合成する信頼チェーンを監査する速度よりも速くエージェントを展開しているのです。
LiteLLM 1.82.8のフォーク爆弾バグだけが、この攻撃が迅速に検出された唯一の理由でした。その実装エラーがなければ、認証情報窃取プログラムは感染したあらゆるシステムのあらゆるPython呼び出しで静かに実行されていたでしょう。46分間で46,996件のインストール。クラウド環境の36%。2,337個の下流パッケージ。攻撃者はミスを犯しました。次はそうしないかもしれません。
更新 — 2026年3月31日:異なるベクター、同じ結末
この投稿が公開されてから6日後、npmは次のインシデントに見舞われました。3月31日、axiosメンテナーのJason Saaymanは、自身の個人用コンピュータが標的型ソーシャルエンジニアリングキャンペーンと、それに続くリモートアクセストロイの木馬マルウェアを介して侵害されたことを明らかにしました。攻撃者はSaaymanのnpm認証情報を使ってaxios 1.14.1と0.30.4を公開し、両バージョンとも[email protected]という新しい依存関係を注入し、それがmacOS、Windows、LinuxにクロスプラットフォームRATをインストールしました。悪意あるバージョンはおよそ3時間稼働していましたが、コミュニティの貢献者がインシデントをトリアージし、npmが削除するに至りました。16
axiosのベクターはTeamPCPとは異なるものでした。侵害されたCIランナーも、サードパーティのセキュリティスキャナーから収集された認証情報も、複数エコシステムにまたがるワームもありませんでした。Saaymanに対するキャンペーンは公開前に約2週間動いており、侵害はメンテナーの個人デバイスからnpmの公開パイプラインへと直行したのです。修復には、個人・業務を問わず彼がこれまで使用していたすべてのデバイスの完全ワイプと、すべてのプラットフォームにおける全認証情報のローテーションが必要でした。C2インフラは142.11.206.73:8000上のsfrclak[.]comでした。16
構造的な教訓は同じです。信頼チェーンには今や、メンテナーの注意力と警戒心もリンクとして含まれるのです。個別に認可された操作が、連鎖内の人間が操作された時に、認可されていない振る舞いへと合成されてしまうのです。axiosチームが採用している緩和策(OIDC公開、不変リリース、デバイス分離)16 は、TrivyからLiteLLMへの流れが露呈させたのと同じ合成ギャップに対処するものです。公開用認証情報が、すでに隣接する何かを侵害した敵対者の手の届く場所に保管されているというギャップです。
3時間。46分。これが現代のサプライチェーン攻撃が動作する時間枠なのです。ピンニングとロックファイルは依然として主要な防御策です。3月31日の00:21〜03:15 UTCの時間枠外で新規インストールを行ったaxiosユーザーは影響を受けませんでした。16
FAQ
自分が影響を受けたかどうかを確認するには?
CIログとローカル環境を検索し、2026年3月24日の10:39から11:25 UTCの間にインストールされたLiteLLMのバージョン1.82.7または1.82.8を探してください。どちらかのバージョンがインストールされていた場合、そのシステム上で環境変数、SSH鍵、設定ファイルとしてアクセス可能だったすべての認証情報をローテーションしてください。LiteLLMの公式ガイダンスは、侵害されたバージョンを実行したあらゆるシステムを完全に侵害されたものとして扱うことを推奨しています。5
どの勧告識別子を追跡すべきか?
OSVおよびPyPA勧告データベースのPYSEC-2026-2を追跡してください。OSVはこのインシデントをMAL-2026-2144としてもエイリアス化しています。2026年3月25日時点では、公開のOSV勧告ページには悪意あるLiteLLMリリースに対するCVEエイリアスが列挙されていないため、インシデント対応チームは影響を受けたバージョン、インストール時間枠、そしてPYSEC-2026-2を優先して参照すべきでしょう。15
LiteLLM CloudやDockerプロキシユーザーは影響を受けたのか?
いいえ。LiteLLM Cloudと公式のDockerプロキシイメージは、依存関係をrequirements.txtで固定しており、侵害バージョンへの自動解決を防いでいました。影響を受けたのは、46分間の時間枠中にpip install litellm(固定なし)でLiteLLMをインストールしたユーザーだけだったのです。5
.pthファイルとは何か、なぜ危険なのか?
.pthファイルは、モジュール検索パスを設定するためのPythonの機能です。site-packages/ディレクトリに置かれた.pthで終わるファイルはすべて、Pythonのsite.pyモジュールによってインタプリタ初期化中に読み取られ、実行されます。これはあらゆるimport文よりも前、あらゆるアプリケーションコードよりも前、あらゆるPythonレベルのサンドボックスよりも前に起こります。このメカニズムはPython標準ライブラリで文書化されていますが、アプリケーション開発者の間では広く知られていません。これは正規の機能が攻撃ベクターとして使われている例なのです。3
これはTrivyサプライチェーン攻撃と関係があるのか?
はい。LiteLLMの侵害は、Trivy侵害の直接的な帰結でした。TeamPCPは3月19日にTrivyのGitHub Actionsを侵害し、ビルドパイプラインでTrivyを運用していた組織からCI/CD認証情報を収集しました。その認証情報の1つがLiteLLMのPyPI公開トークンだったのです。攻撃者はそのトークンを使って、5日後に悪意あるLiteLLMバージョンを公開しました。10
TeamPCPとは何か?
TeamPCP(DeadCatx3、PCPcat、ShellForce、CipherForceとしても追跡されている)は、2026年3月に複数エコシステムにまたがるサプライチェーンキャンペーンを実行した脅威グループで、GitHub Actions、Docker Hub、npm、Open VSX、PyPIのパッケージを侵害しました。このグループは認証情報収集、タグハイジャック、自己伝播型ワーム技術を、約1週間で5つのパッケージエコシステムにわたって使用しました。6
これはAIエージェントセキュリティとどう関係するのか?
パッケージをインストールしたり、URLを取得したり、MCPサーバーに接続したりするAIエージェントは、実行時に信頼関係を合成しています。各操作は個別に認可されています。それらの操作の合成は、サイレントエグレス(エージェントレベル)、Clinejection(CI/CDレベル)、そして今回の攻撃(サプライチェーンレベル)が示すように、認可されていない振る舞いを生み出し得ます。ランタイム挙動監視、ドメイン許可リスト、認証情報分離は、スタックの異なるレイヤーで合成ギャップに対処するものなのです。14
出典
-
CrowdStrike, “From Scanner to Stealer: Inside the trivy-action Supply Chain Compromise,” 2026年3月. タグハイジャック、認証情報収集、攻撃タイムラインの技術分析。 ↩↩↩↩
-
Wiz, “Three’s a Crowd: TeamPCP Trojanizes LiteLLM in Continuation of Campaign,” 2026年3月. LiteLLMはクラウド環境の36%に存在。TrivyからKICS、LiteLLMへのキャンペーン全体の進行。 ↩↩↩
-
Sonatype, “Compromised litellm PyPI Package Delivers Multi-Stage Credential Stealer,” 2026年3月.
.pthファイル技術、ペイロード暗号化、流出メカニズムの技術分析。 ↩↩↩↩↩ -
FutureSearch(Daniel Hnyk), “LiteLLM Hack: Were You One of the 47,000?” 2026年3月. PyPI BigQuery分析:46分間で46,996件のダウンロード。2,337個の依存パッケージ、88%が侵害バージョンを許容。月間ダウンロード数別の下流曝露。 ↩↩↩↩↩↩↩↩↩
-
LiteLLM, “Security Update: Suspected Supply Chain Incident,” 2026年3月. 公式ポストモーテム。Trivyがベクターであることを確認。Docker/Cloudユーザーは影響を受けず。Mandiantが関与。 ↩↩↩↩↩
-
Kaspersky, “Trojanization of Trivy, Checkmarx, and LiteLLM Solutions,” 2026年3月. 5つのエコシステムにまたがるキャンペーン全体の分析。 ↩↩↩
-
Microsoft, “Guidance for Detecting, Investigating, and Defending Against the Trivy Supply Chain Compromise,” 2026年3月. 検出ガイダンス、影響を受けたバージョンマトリクス、侵害指標。 ↩↩
-
Aqua Security, “Trivy Supply Chain Attack: What You Need to Know,” 2026年3月. 公式インシデント対応。認証情報ローテーションの不完全さを認めた。 ↩
-
Palo Alto Networks, “When Security Scanners Become the Weapon,” 2026年3月. 攻撃の技術的内訳。 ↩
-
Snyk, “How a Poisoned Security Scanner Became the Key to Backdooring LiteLLM,” 2026年3月. TrivyからLiteLLMへの攻撃チェーン。
ci_cd/security_scans.sh内の固定されていないTrivy依存関係。 ↩↩ -
Khan, Adnan, via Simon Willison, “Clinejection: Compromising Cline’s Production Releases,” simonwillison.net, 2026年3月. ↩
-
Zhiqiang Wang et al., “MCPTox: A Benchmark for Tool Poisoning Attack on Real-World MCP Servers,” arXiv:2508.14925, AAAI 2026. ↩
-
Lan, Qianlong et al., “Silent Egress: When Implicit Prompt Injection Makes LLM Agents Leak Without a Trace,” arXiv:2602.22450, 2026年2月. ↩
-
Blake Crosley, “What I Told NIST About AI Agent Security,” blakecrosley.com, 2026年2月. ↩↩
-
OSV / PyPA Advisory Database, “PYSEC-2026-2” 2026年3月24日公開. 悪意あるLiteLLMリリースに対する公開勧告。エイリアス:
MAL-2026-2144。 ↩ -
Jason Saayman, “Post Mortem: axios npm supply chain compromise,” github.com/axios/axios, 2026年3月31日. axiosリードメンテナーからの一次開示。タイムライン、修復、ベクター分析。追加の技術分析:StepSecurity, “Axios Compromised on npm — Malicious Versions Drop Remote Access Trojan,” およびDatadog Security Labs, “Axios npm Supply Chain Compromise,” 2026年3月. ↩↩↩↩