SANS Internet Storm Center の記事は、2026年5月24日時点での TeamPCP 系キャンペーンを総まとめしたものです。
ひとことで言えば、「開発者が信じて入れるもの」がことごとく悪用された、かなりいやな週でした。
しかも面白いのは、攻撃の広がり方です。
ふつうは「1つのnpmパッケージが汚染されました」で終わることも多いのですが、今回はそうではありませんでした。
この4つが、ほぼ連鎖反応みたいに並んでいます。
個人的には、ここがいちばん怖いところだと思います。**“配布の入口”が複数壊れると、開発者はどこを疑えばいいのか分からなくなる**からです。
記事の冒頭では、まず大きな流れが3つに整理されています。
GitHub の CISO が、悪意ある Nx Console VS Code extension を原因として公表しました。
この拡張機能は、Visual Studio Marketplace に約18分だけ存在していたそうです。短い。でも短すぎて逆に厄介です。
その18分の間に、GitHub内部の開発者端末で自動更新され、秘密情報が抜かれ、最終的に 約3,800件のGitHub内部リポジトリ が流出したとされています。
しかも被害は GitHub だけではなく、OpenAI、Grafana Labs、Mistral AI の開発者にも及んだと名指しされています。
つまり、ひとつの悪性拡張機能が、複数組織に「静かに」広がったわけです。
PyPI では、Microsoft が公式に公開している durabletask という Python SDK が改ざんされました。
これは Azure Durable Functions 向けのクライアントで、月間ダウンロード数は約41.7万。
対象バージョンは 1.4.1〜1.4.3 の3つです。
重要なのは、importするだけで実行される こと。
つまり「インストールしただけなら大丈夫」という逃げ道がありません。
記事では、この第二段階のペイロードが Linux disk wiper を含むとする報道も紹介しています。もし本当なら、単なる窃取ではなく破壊まで行けるということです。これはかなり重い。
npm 側では、**@antv** エコシステムに向けた「Mini Shai-Hulud」系の第三波が来ました。
639の悪性バージョン、323パッケージ というのは、規模感としてなかなかえげつないです。
対象には echarts-for-react や size-sensor のような、週間ダウンロード数が非常に多いパッケージも含まれていました。
しかも一部の悪性パッケージには、Sigstore verification badge の偽表示まであったとのこと。
ここ、かなり嫌なポイントです。
「署名や証明があるから安心」と思わせるUIそのものが、攻撃者に利用される。これは、セキュリティの“見栄え”に頼る危うさを突きつけています。
このキャンペーンの面白さ、というより怖さは、1つの侵入口から別の侵入口へ芋づる式につながったところにあります。
記事では、2026年5月11日の TanStack wave で盗まれた OIDC credentials（クラウドやCI/CDで使う認証情報）が、5月18日の Nx Console publish に使われた可能性があるとされています。
つまり、以前の攻撃で盗んだ鍵を、次の攻撃の“公開用鍵”として使ったわけです。
この流れはかなり現代的です。
昔のマルウェアは「配る→感染させる」で終わることが多かったのに、今は盗んだ認証情報を使って正規の配布経路から悪性版を出す。
正規の手続きを逆手に取るので、発見が遅れやすいんですよね。
この件で特に重要なのは、verified-publisher badge があっても安全とは限らないと実証されたことです。
Visual Studio Marketplace の verified-publisher は、ざっくり言うと
「この発行者は本物っぽいですよ」という見た目の保証です。
でも、今回のケースでは発行者アカウントが本物でも、その“その時の公開”が悪性だった可能性がある。
ここが肝です。
つまり、
は別問題。
個人的には、この切り分けは今後かなり重要になると思います。
「会社名が付いてるから安全」は、もう単純には言えません。
PyPI の durabletask は、Microsoft 公式という点でかなり信頼されやすいパッケージです。
しかも SDK（開発者が他の機能を呼び出すための部品）なので、**“業務で普通に使う”** 可能性が高い。
記事によれば、悪性コードは Python source files に注入されていて、importしただけで起動します。
これは実務上かなりやっかいです。
CI runner や一時的なビルド環境でも、パッケージを読んだ瞬間に感染しうるからです。
また、第二段階は単なる情報窃取だけではなく、
などの認証情報を狙い、さらに AWS SSM や kubectl exec を使ってクラウドやKubernetes内で広がるとされています。
要するに、クラウド時代の横展開に最適化された設計です。
攻撃者の工夫、正直かなり手が込んでいます。
@antv を狙った npm の波では、323パッケージに639の悪性バージョン という数字が出ています。
これ、1つ1つを見れば小さくても、数で押されると現場は相当つらいです。
しかも収集対象が広い。
記事で挙げられているだけでも、
など、かなり何でもありです。
もはや「開発環境の金目のものを全部ください」という感じです。
さらに、以前の波で見られた .vscode/tasks.json や ~/.claude/settings.json への永続化も継続しているとのこと。
AI coding agent や VS Code 周辺の設定ファイルを狙うのは、今どきらしい持続化のやり方だと思います。
開発者の“日常”に溶け込む場所を押さえるので、発見しにくいんですよね。
記事の後半では、TeamPCP のフレームワークコードらしきものが GitHub に公開されていた話も出てきます。
Datadog Security Labs の分析では、これは モジュール型の TypeScript/Bun ツールキット で、認証情報収集、供給網汚染、暗号化された外部送信までできるように見えるとのことです。
README には
"Love - TeamPCP""Change keys and C2 as needed."といった文字列もあるそうで、なかなか生々しいです。
ここでいう C2 は command and control の略で、攻撃者がマルウェアを遠隔操作するための制御サーバーのことです。
しかも、そのソースを元にした fork（コピー派生）がすぐ出てきた。
これがまた厄介で、以後は検知側が「元のTeamPCP由来」なのか「模倣犯」なのかを見分けにくくなる。
つまり、帰属（アトリビューション）のノイズが増えるわけです。
セキュリティ運用の現場では、これが地味に痛い。
この件で興味深いのは、Microsoft は比較的はっきり動いた一方で、CISA は KEV catalog に載せなかったことです。
KEV catalog は、米国の CISA が管理する「既知の悪用済み脆弱性」の一覧です。
ここに載ると、優先的に対処すべき対象として扱われます。
記事では、CISA はこの週に他の脆弱性は追加したのに、CVE-2026-45321 は入れなかったと指摘しています。
GitHub内部侵害や Microsoft の公式ブログ、複数の有名組織への影響が出ているのに、まだ載らない。
これは少し意外ですし、記事もその“沈黙”を重要視しています。
私もこれは気になります。
運用上、一覧に載るかどうかで優先度が変わる組織は多いので、公式リストにないから安心、では全然ないんですよね。
記事の最後はかなり実務的です。要するに、見つけたらすぐ棚卸しとローテーションです。
nrwl.angular-consoleecharts-for-reactsize-sensortimeago.jsもし該当環境で以下を使っていたら、鍵の再発行・パスワード変更・トークン失効を急ぐべきです。
記事では、次のような振る舞い監視が有効だとしています。
~/.claude/settings.json への書き込み.vscode/tasks.json への書き込みfilev2.getsession.org や seed1.getsession.org への外部送信こういうのは、単なるIOC（既知の悪性文字列）よりも長生きします。
理由は簡単で、攻撃者がコピーしても、行動パターンは残るからです。
この記事を読んでまず思ったのは、「供給網攻撃は、もはや“1箇所の穴”ではなく“信頼の仕組み全体”を狙っている」ということです。
しかも今回は、正規の認証、正規のリポジトリ、正規の配布基盤、正規のバッジまで全部巻き込んでいます。
だからこそ、単純に「このパッケージは有名だから大丈夫」とは言えません。
現実的には、
みたいな、地味で面倒な対策がじわじわ効いてくるんだと思います。
華やかさはないですが、こういう地味な運用が最後に勝つことが多いです。
TeamPCP の今回の動きは、単なるマルウェア流通ではなく、開発者の信頼を前提にした配布経路そのものへの攻撃でした。
GitHub、Microsoft、npm という大きなエコシステムをまたぎ、しかも見た目の信頼指標まで悪用したのが本当に厄介です。
今後の教訓としては、
「署名がある」「 verified だから安心」「公式だから安全」だけでは足りない
ということに尽きます。
安全判断は、表示マークよりも、実際の挙動と依存関係の管理に寄せるべき時代になっている、と感じます。
参考: TeamPCP Supply Chain Campaign: Activity Through 2026-05-24