ミニ・シャイ・フルード：TanStack、OpenAI、そしてnpmのSupply Chain

今回のサプライチェーン攻撃は、オープンソースのレジストリを侵害しただけにとどまりませんでした。世界でも有数のセキュリティ意識の高い組織の内部にあるリリースパイプラインを乗っ取ったのです。その侵入経路となったのは、ごくありふれたnpm依存関係のインストールでした。

2026年5月11日、脅威グループ「TeamPCP」は、現在「Mini Shai-Hulud」として追跡されている「Shai-Hulud」ワーム攻撃キャンペーンの第4波を実行した。 この攻撃により、npmレジストリ内の42のTanStackパッケージに属する84の悪意あるパッケージバージョンが、わずか6分の間に侵害された。その後、npmおよびPyPI（Python Package Index）のソースコードレジストリ全体で170以上のパッケージに拡大し、Mistral AI、UiPath、OpenSearchに属するネームスペースも含まれた。影響を受けたパッケージのうち少なくとも1つである@tanstack/react-routerは、週に約1,200万回のダウンロードを記録している。

これは、激化の一途をたどるキャンペーンにおける第4の波です。これまでの波には、最初のnpmへの侵入（Shai-Hulud 1.0）や、GitHubの認証情報を標的とした2.0の波などが含まれます。

OpenAIは今週、社員の端末2台が不正アクセスを受けたことを明らかにした。ユーザーデータ、本番システム、知的財産には影響がなかったものの、被害の封じ込めには、システムの隔離、認証情報の更新、外部フォレンジック調査の実施が必要となった。また、単一の依存関係のインストールが引き金となり、macOS、Windows、iOS、Androidの各プラットフォームにおいて、コード署名証明書の全面的な更新が行われた。

• 攻撃日：2026年5月11日

• 侵害されたパッケージ：42の@tanstack/*パッケージにまたがる84の悪意のあるバージョン。npmおよびPyPIレジストリ全体では170以上

• CVE:CVE-2026-45321、CVSSスコア 9.6（重大）

• 出典：TeamPCP（PCPcat、UNC6780としても追跡されている）

• 攻撃の仕組み：3つの連鎖するGitHub Actionsの脆弱性 — Pwn Request、キャッシュポイズニング、ランナープロセスのメモリからのOIDC（OpenID Connect）トークンの抽出

• 主な被害事例：OpenAI — 従業員2名の端末が侵害され、macOS、iOS、Windows、Android向けのコード署名証明書を含む機密情報が、社内ソースコードリポジトリから流出

• 過去のリリース：Shai-Hulud 1.0（2025年9月）、2.0（2025年11月）、および3.0（2025年12月）

• 影響： 開発環境およびCI/CD環境が侵害され 、メンテナのアカウントやパッケージが乗っ取られ、SLSAの来歴情報および署名付きビルドが「デフォルトで安全」ではなくなった

• 主なリスク：SLSA（Software サプライチェーンレベル）のビルドレベル3の来歴証明を通過する悪意のあるパッケージ

「Mini Shai-Hulud Wave Four」は、これまでの同キャンペーンの中で最も技術的に洗練された攻撃です。これまでの波では、侵害されたメンテナンス担当者のアカウントを利用して悪意のあるパッケージを直接公開していましたが、Wave Fourでは3つのGitHub Actionsの脆弱性を連鎖的に悪用し、正規のリリースパイプラインそのものを乗っ取りました。

攻撃の流れ：

1. フォークと偽装：攻撃者は TanStack/routerリポジトリをフォークし、GitHubのフォーク一覧画面で一目でフォークだと判別されないよう、zblgg/configurationという名前に変更した。
2. ワークフローのトリガー： プルリクエストが 作成され、pull_request_target ワークフローがトリガーされました。これは、フォークされたコードへのワークフローアクセスを許可する「Pwn Request」パターンです。
3. キャッシュの汚染：攻撃者の フォークコードは 、GitHub Actionsのキャッシュに1.1 GBの改ざんされたpnpm-storeエントリを書き込み、リリースワークフローが後でそれを復元するようにキーを設定した
4. 痕跡を消す： その後、悪意のあるプルリクエストは 強制的に「未処理」の状態にプッシュされ、閉鎖された。これにより、侵害の証拠を隠蔽した。
5. トリガーを待つ： TanStackの正規のメンテナが、本筋とは無関係なプルリクエストをmainブランチにマージした際 、リリースワークフローがトリガーされ、汚染されたキャッシュが復元された
6. Steal the token: Attacker-controlled binaries read /proc/<pid>/mem of the Runner.Worker process to extract the OIDC token minted for npm trusted publishing
7. パイプライン経由での公開：これらの トークンは、TanStack独自の正規のリリース・パイプラインを通じて、84個の悪意のあるパッケージ・バージョンをnpmレジストリに公開するために使用されました。
8. その結果、正規のリリースパイプラインによって生成され、有効なSLSAビルドレベル3の来歴証明、有効なSigstore証明、および正当なGitHub Actions署名を持つパッケージに、認証情報を盗むマルウェアが含まれていたことが判明した。TanStackが事後分析で明らかにしたように、開発者の視点からは、これらのパッケージは暗号的に真正なものに見え、侵害された兆候は一切見られなかった。

機密情報が流出：マルウェアのペイロードは 、侵害されたシステム上で実際にアクセス可能な認証情報やトークンといった機密情報を、3つの冗長化された経路（タイポスクワットドメイン（git-tanstack[.]com）、分散型メッセージングネットワーク「Session」、および盗まれたトークンを使用したGitHubAPI ）を通じて外部へ 持ち出した。 標的となった認証情報には、GitHubトークン、AWS、GCP、Azureのクラウドシークレット、CI/CD認証情報、Kubernetes認証情報、HashiCorpVault 、およびSSHキーが含まれていた。

開発者のマシン上では、このマルウェアは（macOSのLaunchAgentまたはLinuxのsystemdを介して）60秒ごとにGitHubをポーリングする永続的なgh-token-monitorデーモンをインストールしました。トークンの失効により40Xエラーを受信すると、このデーモンはrm -rf ~/を実行してユーザーのホームディレクトリを消去しようとしました。デーモンは24時間後に自動的に終了しました。

OpenAIの発表によると、流出した内容は以下の通りである。侵害を受けた2名の従業員がアクセス可能な内部ソースコードリポジトリの一部から、macOS、iOS、Windows、Android製品向けのコード署名証明書を含む、限定的な認証情報が流出した。 OpenAIは、これらの証明書が悪意のあるソフトウェアの署名に使用されたという証拠はないと確認していますが、予防措置としてすべての証明書を更新しており、macOSユーザーに対し、2026年6月12日までにアプリケーションを更新するよう求めています。この期限を過ぎると、古い証明書で署名されたアプリは動作しなくなる可能性があります。

OpenAIの開示内容には、注目すべきもう1つの詳細がある。侵害された2台のデバイスには、組織全体の環境に展開されていた、最小リリース期間の確認やパッケージの出所検証といった制御機能を含む、パッケージ管理の設定更新がまだ適用されていなかった。攻撃は、その展開期間中に発生した。

これは、実際に存在し、よく見られるセキュリティ上の脆弱性を示しています。セキュリティ対策は段階的に導入されるものです。段階的な導入期間中、一部のシステムはより大きなリスクにさらされます。TeamPCPによる攻撃キャンペーンは数週間にわたり継続的に行われ、レジストリに悪意のあるパッケージを公開し、それらがインストールされるのを待ち構えていました。このタイミングは決して偶然ではありませんでした。

「Mini Shai-Hulud」の期間中に影響を受けるパッケージをインストールした可能性があるすべての組織は、以下の点にご注意ください：

1. トークンを無効化する前に、gh-token-monitor デーモンが実行されていないか確認してください。まず、影響を受けるシステムを隔離し、イメージを作成してください。時期尚早な無効化を行うと、データ消去ペイロードが実行されます。
2. 影響を受けた期間中にパッケージをインストールした開発者やパイプラインについて、GitHub PAT、npmトークン、SSHキー、クラウド認証情報をローテーションしてください。また、多要素認証（MFA）を有効にしてください。
3. 侵害されたパッケージを削除する：npmキャッシュとnode_modulesをクリアし、2026年5月12日以降に公開されたパッケージのバージョンに固定する。
4. GitHub Actions および CI/CD ワークフローを監査する：予期しない公開イベント、新しいワークフロー、または見慣れないエンドポイントへの外部接続がないか確認する。
5. パイプラインを強化する：ライフサイクルスクリプトを制限し、外部ネットワークアクセスを制限し、トークンのスコープを最小化する。
6. 出所確認とコンテンツ検査を併用する：有効な出所情報はパイプラインの起源を示すものであり、その完全性を保証するものではない。マルウェアスキャンと認証検証を併せて実施する。