セキュリティ
Shai-Hulud亜種が444個のパッケージを汚染、tarballや開発ツールのフックを介して拡散
npmワーム「Shai-Hulud」の新たな亜種が数百個のパッケージを汚染しました。この亜種は、対応するソースリポジトリにほとんど痕跡を残さない拡散手法を新たに備えています。
フランク・ハーバートの小説『デューン砂の惑星』において、Shai-Huludとは惑星アラキスの地表下を静かに移動する、自己維持能力を持つ巨大な砂虫の名前でした。2025年9月、コンピューターワームのような挙動を示す新種の自己複製マルウェアが出現した際、セキュリティ研究者たちがハーバートの架空の生物にちなんで命名したのも納得です。
しかし、Microsoftなどが「ChainDrop」と名付けた最新のShai-Hulud亜種は、単なる続編にとどまりません。npmコミュニティは今、オープンソースリポジトリの通常の安全対策を回避する、新たなステルス機能を備えたShai-Hulud亜種の拡散を発見しています。
8月4日、複数のセキュリティ研究者が、このShai-Hulud亜種を用いた大規模なnpmサプライチェーン攻撃を確認しました。この攻撃では複数の発行元にまたがる444個のパッケージが感染しており、これらは合計で月間約20億回ダウンロードされています。この攻撃は、keyv、flat-cache、cache-managerなど、広く利用されている深部インフラ依存パッケージを標的にしていました。
エンタープライズ向けオープンソースセキュリティ企業ActiveStateのCEOであるアビー・カーンズ氏は、Mediumへの投稿で指摘しています。今回の攻撃で特筆すべきは、オープンソースリポジトリの防御を突破する典型的な手法を使っていない点だといいます。
感染したパッケージをインストール(npm用語でいう「npm install」)しなくても、被害に遭う可能性があります。それも感染経路の一つではあるものの、それだけではありません。ChainDropは実行されると、リポジトリの設定ファイル自体に起動フックを仕込みます。つまり、感染したGitブランチをVS CodeやClaude Codeで開くだけで、リポジトリがChainDropの制御下に置かれてしまうのです。
コード自体をいくら精査しても、改ざんの証拠は見つからないかもしれません。ChainDropはリポジトリのソースコミットを介してではなく、ファイルパッケージのダウンロード用アーカイブ形式である「tarball」を介して拡散するからです。
tarballを介して移動するChainDrop
このソフトウェアは実行されると、ユーザーのワークスペースを走査し、フル書き込み権限を持つnpmトークンや、クラウドキー・シークレットといった他の認証情報を探索します。シェルの設定ファイル、環境変数、さらには稼働中のメモリまで調べ上げます。窃取したデータはすべて暗号化され、攻撃者が管理するエンドポイントへ送信されます。
npmトークンが見つかると、そのトークンがフルアクセス権を持つすべてのパッケージのtarballをダウンロードし、リポジトリ自体を経由せずに処理を進めます。
ここが巧妙な点です。ChainDropは自らのペイロードを組み込んでtarballを再構築することで自己複製します。ソースコードリポジトリをいくら確認しても、不正の証拠は見つかりません。
ChainDropの攻撃は二段構えです。GitHubの認証情報も探索対象で、見つかった場合はGitHub APIに問い合わせ、アクセス可能なすべてのリポジトリとブランチを列挙したうえで、悪意ある設定コードをそれらのブランチへ直接コミットします。
そのため、他の開発者がClaudeやVS Codeを使ってこれらのリポジトリを開くと、バックグラウンドタスクが起動して認証情報を収集し、この一連のサイクルが再び始まってしまいます。
開発者ができる対策
npmはCI/CDパイプラインに広く組み込まれており、再ビルド時に依存パッケージのパッチ更新を自動で取得することも多いため、この攻撃は特に厄介です。ワームが新しいビルドに入り込む経路を与えてしまうのです。
感染の疑いがある場合、まず確認すべきは、自分が追加した覚えのない.claude/settings.jsonや.vscode/tasks.jsonといったファイルの有無だと、ActiveStateのカーンズ氏は助言しています。確認はメインブランチだけでなく、他のすべてのブランチについても行う必要があります。
感染が確認されたパッケージはすべて、npmから速やかに削除されました。オープンソースセキュリティ企業のSafeDepは、汚染されたパッケージのバージョン番号付きの一覧を公開しています。現在稼働中の環境と照合して確認することをお勧めします。
後始末をするだけでなく、開発者とセキュリティチームは、ChainDropを踏まえて自分たちのシステムがどのように侵害され得るかを改めて見直す必要があります。
まず手を付けるべきは、GitHub Actionsのような信頼された発行ツールの評価です。「リポジトリから供給される設定情報を、実行可能なコンテンツとして扱う」姿勢に転換すべきだと、カーンズ氏は記しています。実際、それが現実だからです。
「今回のキャンペーンが実際に見つけ出したのは、依存関係スキャンツールが監視対象として設定していなかった実行経路でした。しかもそれは、エンジニアリング組織がこの2年間、できる限り急いで導入してきたまさにそのツールの内部に潜んでいたのです」とカーンズ氏は記しています。「このギャップに気づき、大規模に悪用した攻撃キャンペーンとしては、これが最初の例です。そして、これが最後にはならないでしょう」®
