英語版で読む
技術 約22分で読めます

Mini Shai-HuludがTanStack・Mistralのnpmへ拡大、CVE-2026-45321とTeamPCPの連続キャンペーン

セキュリティ npm サプライチェーン マルウェア GitHub Actions
いけさん目次

TL;DR

ステータス 随時更新中。直近の追記: Mandiant集計1,000+ SaaS下流被害、GTIG別名UNC6780、CipherForce並列ランサム、intercom-php Packagistでの3エコシステム横断

影響 2026年5月11日UTCのTanStack 42パッケージ84バージョンから始まり、UiPath系60超を含む200パッケージ近くまで拡大。CVE-2026-45321（CVSS 9.6 / Critical）。SLSA Build Level 3 provenance付き悪性パッケージの初観測。一次侵害から窃取したシークレットの下流被害はMandiantの集計で1,000+ SaaS環境

帰属 攻撃グループはTeamPCP（Google GTIGはUNC6780としてトラッキング）。Aqua Trivy（2026年3月）、Bitwarden CLI npm（2026年4月）、Checkmarx Jenkins AST Plugin（2026年5月9日）と同系統の連続キャンペーン

対応 該当バージョンを npm install／pnpm install／yarn install した開発端末・CI runnerは、ネットワーク隔離 → gh-token-monitor デーモン停止 → そのあとにnpm／GitHub／AWS／GCP／Kubernetes／Vault／SSHのrevoke・ローテーション（順序を逆にするとtoken失効を検知した監視デーモンが rm -rf $HOME を走らせる）。.claude/ 配下と .vscode/tasks.json の点検も同時に

確認 lockfile・package cache・CIログでの router_init.js、tanstack_runner.js、@tanstack/setup、予期しないBun実行、想定外のnpm publishの痕跡。payload SHA256 ab4fcadaec49c03278063dd269ea5eef82d24f2124a8e15d7b90f2fa8601266c、C2ドメイン api.masscan.cloud／git-tanstack.com、流出先 *.getsession.org をDNSログでも見る

二次被害リスク Vectランサムウェア（実体は128KB超のファイルを破壊するwiperで復号不能）がTeamPCP侵害組織を標的化中。身代金支払いではデータが戻らない前提でDR計画を組む

2026年5月11日19:20〜19:26 UTC、TanStackのnpmパッケージ42個に悪性バージョン84件が公開された。
日本時間では2026年5月12日04:20〜04:26ごろ。
TanStack公式のポストモーテムでは、pull_request_target、GitHub Actions cache poisoning、OIDCトークンのrunnerメモリ抽出がつながった攻撃として説明されている。

Aikidoの調査記事では、TanStackだけでは終わっていない。
Mini Shai-Huludの今回の波として、169パッケージ名にまたがる373件の悪性package-versionが報告されている。StepSecurityはその後さらに拡大し、UiPath系50パッケージ超、DraftLabほかを含む170パッケージ超に達したとしている。対象には @tanstack、@mistralai、@uipath、@squawk、@tallyui などが含まれる。

攻撃グループの帰属はTeamPCPで、StepSecurityのレポートによるとAqua SecurityのTrivyスキャナ侵害（2026年3月）、Bitwarden CLIのnpm侵害（2026年4月）、Checkmarx Jenkins AST Plugin侵害（2026年5月9日）と同系統の攻撃活動になる。Dune世界のブランチ名（fremen、sandworm、harkonnen）を運用に使う命名癖もそのまま引き継がれている。今回の事例にはCVE-2026-45321（CVSS 9.6 / Critical）が割り当てられた。

@tanstack/react-router や @tanstack/history を使うReact系プロジェクトだけでなく、Mistral SDKをCIで入れている環境も巻き込まれる話になった。
Aikidoが挙げたMistral側の汚染バージョンは @mistralai/mistralai の 2.2.2、2.2.3、2.2.4、@mistralai/mistralai-azure と @mistralai/mistralai-gcp の 1.7.1〜1.7.3 だ。
Mistral公式もsecurity advisoryを出していて、現時点では「Mistralインフラ自体への侵害の兆候はない」「PyPI側の mistralai==2.4.6 はimport時に悪性スクリプトを走らせる」と整理している。

TanStack側はnpmトークン窃取ではなくrunner上のOIDC悪用

TanStack公式の説明でいちばん嫌なところは、npmトークンが盗まれたわけではない点だ。
release workflow自体も、定義されたpublish stepから悪性パッケージを出していない。

攻撃の流れはこうなっている。

graph TD
    A["攻撃者がfork PRを作成"] --> B["pull_request_target workflowで<br/>fork側コードが実行"]
    B --> C["pnpm store cacheを汚染"]
    C --> D["mainへの通常pushで<br/>release workflowが起動"]
    D --> E["汚染cacheをrestore"]
    E --> F["runner内でOIDC tokenを抽出"]
    F --> G["registry.npmjs.orgへ直接publish"]
    G --> H["42パッケージ84バージョンが汚染"]

Trusted publishingは、長寿命のnpm tokenをGitHub Actionsから消すための仕組みだ。
GitHub ActionsのOIDCで短命のpublish tokenを発行し、npmへ公開する。
ワークフローがきれいなら良い設計だが、runner上で攻撃者のコードが動いた場合は、その短命トークンをその場で使われる。

つまりprovenance（出所証明）は「どこでビルドされたか」を示すだけで、「そのビルドが安全だったか」までは示さない。
axiosメンテナがRAT経由で侵害された件では、正規メンテナ端末の掌握で2FAやローカルpublishが問題になった。
今回は正規のrelease workflowの権限を、runner上の悪性コードが直接使っている。
どちらも「信頼された経路」が攻撃者の手元に来た瞬間に崩れる。

OIDCトークンの取り方も泥臭い。Aikido・Socket・StepSecurityの解析を突き合わせると、payloadは /proc/<pid>/mem を直接読みに行き、GitHub Actions runnerプロセスのヒープから {"value":"...","isSecret":true} の形をしたJSONオブジェクトを片端から拾う。これでマスクされたsecretも生のJWTもまとめて手に入る。GitHub Actions側のlog masking（***への置換）はあくまでログ出力の話で、プロセスメモリ上の生値はマスクされない、というところを突かれた形だ。

SLSA provenanceは有効でも悪性パッケージは出る

今回の汚染版TanStackパッケージには、SLSA Build Level 3のprovenance attestationが正しく付いている。StepSecurityはこれを「validに署名された悪性npmパッケージとして初の文書化事例」と整理している。

provenanceは「このartifactは、この公開リポジトリのこのワークフローから、このコミットを材料にして作られた」という事実を暗号学的に保証する。今回もその保証自体はちゃんと成立していて、TanStackの正規GitHub Actionsワークフローから、正規のコミットを起点に、登録された通りの経路でnpmに公開されている。それでも中身は悪性だった。

provenanceで分かるのは「どのパイプラインが作ったか」だけで、「そのパイプラインが意図通り動いていたか」までは分からない。今回はfork PR経由でcache poisoningが先に成立しているため、ワークフロー定義は健全のまま、内部状態だけが汚染されていた。

読み手側に効いてくるのは、provenance検証だけを信頼境界にしないという話だ。具体的には、依存パッケージのSLSA署名OKを「安全」と読み替えない、新バージョン公開直後はpost-publish監視（lifecycle scriptの新規追加、tarball内ファイルの差分、optional dependencyのGit参照）で時間差検知を入れる、trusted publishingを使うリポジトリ側は pull_request_target とbranch/workflow pinningの組み合わせを点検する、あたりまで踏み込んでようやくこの攻撃面を埋められる。

悪性パッケージはoptional dependencyからGitHub上のpayloadを踏ませる

TanStackの汚染パッケージには、ルートに router_init.js が混入していた。
さらに package.json には、GitHub上の特定commitを指す optional dependency が追加されている。

"optionalDependencies": {
  "@tanstack/setup": "github:tanstack/router#79ac49eedf774dd4b0cfa308722bc463cfe5885c"
}

このGit dependency側に prepare script があり、bun run tanstack_runner.js && exit 1 を実行する。
Git dependencyのlifecycle scriptはinstall時に走るため、見た目は通常の依存解決でもpayload（悪意あるコード本体）が動く。

最後に exit 1 するのも雑ではない。
optional dependencyなので、失敗してもinstall全体は止まらない場合がある。
payloadだけ先に実行し、失敗は optional dependency の失敗として流す設計だ。

ここは偽Strapiプラグインが postinstall.js で即時実行していた件と同じく、npmのlifecycle scriptが攻撃面になっている。
違うのは、今回は偽パッケージではなく正規パッケージの正規リリース経路に近い場所が使われたことだ。

盗みに行く対象はCI runner前提

Aikidoの解析では、payloadは開発端末だけでなくCI環境を強く意識している。
探しに行く対象は、npm tokenやGitHub tokenだけではない。
AWSのmetadata、GCP metadata、Kubernetes service account token、Vault token、環境変数、ローカルファイルシステム上のシークレットまで見る。

この手のワームは、感染した環境を「次の公開元」に変える。
窃取したnpm・GitHub権限から、被害者がpublishできるパッケージを探し、package archiveを改変し、バージョンを上げて再公開する。
SANDWORM_MODEでも、npm token、GitHub token、SSH経路を使ったワーム伝播が中心だった。
Mini Shai-HuludはそこにGitHub Actions OIDCとtrusted publishingの悪用が乗った形に見える。

確認すべき痕跡は、lockfileとCIログに残りやすい。
@tanstack/setup、github:tanstack/router#79ac49eedf774dd4b0cfa308722bc463cfe5885c、router_init.js、router_runtime.js、tanstack_runner.js、bun run tanstack_runner.js が出てきたら、その環境は侵害済みとして扱う。
CIログでは、install中の予期しないBun実行、optional dependencyの失敗、想定外のOIDC token request、想定外のnpm publishを見る。

具体的なIoCも公開されている。router_init.js本体のSHA256は ab4fcadaec49c03278063dd269ea5eef82d24f2124a8e15d7b90f2fa8601266c、C2は api.masscan.cloud と git-tanstack.com、流出先には *.getsession.org 系のサブドメインが使われる。攻撃者側のGitHubアカウントは voicproducoes（2026年3月19日作成）で、リポジトリへの自動コミットは claude@users.noreply.github.com の見せかけのアドレスで署名される（このアドレス自体はAnthropic公式ではないので、リポジトリのコミット履歴に出てきたら侵害サインとして扱う）。DNSログで getsession.org への問い合わせをブロックして検知に使う、というのが現実的な短期対応になる。

感染後は .claude/ と .vscode/ で開発者マシンに居座る

Socket・StepSecurityの解析で嫌な部分は、payloadがCI runnerだけで終わらない点だ。開発者マシンに npm install が走った時にも、ローカルへ独立した永続化を仕掛ける。

確認されている書き込み先は以下のとおり。

  • ~/.claude/router_runtime.js、~/.claude/settings.json のhook定義書き換え
  • プロジェクト直下の .vscode/tasks.json への自動起動タスク追加

.vscode/tasks.json を書かれると、VS Codeでそのフォルダを開いた瞬間に攻撃者タスクが走る。.claude/settings.json のhookを書き換えられると、Claude Codeが起動するたびにpayloadが呼ばれる構造になる。どちらも npm uninstall や node_modules の入れ直しでは消えない。

対応の優先度としては、汚染を踏んだ可能性のある端末で次を見る。

  • ~/.claude/ 配下に身に覚えのない router_runtime.js や、書き換えられた settings.json がないか
  • プロジェクトの .vscode/tasks.json に追加された見覚えのないタスクがないか
  • VS Codeで該当プロジェクトを「自動で開く」設定にしている場合、その実行履歴

身に覚えのないファイルが見つかれば、その端末を侵害済みとして扱い、TanStack公式が挙げている認証情報の総入れ替えまで進める。

続報

Aikidoの後続記事を見ると、Mini Shai-HuludはTanStackとMistralだけで閉じていない。PyPI側のPyTorch Lightning、SAP向けnpm、偽のtanstackパッケージにも波及が観測されている。

PyTorch Lightningの侵害報告では、PyPIの lightning パッケージの 2.6.2 と 2.6.3 にMini Shai-Hulud系の悪性コードが確認されている（Lightning.aiが現在主に配布している統合パッケージ名は lightning で、旧名の pytorch-lightning ではない点に注意）。
npm側だけを見ていると見落とすが、Python環境でも同じ「install時にシークレットを取りに行く」系の確認が要る。特にML系のCIは、クラウド認証情報、モデル配布用トークン、実験管理サービスのAPIキーを持ちがちなので、影響範囲をJavaScriptプロジェクトに閉じない。

別のAikido記事では、SAP向けnpmパッケージもBunベースのpreinstall payloadで狙われたとされている。
GitHub、npm、クラウド、CIのシークレットを奪い、OhNoWhatsGoingOnWithGitHub 経由で拡散する流れなので、この記事で見たTanStackの router_init.js ＋ optional dependency型と同じく、依存解決中のlifecycle scriptが侵入口になる前提で扱う。

さらに、偽の tanstack パッケージが27分で4バージョン公開され、postinstallで .env を持っていく事例も出ている。
これは正規TanStackパッケージの侵害とは別口だが、同じニュースを見た開発者が名前で検索して入れてしまう二次被害の形に近い。lockfile上の @tanstack/* だけでなく、素の tanstack のような紛らわしい依存名も合わせて洗う。

PyPI側にもMistral SDKとguardrails-aiが追加

2026年5月12日付で、PyPIの mistralai==2.4.6 と guardrails-ai==0.10.1 がquarantine扱いになっている。StepSecurityのMini Shai-Hulud関連リストにも両者が載っている。

npm側の @mistralai/* だけを見ていると、Python側のMistral SDKを pip install で入れているMLパイプラインを見落とす。先に挙げたPyTorch Lightning 2.6.2/2.6.3と合わせて、PyPI側の侵害は3パッケージに広がった形だ。

guardrails-aiはLLM出力のガードレール用ライブラリで、AI系CIに入っている確率が高い。直近で mistralai や guardrails-ai を新しく入れた覚えがあれば、npm側と同じ基準（クラウド認証情報、HuggingFace token、各種APIキーのローテーション）まで踏み込む。

npm側でも @opensearch-project/opensearch@3.6.2 がStepSecurityのcompromised listに追加されている。TanStack／UiPath／Mistralだけでなく、検索基盤系のNodeクライアントまで届いている、という確認用の一行として置いておく。

2026-05-13時点での拡大状況

5月12〜13日にかけて影響範囲はさらに広がっている。Wizの追跡記事とHacker Newsのまとめ（OX Security集計）を合わせると、npm側だけで200近いパッケージに達し、累計DL数は518M、流出クレデンシャルの格納先として攻撃者が作成したGitHubリポジトリは400超に上る。

StepSecurityのレポートでは、TeamPCPの先行被害として intercom-client@7.0.4（2026-04-30公開）が整理されている。Mini Shai-Huludの「初手」はTanStackではなくIntercomクライアントnpmパッケージから始まっていたという読み方になる。Trivy（2026-03）、Bitwarden CLI（2026-04）、intercom-client（2026-04-30）、Checkmarx Jenkins AST Plugin（2026-05-09）、TanStack波（2026-05-11）の順だ。

このIntercom波で同時にPackagist側の intercom-php も侵害されていたことが、SANS ISC Weekly W18で整理されている。npm → PyPI → Packagistの3エコシステムを横断するワーム伝播が実環境で確認されたのはこれが初。「JavaScriptプロジェクトに閉じない」というのはML系PyPIだけでなく、PHPプロジェクトのcomposer install経路まで含めて読む必要がある。Laravel・Symfony系のCIで intercom/intercom-php を入れている環境は、npm側と同じローテーション基準を適用する。

5月13日時点で新しく確認された汚染範囲は以下の通り。

  • @uipath系: 50超 → 60超に増加
  • @draftauth scope: 既出の@draftlab系とは別口で追加
  • @opensearch-project/opensearch: Wizの追跡では 3.5.3 〜 3.8.0 の範囲が含まれる（StepSecurity初出の 3.6.2 単独より広い）

流出経路では、*.getsession.org 系ドメインの先にあるSessionメッセンジャー網そのものを使う動きが新規に確認されている。Sessionは分散型・暗号化されたメッセンジャーで、中央集権サーバを持たないためDNSブロックや単一ドメイン押収では止めにくい設計だ。短期的には getsession.org のDNSブロックで足を止められるが、攻撃者側がドメインを差し替えてきても次の窓は同じSession網に開く前提で見るほうが現実的になる。

攻撃グループTeamPCPと過去のTrivy・Bitwarden CLI・Checkmarx Jenkins侵害

StepSecurityのレポートは、今回の波を「TeamPCP」と署名する攻撃グループによる連続キャンペーンの一部として位置付けている。同グループは2026年3月にAqua SecurityのTrivyスキャナを、4月にはBitwarden CLIのnpm配布を侵害したとされる。Palo Alto Networks Unit42の連続キャンペーン解析では、Trivy → KICS → LiteLLM → VS Code拡張 → Bitwarden → SAP向けnpm → TanStack/Mistralまでが一本の作戦として整理されていて、「保護者を武器化する（Weaponizing the Protectors）」というフレームでセキュリティツール側のサプライチェーンが集中的に狙われていると説明されている。

毎回の手口に共通するのは、攻撃対象自体は正規メンテナの正規リリース経路だが、CIまわりの設定（fork PR、cache、OIDC、trusted publishing）に開いている穴をすり抜けて、正規identityで配布まで完走させる、という構造だ。OSやアプリ本体の脆弱性ではなく、CI/CDパイプラインの境界設計が攻撃面になっている。

実務上の含意は、自分のリポジトリの pull_request_target、cache scope、id-token: write の権限範囲、third-party actionのSHA pinning、trusted publishingのbranch/workflow pinningを、TanStackと同等以上に締めない限り、同じ手で踏まれうるということになる。攻撃グループは継続的に標的を変えながら同じテンプレートを使っているので、「自社はTanStackを使っていないから関係ない」という読みは成立しない。

Checkmarx Jenkins AST Pluginも侵害（2026-05-09）

TanStack波（5月11日）の2日前、2026年5月9日にCheckmarxのJenkins ASTプラグイン 2026.5.09 がTeamPCPによって侵害されたことが、The Hacker News、The Register、SecurityWeek によって報じられている。攻撃者は repo.jenkins-ci.org 上のAST plugin一覧ページの名前を Checkmarx-Fully-Hacked-by-TeamPCP-and-Their-Customers-Should-Cancel-Now に書き換え、説明文も改変している。露出窓の間に該当バージョンを取得したJenkinsインスタンスは侵害扱いになる。

最終クリーン版は2025年12月の 2.0.13-829.vc72453fa_1c16。Jenkins runnerから見えるシークレット（GitHubトークン、AWS／GCP／Azure認証情報、Kubernetes config、SSH鍵、環境変数経由のAPIキー）はすべて流出済みとして扱う、というのがCheckmarxの公式アナウンスのトーンだ。

Mini Shai-Huludの時系列を、TanStackだけ見ていると見落とすという意味で、ここはタイムラインに割り込んでくる。

Mandiantが1,000+ SaaS環境を集計、名指し済み下流被害組織

TeamPCPの一次侵害（Trivy・LiteLLM・Bitwarden・SAP・TanStackなどのCI/CD経路）から窃取されたCI/CD・クラウド・SaaSシークレットを使った下流侵害は、Mandiantの集計で1,000+ SaaS環境に達したとされる（SANS ISC Update 006）。後述のVectランサム連携で先に挙がっているGuesty・USHA International・S&P Global以外に、名指しで観測されている主な下流被害組織は次の通り。

組織経路・規模出典
CiscoTrivyスキャナ侵害経由でソースコード窃取SANS ISC Update 007
欧州委員会CERT-EUがクラウド侵害を確認Update 006
Sportradarスポーツデータプロバイダ、複数顧客系統に影響Update 006
Databricks主要クラウドプラットフォーム初の下流被害として調査中SANS ISC Update 004
MercorAIタレントマーケットプレイスがサプライチェーン由来の漏洩を確認Aviatrix脅威研究

Google GTIGはTeamPCPをUNC6780としてトラッキングを開始している。攻撃グループ名で複数のリサーチを突合する場合は、TeamPCP / UNC6780 / Vectアフィリエイト / BreachForumsスレッドの4軸で見ると、同じ作戦の別チャネル情報を取り損ねない。

実務上の含意は「初手の感染パッケージを自分が使っているか」ではなく、「初手から窃取されたシークレットでアクセスされうるSaaSを自分が使っているか」に変わる。TanStackもMistralも使っていない組織でも、過去半年以内にTrivy・Checkmarx KICS・Bitwarden CLI・LiteLLM・SAP系npm・Checkmarx Jenkins AST PluginのいずれかをCIで通していれば、Mandiantが集計した1,000+ SaaSの母集団に入りうる。被害の母集団を「踏んだ依存」から「アクセスされうるSaaS」に広げて棚卸する必要がある。

Vectランサムウェアとの提携で二次被害フェーズに入った

2026年4月15日に、VectランサムウェアグループがTeamPCPの一次侵害組織を標的化していることを公開掲示板で宣言し、Trivy/LiteLLMキャンペーン由来の不動産管理SaaS「Guesty」を最初の被害者として公開した（Halcyon Ransomware Alerts、Industrial Cyber、Socket）。約4百万件のメール、700GBのデータ流出を主張している。

その後リスト化された名指しの被害者として、

  • Guesty（不動産管理SaaS、Trivy/LiteLLMキャンペーン由来、約700GB）
  • USHA International（インド製造業、従業員データとSAPデータベース）
  • S&P Global（主張は公開済み、第三者では未確認）

の3組織が挙がっている。TeamPCPによる一次侵害でCI/CD・クラウド・SaaSのシークレットを抜かれた組織が、続いてVect側に標的化される構図だ。

なお、TeamPCPはVect提携と並列で、自前運営のランサムウェアCipherForceも回している（SANS ISC Update 004）。Vectが「BreachForumsアフィリエイト網（およそ30万登録ユーザー）を吸い込むRaaSの窓口」だとすると、CipherForceは「TeamPCP内製の独立運用ライン」で、同じ一次侵害下流から並走して標的化される。被害組織から見ると交渉相手が一本化されていないため、「Vect側に支払えば終わり」ではなく、別系統でデータが公開・破壊される可能性まで前提に組む必要がある。

ここで運用上ヤバいのは、Vectが「ランサムウェア」を名乗っていても実体はwiperで、復号化機能が存在しない点だ。Check Point Research、The Register、Halcyon、CSA Lab Space が独立に確認しているところでは、Vectは128KBを超えるファイルを破壊する設計になっている。VM disk、データベース、ドキュメント、バックアップなど、業務上意味のあるファイルはほぼすべて閾値を超えるため、身代金を払っても戻らない。

TanStack波で npm install を踏んだ組織は、

  • 「token revokeから始めない」（前述の gh-token-monitor でホスト全消し）
  • 「身代金を払って戻すという選択肢を最初から外す」（Vectで暗号化ではなく破壊が走っている）

の2点を、DR計画とインシデントレスポンス手順の両方に反映しておく必要がある。バックアップから戻す前提を強くする、オフライン保管・改竄不能なスナップショットを増やす、というところまで含めての準備になる。

トークン失効ワイプと地理的破壊ロジック

ここがこの攻撃でいちばん運用上ヤバい部分で、payloadには「token revokeを検知したら rm -rf $HOME を走らせる」dead man’s switchが仕込まれている。Semgrepの解析とDevOps Dailyの解説で確認されている。

仕込まれるのは gh-token-monitor という常駐デーモンで、

  • Linux: ~/.config/systemd/user/gh-token-monitor.service と ~/.local/bin/gh-token-monitor.sh
  • macOS: ~/Library/LaunchAgents/com.user.gh-token-monitor

の形で居座る。60秒ごとに盗まれたGitHub tokenでAPIを叩き続け、HTTP 40x（token失効）を検知すると ${CONFIG_DIR}/handler に保存された rm -rf "$HOME" を実行する。コード内には IfYouRevokeThisTokenItWillWipeTheComputerOfTheOwner という文字列が含まれていることがSemgrepの解析で確認されている。24時間トリガーされなければデーモンは静かに終了するので、ログを後追いしても気づきにくい設計だ。

別系統として、Upwindの解析では、システムがイスラエルまたはイランに在ると判定されると roulette.py という確率的モジュールが rm -rf / を実行する地理的破壊ロジックも報告されている。確率は明示されていないが、確率的にする狙いは「victim間で挙動が一致しないので相関解析が難しくなる」点にあるとUpwindは整理している。

実務上の含意は単純だ。「token revokeから始める」という普通のインシデントレスポンス手順は、この攻撃に対しては自爆操作になる。 順番を逆にする必要がある。

  1. ネットワーク隔離（C2への発信を止める＆token validation pingを止める）
  2. ~/.config/systemd/user/ と ~/Library/LaunchAgents/ から gh-token-monitor 系のserviceを停止・削除（systemctl --user stop / launchctl unload）
  3. ${CONFIG_DIR}/handler 等のpayload残骸も削除
  4. そのあとでnpm／GitHub／AWS／GCP／Kubernetes／Vault／SSH tokenのrevoke・ローテーション
  5. 端末はクリーンインストールから再構築する（.claude/・.vscode/ の永続化も含めて根を絶つ）

CI runner側は使い捨て扱いにできるならそれが最短だが、self-hosted runnerでlong-livedな構成だと同じデーモンが居座っている可能性があるので、上の順序を踏まないとrunnerホストの$HOMEまで巻き込まれる。

バージョンを上げるだけでは足りない

汚染バージョンをunpublishまたはdeprecateした後でも、すでにinstall済みの端末とrunnerは別問題だ。
TanStack公式も、2026年5月11日に該当バージョンをinstallした環境では、AWS、GCP、Kubernetes、Vault、GitHub、npm、SSHの認証情報をローテーションするよう求めている。

lockfileだけ見て終わると、CIの一時環境やcacheを見落とす。
GitHub Actions cache、npm/pnpm/yarnのpackage cache、self-hosted runnerのworkspace、artifact、最近のpublish履歴まで見る必要がある。
特にself-hosted runnerは使い捨てではないので、runnerごと再作成する判断が現実的になる。

TanStack側では全cache entryの削除、pull_request_target workflowの構造変更、repository owner guard、third-party actionのSHA pinningが入った。
自分のリポジトリでも、fork PRのコードを pull_request_target でcheckoutしてbuildしていないか、cacheがbase repo側に保存されていないか、id-token: write が広すぎないかを見直すところからになる。

参考にした一次・準一次情報はTanStack公式のPostmortem、AikidoのMini Shai-Hulud Is Back、Socketの解析記事、StepSecurityのレポート、Palo Alto Networks Unit42のTeamPCP連続キャンペーン解析、Snykの記事、Endor Labsの記事あたり。
Vectランサム連携についてはHalcyon、Industrial Cyber、Socket、Vect自体の挙動についてはCheck Point Researchを参照。
下流被害・CipherForce並列運用・UNC6780別名・3エコシステム横断（Packagist）はSANS ISCのTeamPCP連続トラッキング（Update 004 / Update 006 / Update 007 / Weekly W18）とAviatrix脅威研究のMercor事例を参照。
パッケージ一覧やIoCはまだ動いているため、最終確認は各社のAffected Packages And Versions / IoCセクションを直接見るのが早い。