感染源はソースコードではなく「設定ファイル」——npmを襲った新型ワームChainDrop

2026年8月4日、マイクロソフトをはじめとする複数のセキュリティ研究者が、JavaScriptのパッケージ配布サービス「npm」を舞台にした大規模な攻撃を検出しました。「ChainDrop（チェーンドロップ）」と名付けられた自己増殖型のマルウェアに感染したパッケージは、複数の公開元にまたがって444件。それらの合計ダウンロード数は、月あたりおよそ20億回にのぼります。この数字は感染した回数ではなく「感染したパッケージ群が普段どれだけ使われているか」を示すものですが、影響の届く範囲の広さが伝わる規模です。

感染したパッケージはすでにすべてnpmから削除されています。ただ、この事件が注目されているのは被害の規模だけが理由ではありません。ChainDropの侵入経路が、これまでの守り方の「盲点」を突くものだったからです。

npmと基盤パッケージの位置づけ

npmは、JavaScriptのプログラムが使う「部品（パッケージ）」を配る仕組みです。世界中の開発者が、ここから部品をダウンロードして自分のソフトに組み込みます。今回標的になったのは、keyv、flat-cache、cache-managerといった、多くのソフトが土台として使っている基盤に近いパッケージでした。土台が汚染されると、その上に建つものすべてに影響が及びかねない、という構図です。

こうした「部品の供給ルートを汚染する」攻撃は、サプライチェーン攻撃と呼ばれます。工場でいえば、完成品を直接狙うのではなく、納入される部品にあらかじめ細工をしておくやり方です。npmを狙ったサプライチェーン攻撃は以前からあり、2025年9月には「Shai-Hulud（シャイフルド）」と呼ばれる自己増殖型のマルウェアが登場していました。名前の由来はSF小説『デューン』に出てくる、砂の下を静かに移動する巨大な砂虫です。今回のChainDropは、マイクロソフトの分析によれば、このShai-Huludの変種にあたります。

これまでの守り方の前提

サプライチェーン攻撃への従来の対策は、大まかにいえば「ソースコードの置き場（リポジトリ）が書き換えられていないか」を見張ることでした。パッケージの中身はソースコードから作られるのだから、大元のソースコードを監視していれば異変に気づける——そういう前提です。依存しているパッケージを自動で検査するツールも広く使われていますが、それらが見ているのも基本的にはコードでした。

この前提は長らく機能してきました。実際、過去の攻撃の多くは、リポジトリへの不正なコミット（変更の記録）や、怪しいコードの混入という形で痕跡を残していたからです。逆にいえば、守る側の目は「コード」に集中していた、ということでもあります。

ソースコードに痕跡を残さない増殖方法

ChainDropは、そのソースコードを触りませんでした。

マイクロソフトの分析によると、ChainDropの増殖の仕組みはこうです。まず、感染したパッケージをインストールすると、インストールが完了する前に自動で実行される「preinstall」という仕組みを通じて、マルウェア本体が動き出します。動き出したマルウェアは、その環境にあるnpmの公開用トークン（パッケージを公開する権限の証明書のようなもの）や、クラウドの鍵、GitHubの認証情報などを探し回ります。探す場所はファイルや環境変数にとどまらず、実行中のメモリにまで及びます。

そして書き込み権限のあるnpmトークンを見つけると、そのトークンで公開できるパッケージの配布物——tarball（ターボール）と呼ばれる、パッケージの実体を固めた圧縮ファイル——をダウンロードし、そこに自分自身を混ぜ込んで作り直し、バージョン番号をひとつ上げてnpmに再公開します。

ここが従来と決定的に違う点です。この一連の流れのどこにも、ソースコードのリポジトリへの変更が含まれていません。実際、悪意あるバージョンの多くには、対応するコミットもプルリクエストも存在しませんでした。つまり、汚染されたパッケージのソースコードをいくら見比べても、見た目のうえでは何も変わっていない。監視カメラが向いていない場所で、荷物だけがすり替えられていた形です。

開発ツールの設定ファイルという第二の経路

ChainDropには、もうひとつの広がり方があります。盗んだGitHubの認証情報を使って、アクセスできるリポジトリを一覧し、そのブランチ（作業用の枝分かれ）に直接、悪意ある設定ファイルを書き込むのです。

狙われたのは、VS CodeやClaude Codeといった開発ツールが読み込む設定ファイル（.vscode/tasks.json や .claude/settings.json など）でした。これらのツールには、リポジトリを開いたときに設定ファイルの内容に従って処理を自動実行する仕組みがあります。本来は開発を便利にするための機能ですが、ChainDropはここに起動用の仕掛けを仕込みました。結果として、細工されたブランチを開発者がエディタで開くと、裏でマルウェアが起動し、認証情報の収集からまた同じサイクルが始まる——開発者から開発者へと渡っていく感染経路が生まれたわけです。

ここで大事なのは、これがVS CodeやClaude Codeというツール固有の欠陥ではない、という点です。「リポジトリに含まれる設定に従って何かを自動実行する」という仕組みは、いまの開発ツールが広く備えている標準的な機能で、ChainDropはツールそのものではなく、この仕組み全体を突きました。企業向けオープンソースセキュリティ企業ActiveStateのCEO、Abby Kearns氏は、この攻撃について「この隙間に気づいて、規模を伴って使った最初のキャンペーンだ」と指摘しています。依存関係を検査するツールは、そもそも設定ファイルを実行の入り口として見るようには設定されていなかった、というのがKearns氏の分析です。

つまりChainDropが突いたのは、「設定ファイルはただのデータであって、実行されるものではない」という、守る側の暗黙の前提そのものでした。Kearns氏の言葉を借りれば、これからは「リポジトリが持ち込む設定を、実行可能なコンテンツとして扱う」必要がある——いまや、それが実態だからです。

現在の状況と開発者が確認できること

冒頭で触れたとおり、感染が確認されたパッケージはすべてnpmから削除済みです。セキュリティ企業のSafeDepが、感染したパッケージとバージョン番号の一覧を公開しており、自分の環境で使っているものと照合できます。

Kearns氏が挙げている確認方法は、自分で追加した覚えのない .claude/settings.json や .vscode/tasks.json がリポジトリにないかを見る、というものです。このとき、メインのブランチだけでなく、すべてのブランチを確認することが勧められています。マイクロソフトは、感染した可能性のあるパッケージを取り込んだ環境については、そこからアクセスできた認証情報を漏れた前提で扱い、クリーンな環境から鍵やトークンを作り直すことを推奨しています。あわせて、npmのコマンドラインツールを新しいバージョン（v12）に更新し、公開されたばかりのバージョンをすぐ取り込まないようにする設定（min-release-age）を使うことも挙げられています。

今回の件が残した教訓は、開発の現場を超えて一般化できるものかもしれません。「ただのデータだと思っていたものが、いつのまにか実行されるものになっていた」——便利さのために自動化を積み重ねていくと、その自動化のひとつひとつが、意図しない入り口にもなりうる。Kearns氏は「これが最後の一件にはならないだろう」とも書いています。ソースコードの監視という守りが無意味になったわけではありませんが、見張るべき場所がひとつ増えたことは、確かなようです。