2025年9月に初めて確認され、同年11月に大規模化した自己増殖型npmワーム「Shai-Hulud 2.0」は、ソフトウェアサプライチェーンセキュリティの転換点となった。npm installを実行するだけで、開発者のマシンに潜伏し、npmトークンを窃取し、そのトークンで他のパッケージを汚染する──この「ワーム型」攻撃は25,000以上のリポジトリに影響を及ぼし、最終的にTrust Walletから850万ドルの暗号資産が流出する事態にまで発展した。本稿では、Shai-Hulud 2.0の技術的メカニズムを解析し、npmエコシステムが抱える構造的脆弱性と、組織が取るべき防御策を詳述する。

Shai-Hulud攻撃の時系列──200パッケージから25,000リポジトリへ

最初の感染は2025年9月14日、rxnt-authenticationパッケージのバージョン0.0.3として公開された。翌日、セキュリティ企業ReversingLabsがこの自己増殖型マルウェアを発見し、フランク・ハーバートのSF小説『デューン』に登場する砂虫にちなんで「Shai-Hulud」と命名した。9月23日にはCISA（米国サイバーセキュリティ・インフラストラクチャセキュリティ庁）が「npmエコシステムに影響を及ぼす広範なサプライチェーン侵害」として公式アラートを発行した。

第一波の影響は200〜500パッケージにとどまったが、2025年11月24日に確認された第二波「Shai-Hulud 2.0」は桁違いの規模で拡散した。ピーク時には30分ごとに約1,000の新規悪意あるリポジトリが生成され、最終的に25,000以上のリポジトリ、796のユニークなnpmパッケージ（合計週間ダウンロード数2,000万以上）が汚染された。約40万件のシークレットが流出し、そのうち約60%のnpmトークンは発覚後数週間経っても有効なままだったと報告されている。

技術解析──preinstallスクリプトとTruffleHogの武器化

Shai-Hulud 2.0の感染チェーンは、npmのライフサイクルスクリプトを悪用する点で第一波と共通するが、攻撃手法は大幅に洗練されている。第一波がpostinstallスクリプト（インストール完了後に実行）を使用したのに対し、2.0はpreinstallスクリプト（インストール開始前に実行）に移行した。これにより、テストやセキュリティチェックが実行される前にペイロードが展開される。

ペイロードはsetup_bun.jsやbun_environment.jsといった一見無害なファイル名で偽装され、10MB以上に肥大化した難読化コードとして配置される。実行されると、以下の4段階で攻撃が進行する。

第1段階：クレデンシャルハーベスティング
ワームは正規のシークレットスキャンツールTruffleHogのバイナリを自動的にダウンロードし、開発者のホームディレクトリを再帰的にスキャンする。.npmrcファイルに含まれるnpmトークン、GitHub Personal Access Token（PAT）、AWS・GCP・Azureの APIキー、SSHキーなどを体系的に収集する。発見されたシークレットは有効性が検証された上で窃取される。

第2段階：トークンの検証と悪用
窃取したnpmトークンでnpmレジストリに認証し、そのアカウントがメンテナンスする全パッケージを列挙する。1つの開発者アカウントから最大100パッケージが汚染対象となる。

第3段階：再帰的感染
列挙された各パッケージのソースコードに悪意あるpreinstallスクリプトを注入し、新バージョンとして公開する。この新バージョンを依存関係としてインストールした別の開発者のマシンでも同じプロセスが繰り返され、指数関数的に感染が拡大する。

第4段階：永続化と破壊
侵害したマシンをGitHub Actionsのセルフホステッドランナーとして登録し、GitHubインフラをC2（コマンド＆コントロール）基盤として利用する。窃取したクレデンシャルは「Shai-Hulud」や「Shai-Hulud: The Second Coming」と名付けられた公開GitHubリポジトリにコミットされる。なお、クレデンシャル窃取や外部への送出が失敗した場合、フォールバックとしてユーザーのホームディレクトリ全体を破壊する自滅コードも組み込まれている。

Trust Wallet事件──850万ドルの暗号資産流出

Shai-Hulud 2.0がもたらした最大の実害は、2025年12月25日に発覚したTrust Walletの侵害事件である。攻撃の流れは以下の通りだった。

まず、Shai-Hulud 2.0によるクレデンシャル流出でTrust Wallet開発者のGitHubシークレットが漏洩した。攻撃者はこのシークレットからChrome Web Store（CWS）のAPIキーとTrust Walletブラウザ拡張機能のソースコードへのアクセスを獲得した。悪意あるコードを拡張機能のバージョン2.68に注入し、窃取したCWS APIキーで公開した。ストアの審査を通過した改ざん版が自動配信され、2,520のウォレットから約850万ドルの暗号資産が抜き取られた。

Trust Walletはクリーンなバージョン2.69へのロールバック、公開アクセスとAPIクレデンシャルの無効化、デプロイメントの制限、ブロックチェーン分析会社との連携、被害ユーザーへの補償を表明した。この事件は、npmサプライチェーン攻撃が最終的に暗号資産の直接的窃取にまでエスカレートしうることを実証した。

npmエコシステムの構造的脆弱性と対応策

Shai-Hulud 2.0の成功は、npmエコシステムが長年抱えてきた構造的問題を浮き彫りにした。第一に、ライフサイクルスクリプトのデフォルト実行である。npm installは標準でpreinstall/postinstallスクリプトを自動実行するため、パッケージをインストールするだけで任意のコードが実行される。第二に、長寿命トークンの蔓延である。多くのnpmトークンは有効期限が設定されておらず、一度漏洩すると無期限に悪用される。第三に、公開操作のMFA不備である。トークンのみでパッケージを公開でき、多要素認証が必須ではなかった。

GitHubは2025年末に以下のロードマップを発表した。レガシーなクラシックトークンの廃止、ローカル公開時の2FA必須化（TOTPからFIDOベースへの移行）、公開権限付きトークンの有効期限を最大7日に制限、OIDCベースの「Trusted Publishing」の標準化である。これらは正しい方向性だが、完全な実施には時間を要する。

組織が今すぐ実施すべき対策は多岐にわたる。即時対応として、すべてのnpmトークン・GitHub PAT・SSHキー・クラウドクレデンシャルのローテーション、npm install --ignore-scriptsによるライフサイクルスクリプトの無効化、ロックファイル（package-lock.json）の整合性検証がある。中長期対策として、全開発者アカウントへのWebAuthn 2FA強制、グラニュラートークンへの移行と短い有効期限の設定、OIDC/Trusted Publishingの採用、SCA（Software Composition Analysis）ツールの導入、CI/CDでの一時的エージェント使用（永続的ランナーの廃止）が挙げられる。

ビルドプロセスの武器化が意味するもの

Shai-Hulud 2.0は単なるマルウェアの進化ではなく、ソフトウェア開発の最も基本的な行為──依存関係のインストール──が攻撃ベクトルとなりうることの決定的な証明である。従来のサプライチェーン攻撃（タイポスクワッティングやメンテナアカウントの直接侵害）とは異なり、ワーム型は一度の侵入から自律的に拡散するため、攻撃のスケーラビリティが根本的に変わった。

2016年のleft-pad事件がnpmの「可用性」の脆弱性を露呈したとすれば、Shai-Hulud 2.0は「完全性」と「機密性」の脆弱性を同時に突いた。パッケージの中身が改ざんされ（完全性の侵害）、開発者のクレデンシャルが窃取される（機密性の侵害）。この二重の脅威に対処するには、パッケージレジストリの認証強化だけでなく、ビルドプロセス全体のゼロトラスト化──すなわち、すべての依存関係を「信頼しない」前提で扱うセキュリティモデルへの転換が不可避である。

Shai-Hulud 2.0の教訓は明確である。npm installは単なるパッケージのダウンロードではなく、サードパーティコードの実行であり、それは本質的にリスクを伴う行為である。このリスクを正しく認識し、技術的・組織的な対策を講じることが、現代のソフトウェアサプライチェーンを守る出発点となる。

FAQ

Shai-Hulud 2.0とは何か？

npmのライフサイクルスクリプト（preinstall）を悪用し、TruffleHogで開発者のクレデンシャルを窃取した上で、盗んだnpmトークンを使って他のパッケージに自己を注入する自己増殖型ワームである。2025年11月に大規模化し、25,000以上のリポジトリが影響を受けた。

自分のプロジェクトが影響を受けたか確認する方法は？

npm auditを実行し、既知の脆弱性レポートを確認する。また、package-lock.jsonの差分を精査し、意図しないバージョン変更がないかチェックする。npmは侵害されたパッケージリストを公開しており、自身の依存関係と照合することを推奨する。

npm installの--ignore-scriptsオプションのデメリットは？

ネイティブモジュールのコンパイル（node-gypなど）やPostCSSの設定など、正当なpostinstallスクリプトに依存するパッケージが正常に動作しなくなる場合がある。影響範囲を事前にテストした上で段階的に導入することが望ましい。

Trusted Publishingとは何か？

OIDCベースの認証メカニズムで、CI/CDパイプラインから直接npmに公開する際に長寿命トークンではなく短命のトラストトークンを使用する方式である。GitHub Actionsとnpmの連携で利用可能であり、トークン漏洩リスクを大幅に低減する。

参考文献