2025年後半、npmエコシステムを震撼させた自己複製型ワーム「Shai-Hulud」が、2026年に入り新型亜種として再出現している。本記事では、500以上のパッケージを汚染した初期攻撃から、Dead Man's Switchによるデータ破壊機構を実装した2.0、そして強化された難読化技術を持つ3.0まで、その技術的進化を解説する。エンジニア・CTOが今すぐ実施すべき依存関係管理と防御策を、CISAガイダンスと共に提示する。

Shai-Hulud攻撃の全貌 ── 3つの波

「Shai-Hulud」という名称は、SF小説『砂の惑星』に登場する巨大砂虫に由来する。その名の通り、このマルウェアはnpmエコシステムの「砂の下」を這い回り、パッケージからパッケージへと自己複製しながら拡散する。Unit 42の調査により、2025年9月に最初の攻撃が確認されて以来、3つの大きな波が観測されている。

第1波（2025年9月）では、180以上のnpmパッケージが汚染され、GitHub Personal Access Token（PAT）やAWS・GCP・Azureのクラウド認証情報が窃取された。CISAは2025年9月23日に緊急アラートを発出し、被害総額は約5,000万ドル（約75億円）の暗号資産盗難に達したと報告されている。

第2波「The Second Coming」（2025年11月21〜24日）は、攻撃の自動化と規模において前例のない水準に達した。Check Pointの分析によれば、わずか72時間で621のnpmパッケージが感染し、25,000以上のGitHubリポジトリが侵害された。487の組織から14,206件のシークレットが漏洩し、そのうち2,485件は調査時点でも有効な認証情報であった。

第3波（2025年12月29日〜）では、Upwindのセキュリティ研究者により「@vietmoney/react-big-calendar@0.26.2」パッケージで新型亜種Shai-Hulud 3.0が検出された。強化された難読化技術と永続化メカニズムを備え、検知回避能力が大幅に向上している。

技術的メカニズム ── preinstallスクリプトとBunランタイム

Shai-Huludの特徴的な攻撃ベクトルは、npmのライフサイクルスクリプトを悪用する点にある。従来のマルウェアがpostinstall（インストール後）で実行されるのに対し、2.0以降はpreinstall（インストール前）フェーズで悪意あるコードを実行する。これにより、インストールが失敗した場合でもマルウェアは実行され、セキュリティスキャンやテストが行われる前に攻撃が完了する。

攻撃ペイロードは2つのコンポーネントで構成される。まずsetup_bun.jsがBunランタイムをインストールし、次にbun_environment.jsが本体の悪意ある機能を実行する。Node.jsではなくBunを使用する理由について、Zscalerの分析では「大半のセキュリティツールやサンドボックスはNode.jsの挙動を監視するよう最適化されている」ため、検知を回避できるとしている。

データの外部送信には、従来型のC2（Command and Control）サーバーではなく、公開GitHubリポジトリが使用される。攻撃者は「Sha1-Hulud: The Second Coming」とラベル付けされたリポジトリを作成し、窃取したシークレットをアップロードする。正規のGitHubトラフィックに紛れ込むことで、ネットワーク監視による検知を困難にしている。

Dead Man's Switch ── 復旧を阻むデータ破壊機構

Shai-Hulud 2.0で導入された最も危険な機能が「Dead Man's Switch」（デッドマンスイッチ）である。これは、マルウェアの伝播・外部送信チャネルが遮断された場合に、感染システム上のデータを破壊する自己防衛メカニズムである。

具体的には、マルウェアはGitHub（外部送信用）とnpm（拡散用）への接続を継続的に監視する。両チャネルへのアクセスが同時に失われた場合、破壊ペイロードがトリガーされる。Windows環境ではcipherコマンドによるファイル上書き、Unix/Linux環境ではshredコマンドによるセキュアな消去が実行され、フォレンジック調査によるデータ復旧は事実上不可能となる。

このメカニズムは、防御側に深刻なジレンマを突きつける。マルウェアのC2チャネルをブロックするという一般的な対策が、かえってデータ破壊を誘発するリスクを生むためである。単純なネットワーク遮断ではなく、感染端末の慎重な隔離と段階的な修復が求められる。

クロスエコシステム拡散のリスク

現時点でShai-Huludの直接的な被害はnpmエコシステムに集中しているが、他のパッケージリポジトリへの拡散リスクも顕在化している。PyPIの公式ブログ（2025年11月26日）によれば、Shai-Huludに侵害されたリポジトリ内でPyPIの認証情報が露出した事例が確認されている。

さらに、Maven Centralでは「org.fasterxml.jackson.core/jackson-databind」を装った悪意あるパッケージが発見されており、正規のJackson JSONライブラリに見せかけた多段階攻撃チェーンが実装されていた。Dark Readingの2026年予測記事では、Shai-Huludから学んだ手法がPyPI、Maven、RubyGemsへと横展開される可能性を警告している。

この脅威の背景には、各エコシステムに共通する構造的脆弱性がある。メンテナー認証情報の漏洩、ライフサイクルスクリプトの自動実行、そして「信頼された依存関係」という前提に依存した開発ワークフローである。サプライチェーン攻撃は単一のエコシステムを超えて、ソフトウェア開発全体の信頼基盤を揺るがしている。

防御策 ── エンジニア・CTOが今すぐ取るべきアクション

CISAおよび各セキュリティベンダーの推奨事項に基づき、以下の多層的防御策を提示する。

即時対応（感染確認時）

  • 依存関係マニフェスト（package.json）とロックファイル（package-lock.json、pnpm-lock.yaml）を監査し、侵害されたパッケージを特定・除去する
  • npmキャッシュをクリア（npm cache clean --force）し、信頼できるソースから再インストールする
  • 開発環境・CI/CDパイプラインのすべてのシークレットをローテーションする
  • GitHubのセルフホステッドランナーを監査し、不正なエントリを削除する
  • リポジトリ内のワークフローファイル（.github/workflows/）を検査し、不審なファイルを除去する

予防策（恒久的対策）

  • ライフサイクルスクリプトの無効化：--ignore-scriptsをデフォルトとし、必要な場合のみ明示的なallow-listで許可する。pnpmは2025年よりスクリプトの実行をオプトイン方式に変更している
  • ロックファイルの厳格な管理：CI環境ではnpm ciを使用し、lockfile-lintで改ざんを検知する
  • SBOM（Software Bill of Materials）の生成・監査：npm sbomやcdxgenを用いてCycloneDX/SPDX形式のSBOMを生成し、依存関係の透明性を確保する
  • 多要素認証の強制：GitHub・npmアカウントにMFAを必須化する。npmは2025年12月より新規パッケージにデフォルトで2FAを有効化している
  • レガシートークンの廃止：2025年末のnpmによるレガシートークン廃止に対応し、細粒度アクセストークンへ移行する

FAQ

Shai-Huludに感染しているかどうかを確認する方法は？

Snyk、Socket、Sonatypeなどのセキュリティツールで依存関係をスキャンする。また、GitHubリポジトリに「Sha1-Hulud」を含むdescriptionの不審なリポジトリがないか確認し、.github/workflowsディレクトリ内の見覚えのないワークフローファイルをチェックする。

Dead Man's Switchが発動した場合、データは復旧できるか？

cipherやshredコマンドによる上書き消去が実行されるため、一般的なデータ復旧は困難である。感染確認後は、ネットワーク遮断前にバックアップからの復旧手順を確立し、段階的な隔離を行うことが推奨される。

preinstallスクリプトを完全に無効化しても問題ないか？

一部のパッケージ（ネイティブアドオンのビルドなど）は正当なpreinstallスクリプトを必要とする。--ignore-scriptsで全体を無効化しつつ、信頼できるパッケージのみallow-listで許可する運用が現実的である。

npmだけを監視していれば安全か？

いいえ。Shai-Huludは窃取した認証情報を通じて他エコシステム（PyPI、Maven、RubyGems）への横展開リスクがある。すべてのパッケージリポジトリの認証情報をローテーションし、SBOM監査を横断的に実施すべきである。

CI/CDパイプラインで最も優先すべき対策は？

セルフホステッドランナーの監査とシークレット管理の強化である。Shai-Huludは感染システムをGitHubランナーとして登録し、さらなる権限昇格を試みる。ランナーの定期的な棚卸しとシークレットの最小権限原則が重要である。

参考文献