Mini Shai-Hulud 攻撃への対応：2FA-Bypass Token の無効化を npm が実施

Mini Shai-Hulud Attack Prompts npm to Revoke 2FA-Bypass Tokens

2026/05/22 gbhackers — npm は、プラットフォーム全体で granular access token を強制リセットし、二要素認証 (2FA) の回避を阻止した。この対応は、Mini Shai-Hulud キャンペーンに関連する一連のサプライチェーン攻撃により、数百の JavaScript パッケージが侵害されたことを受けてのものだ。

この緊急対応は 2026年5月19日に実施され、2FA を使用せずに公開操作を可能にする、すべての書き込み権限付き npm トークンが無効化された。先日の攻撃で、メンテナー・アカウントが乗っ取られ、@antv エコシステム内の広く利用されるパッケージに悪意のコードが注入されたが、このインシデントを受けての対応が実施されたことになる。

直接の引き金は npm メンテナー・アカウント “atool” の侵害である。単一の自動化処理を実施した攻撃者は、323 件のパッケージに対して 639 件の悪意のバージョンを公開した。影響を受けたライブラリには、echarts-for-react／timeago.js／size-sensor／canvas-nest.js などの、ダウンロード数の多いパッケージが含まれる。

このインシデントは、同一キャンペーンに関連する、過去の侵害に続くものであり、2026年5月11日には TanStack パッケージ 42 件が侵害されている。このときは、複数の悪意のバージョンが配布され、数百万の下流ユーザーに影響を与えた。

npm は、「今回のリセットは、窃取された認証情報の再利用を防止するために必要なものだった。Mini Shai-Hulud の攻撃パターンに従うサプライチェーン攻撃を防止するために、2FA を回避するすべての書き込みトークンを無効化した」と述べている。

npm granular access token invalidation to prevent supply chain (Source : Socket).
npm granular access token invalidation to prevent supply chain (Source : Socket).

Socket の研究者が追跡した結果として、このキャンペーンは TeamPCP と呼ばれる脅威グループに帰属し、広範なエコシステムに影響を与えていることが判明した。npm／PyPI／Composer にまたがる 500 以上のプロジェクトにおいて、1,000 件を超えるパッケージ・バージョンが侵害されている。

標的化されたものには、Bitwarden CLI／Aqua Trivy／SAP CAP／TanStack などの主要な開発ツールとプラットフォームが含まれる。特筆すべき事例として挙げられるのは、Visual Studio Code エクステンションの更新を悪用する攻撃者が、GitHub の内部リポジトリに侵入し、約 3,800 のリポジトリからデータを外部送信したインシデントである。

この攻撃チェーンには、npm トークンの窃取に頼らないものもある。その代わりに、GitHub Actions のキャッシュ汚染や runner メモリからの OIDC トークン抽出といった手法を用いて、CI/CD パイプラインを悪用している。

Mini Shai-Hulud 攻撃が npm に対応を促す

npm によるトークンの無効化により、すでに窃取された認証情報の悪用が遮断されるが、根本的な攻撃ベクターが排除されるわけではない。2FA 回避トークン・モデルは、自動公開ワークフローを支援するために存在するが、CI 環境で長期間にわたり有効なシークレットの露出によるリスクを引き起こす。

この種の環境を標的とする Mini Shai-Hulud マルウェアは、npm トークン／クラウドキー／SSH 資格情報／API シークレットなどをスキャンする。それらを取得した攻撃者は、正規パッケージに対する侵害バージョンを、自動的に再公開する経路を手にする。

Staged Publishing Lands in Public Preview (Source : Socket).
Staged Publishing Lands in Public Preview (Source : Socket).

npm が推奨する “Trusted Publishing” モデルも課題を示している。このモデルでは、静的シークレットの代わりに短命な OIDC (OpenID Connect) トークンが使用される。ただし、TanStack 侵害では、実行中の CI ジョブからの OIDC トークンの抽出と再利用を成功させた攻撃者が、保護の回避を達成している。

これに対応して npm は、より強固な対策である staged publishing を導入した。2026年5月20日にパブリック・プレビューとして公開された、この機能は、パッケージ公開前における人手による承認ステップを必須とするものだ。

staged publishing の仕組み

  • CI 経由で公開されたパッケージは、最初にステージング環境に配置される。
  • メンテナーは多要素認証により、リリースを承認する必要がある。
  • 承認されたパッケージのみが、公開インストール可能になる。

たとえば、CI パイプラインを侵害した攻撃者が、悪意のバージョンを公開しても、メンテナーが確認／承認するまで、そのリリースはステージングに留まる。

この機能はオプションであり、パッケージ単位で設定が必要であるため、大規模エコシステムでの導入は遅れる可能性がある。

現時点でメンテナーに求められるのは、トークンの再生成および、影響を受けた自動化ワークフローの更新である。npm トークンに限らず、露出の可能性がある環境に関連する、すべての資格情報をローテーションすることを、セキュリティ専門家たちは推奨している。

追加の防御策は以下である。

  • 重要パッケージに対する staged publishing の有効化。
  • CI ワークフローの制限と、トークン露出の最小化。
  • リリース遅延制御 (最短リリース期間など) などを用いた即時インストールの回避。

Mini Shai-Hulud キャンペーンが示すのは、従来の認証情報窃取だけではなく、開発ツールや自動化パイプラインを通じて、現代のソフトウェア・サプライチェーンが攻撃されるというトレンドである。

npm のトークン・リセットにより、即時の封じ込めが実現される。ただし、長期的な防御を達成するためには、staged publishing のような強化された制御と CI/CD セキュリティ実践の普及が必須となる。

これらの有効な対策を、どれだけ迅速にメンテナーが導入できるかにより、次のサプライチェーン攻撃への耐性が定まってくる。

訳者後書：npm の方針変更の背景にあるのは、 自動公開ワークフローを支援するために用意されていた、 二要素認証 (2FA) を回避する書き込み権限付きのトークンの窃取と悪用です。 開発環境の自動化処理に使われる、長期間にわたり有効な認証情報の管理のギャップを突く攻撃が展開されています。 攻撃者は、メンテナーのアカウントや CI/CD パイプラインからトークンを盗み出し、多数の正規パッケージを装う、悪意のバージョンを自動で公開／配布してしまいました。 自動化の利便性と、 認証を多段階で保護することのバランスの難しさを伝える事例です。よろしければ、カテゴリー AuthN AuthZ も、ご参照ください。