npm ワームが 111日ぶりに再出現：レジストリ・レベルでのマルウェア・スキャンの限界が明らかに

Known npm Worm Returns After 111 Days and Security Scanning Still Let It Through

2026/09/08 gbhackers — 既知の Shai-Hulud npm ワームのペイロードが 111日間の活動休止を経て再び出現し、レジストリ・レベルのマルウェア・スキャンは有効に機能しているのかという、新たな疑問が生じている。2026年5月の攻撃キャンペーンでは、侵害された 1 つのメンテナ・アカウントを起点として、短期間でソフトウェア・サプライチェーンのインシデントへ発展する可能性が示された。この攻撃者は、広く利用されている可視化／フロントエンド関連の依存関係を含む、複数の npm パッケージの悪意のあるバージョンを公開していた。

このマルウェアはインストール時に実行され、開発者のワークステーションや CI/CD ランナーから認証情報を収集した後、窃取した npm 公開用トークンを悪用して他のパッケージへ感染を拡大した。今回新たに確認された活動が注目されるのは、新しい回避手法が導入されたためではなく、むしろ、既知のペイロードが新たな手法を使用せずに再出現したためである。

研究者は、再出現したペイロードを SHA-256 ハッシュ e37e3ddeeaaa9e0c4fdbcb829b4895a6521031c80053fc436625b61e6ee5b1a6 により特定し、以前の @antv を標的とした攻撃で確認されたものと同一のアーティファクトであることを確認した。検出履歴によると、2026年5月19日の時点で、このハッシュを含む 319 件のパッケージ・バージョンが確認されていたが、その後は 9月7日まで新たな検出がなく、活動休止期間は 111日間に及んだ。

このワームは、同じ npm アカウントから 1 時間以内に公開された以下の 4 件のパッケージで再出現したと報告されている。

feishu-docx-mcp@0.3.2／bmc-i18n-extract-cli@1.1.1／blueai-cli@0.7.0／bmc-translate-utils@1.1.1

パッケージ数が少ないからといって、今回のインシデントを軽視すべきではない。既知の悪意のあるバイナリが 3 カ月以上経過した後、変更されることなく再出現したことは、レジストリ・スキャンや、脅威インテリジェンスの取り込み、パッケージの信頼性評価といった基本的な防御機能の有効性を問う事例である。

特に懸念されるのは、すでに npm が公開時のマルウェア・スキャンを導入し、新しく公開されたパッケージをインストール可能な状態に移行する前に、短時間保留して自動解析するよう設計されている点である。Aikido の研究者たちによると、再び活動を開始したパッケージには、5月19日に発生した @antv エコシステム内の数百件のパッケージ侵害と関連付けられたものと、完全に同一のペイロードが取り込まれていた。

npm ワームが 111 日ぶりに再出現

SHA-256 ハッシュの完全一致は、マルウェア防御において最も単純な検出方法の 1 つである。それにより、不審なコードの実行／難読化の解除／多段階の配信ロジックの解析／サンドボックス内でのペイロードの挙動解析を必要とせずに、既知の悪意のフィンガープリントを検出できる。今回のハッシュも、すでに公開情報として解析され、大規模なサプライチェーン攻撃との関連が確認されていた。

以前の Mini Shai-Hulud の活動では、preinstall などの悪意のあるライフサイクル・フックを利用して npm install の実行中にコードを実行している。影響を受けた @antv パッケージでは、注入されたローダーが bun run index.js を使用していた。また、一部のリリースには任意の GitHub リポジトリへの依存関係も含まれ、通常の npm パッケージのペイロードとは別の実行経路が作られていた。

このマルウェアは実行後に、GitHub／npm のトークン／クラウド認証情報／SSH キー／Docker 認証ファイル／Kubernetes サービス・アカウント・トークン／Vault シークレット／環境変数／データベース接続文字列を探索する。さらに、CI/CD インフラも標的とし、有効な GitHub トークンを取得した場合には、攻撃者が制御するリポジトリを作成して窃取したデータを保存していた。

この攻撃キャンペーンは、ワームとしての機能を備えているため、従来の認証情報窃取型マルウェアと比べて大きな危険性がある。攻撃者は窃取した npm 認証情報を悪用して、メンテナが公開権限を持つパッケージを列挙し、パッケージ・アーカイブへの悪意のあるコードの注入／バージョン番号の更新／パッケージの再公開を行うことで、侵害された各メンテナ・アカウントから別のプロジェクトへ感染を拡大する可能性がある。

公開時のスキャンは依然として有効だが、今回の事例が浮き彫りにしているのはその限界である。暗号化された新種で、複数段階で動作し、限定された実行時条件でのみ有効化されるマルウェアは公開前に確実に分類することが難しい一方、公開情報として記録された悪意のあるハッシュと一致する未変更のファイルについては、最低限のブロック条件とすべきである。

さらに、ハッシュのみに依存したスキャンは、それが正常に機能した場合であっても十分な防御にならない。攻撃者は、1 バイトの変更／アーカイブの再パッケージ化／難読化方式の変更／リモート依存関係へのペイロードの移動によって、悪意の機能を維持したまま新しいフィンガープリントを生成できる。Shai-Hulud の過去の攻撃キャンペーンでも、難読化された JavaScript／ライフサイクル・フックによる実行／GitHub でホストされた特殊な依存関係などを悪用して、攻撃対象領域を拡大する手法が確認されている。

組織にとって必要なことは、新たに確認された 4 件のパッケージ・バージョンと過去の Shai-Hulud のインジケーターについて、ロック・ファイル／パッケージ・キャッシュ／ビルド・ログ／ソフトウェア部品表 (SBOM) を直ちに確認することだ。影響を受けるリリースをインストールしたチームは、開発者のエンドポイント／CI ランナーが侵害されている可能性を考慮し、npm と GitHub のトークンのローテーション、クラウドとデプロイメント関連の認証情報の確認、未認可のパッケージ公開活動の調査を実施する必要がある。

また、セキュリティ・チームは、package.json の変更を確認するとともに、特に preinstall／postinstall／Bun または未知のシェル・スクリプトを呼び出すコマンドなど、予期しないライフサイクル・スクリプトの存在を調査する必要がある。以前の攻撃キャンペーンでは、.vscode/tasks.json／.claude/settings.json も変更されていたため、これらの設定ファイルも確認する必要があり、パッケージを削除するだけでは、侵害されたシステムから永続化の仕組みを排除できない可能性がある。

変更されていない Shai-Hulud のペイロードが再出現したという事実は、サプライチェーン・セキュリティを公開後の検出やレジストリによる安全性の保証だけに依存させることはできないことを改めて示している。ワームが検出される前に実行される機会を減らすには、ロック・ファイルによる依存関係の固定、メンテナ用トークンの権限範囲の制限、短期間で失効する認証情報の使用、CI におけるライフサイクル・スクリプトの制限、新しく公開されたバージョンの採用延期が有効である。

IOC

NetworkFilesPersistence
t[.]m-kosche[.]com Command-and-control (C2) domain linked to the original May campaign wave.	SHA-256: e37e3ddeeaaa9e0c4fdbcb829b4895a6521031c80053fc436625b61e6ee5b1a6Root-level index.js payload.preinstall script executes bun run index.js.	.vscode/tasks.json can configure Visual Studio Code tasks that execute attacker-controlled commands..claude/settings.json can modify Claude Code/project settings to support execution.

Note: IP アドレス／ドメインは、誤って名前解決／ハイパーリンク化されることを防ぐため、意図的にデファングされている (例：[.])。リファングは MISP／VirusTotal／SIEM など、管理された脅威インテリジェンス・プラットフォーム内でのみ実施する。

JavaScript エコシステムを支える npm パッケージの安全性を揺るがす問題が起きています。乗っ取られたメンテナ・アカウントを経由して既知の Shai-Hulud ワームが再出現し、レジストリ側の検証機構をすり抜けて悪意あるコードが配布されました。開発環境や CI/CD ランナーからの各種認証情報窃取／他プロジェクトへの自動的な二次感染といった深刻な影響が生じます。対応策として、依存関係ログや package.json の確認／トークン類のローテーション／自動実行スクリプトの制限が求められます。