2026年7月にリリース予定のnpmの次期メジャーバージョンであるv12では、デフォルトで依存関係のインストールスクリプトが実行されなくなります。
その話を聞いて安心しました。インストールスクリプトを無効にすることは、npmがデフォルト設定で実施できる最も有益な変更です。昨年、コミュニティはNx s1ngularityやShai-Huludなど、postinstallスクリプトを悪用した一連のサプライチェーン攻撃に見舞われました。今回のnpmのアップデートは、長らく待ち望まれていた変更であり、サプライチェーン攻撃の巨大な攻撃経路を縮小することになるでしょう。
npmの変更点
実行すると npm install 今日では、依存関係ツリー内のどこにあるパッケージでも、次のようなライフサイクルスクリプトを定義することができます preinstall, インストール、または postinstall、そしてnpmが自動的にそれらを実行します。このコードは、インストールした瞬間、何かをインポートしたり独自のコードを実行したりする前に実行されます。
v12では、そのような問題は解消されます。スクリプトは、`npm approve-scripts` で作成した許可リストに登録されたパッケージに対してのみ実行され、それ以外は `npm deny-scripts` でブロックされます。これらの設定は、プロジェクトの他の部分と一緒にコミットされます。
その他にも、いくつかの小さな変更が含まれています。Git依存関係 、引数として指定しない限り解決依存関係 --allow-gitこれにより、Gitの依存関係のnpmrcがGitの実行ファイルを上書きし、たとえ --スクリプトを無視 依存関係。httpsのtarballのようなRemote-URL依存関係も、以下を指定しない限り解決されなくなります --allow-remoteこれにより、攻撃者が依存関係を自身が管理する外部URLに向け、いつでもペイロードをすり替えることができるという経路を遮断します。
この許可リストは、scriptsフィールドに一切記載されていないコードも対象とします。パッケージがbinding.gypを同梱している場合、npmはインストール時に暗黙的にnode-gypによる再ビルドを実行するため、package.jsonに一切の記述がない依存関係であっても、そのビルドファイル1つを保持しているだけでコードを実行できてしまいます。v12では、このビルドを宣言されたスクリプトと同様に扱うため、そのパッケージが許可リストに含まれていない限り、実行はブロックされます。 当社の調査チームは最近、 この潜在的な攻撃経路がいかに奇妙かつ危険であるかを明らかにしました。
これらはすべて、npm 11.16.0 ですでに警告として実装されているため、アップグレードする前に何が動作しなくなるかを確認できます。
npmの変更によって修正されたインストール後の脆弱性
昨年秋以降、npmを襲ったワームや認証情報窃取型マルウェアのほぼすべては、実行時ではなくインストール時に動作していました。これらの手口は概ね、攻撃者がまず信頼されているパッケージを乗っ取るというものです。その方法は、通常、メンテナンス担当者のnpmアカウントをフィッシング攻撃で乗っ取ったり、公開トークンを盗み出したりするものです。その後、攻撃者はpackage.jsonにpostinstallスクリプトを追加した新バージョンを公開します。多くの場合、本来のソースコードには手を加えないため、一見して異常があるようには見えません。
誰かが「npm install」を実行すると、npmはそのスクリプトをそのユーザーとして自動的に実行します。このスクリプトはマシンのフィンガープリントを取得し、攻撃者のサーバーから実際のペイロードをダウンロードして実行した後、自身を削除します。その間、ペイロードはトークンやSSHキー、その他の機密情報をスキャンし、それらを外部へ送信します
こうした攻撃では、悪意のあるパッケージを使用したり、インポートしたりしなくても被害に遭う可能性があります。単に運悪く実行してしまうだけで npm install パッケージが感染している間は。
v12のデフォルト設定が有効な場合、インストールは、その特定のパッケージがコミットした許可リストに含まれていない限り、悪意のあるパッケージの段階で停止します。攻撃者は依然として改ざんされたバージョンを公開することはできますが、v12がインストールされているマシン上では、それらはnode_modules内に無害なファイルとして存在するだけです。
なぜこれが重要なのか
インストール後のスクリプトを悪用した攻撃の波は昨年の秋に始まり、今もなお収まる気配がありません。つい先週も、Red Hatのパッケージに対する同様の攻撃が確認されました。この手法を悪用し、当社のセキュリティ研究者を夜も眠れないほど悩ませた主な攻撃には、次のようなものがあります：
- Nx Singularity、2025年8月。盗まれたパブリッシュトークンにより、インストール時にポストインストールスクリプト「telemetry.js」が実行される悪意のあるNxバージョンが配布された。このスクリプトはGitHubトークン、npmの認証情報、SSHキー、および暗号資産ウォレットの情報を収集し、それらを公開されているGitHubリポジトリにアップロードした。収集された約2,300件の認証情報は、その後の攻撃の足掛かりとなった。
- 2025年11月、シャイ・フルード。Zapier、ENS、PostHog、Postman、AsyncAPIの各サービスで計500件近くのパッケージを襲った自己複製型ワームは、セットアップ時にBunランタイムをインストールし、TruffleHogを実行してシークレット収集し、それらをGitHubの公開リポジトリにダンプした。
- 2026年3月のaxios乗っ取り事件。乗っ取られたメンテナーアカウントから、インストール後のフックを実行し、クロスプラットフォーム型RATを仕込むことだけを目的とした依存関係が配布された。axiosのダウンロード数は週に約1億回に上る。
- 「Mini Shai-Hulud」、2026年5月。オリジナルのShai-Huludから派生したワームで、Bunランタイムをダウンロードし、認証情報窃取ツールを実行するプリインストール型フックを仕込んでいた。TanStack、UiPath、Mistral AIのパッケージ100件以上に拡散し、有効なビルドの来歴情報を伴うマルウェアを公開した初のnpmワームとなった。
これはnpmだけの問題ではありませんが、npmが最大の標的となっています。同様の仕組みは他のエコシステム、例えばPHPのComposerでも見られます。Composerでは5 月に200以上のLaravel-Langバージョンが改変され、オートローダーを介して認証情報窃取型マルウェアが自動的に実行されるようになっていました（現在、ComposerではAikidoを活用したネイティブなマルウェアフィルタリング機能が実装され、下流のユーザーを保護しています）。
これからどうすればいいでしょうか
3つの変更点はいずれも警告として表示されるだけで、すでに実装されているため、npm 11.16.0 以降にアップグレードしてください。すでに 11.15.0 以降をご利用の場合は、 --allow-git 現在入手可能です。そして――-allow-remote バージョン11.15.0以降で利用可能になったため、v12を待たずに設定を確定させることができます。スクリプトの場合は、以下を実行してください npm approve-scripts --allow-scripts-pending 何がブロックされるかを確認し、信頼できるパッケージを承認して、更新された内容をコミットする package.jsonv12がリリースされると、スキップしたものはすべて動作しなくなります。多くの正規パッケージでは、ネイティブビルドやセットアップにインストールスクリプトを使用しているため、デフォルト設定が変更されると、それらのインストールには承認が必要になります。必ず確認してください。
また、Safe Chainは以下の方法でインストールすることもできます AikidoのSafe Chainをインストールすることもできます。これは、npm、npx、yarn用の無料のセキュアラッパーであり、現在のワークフローに組み込まれ、インストール前にすべてのパッケージをマルウェアチェックします。これにより、誤ってマルウェアをインストールするのを防ぎ、新しいパッケージバージョンに対して待機期間を設けることで、多くの侵害されたパッケージがデバイスに侵入するのを防ぎます。
適切なデフォルト設定は、変更履歴を一度も開かない人々（セキュリティ研究者や必要以上に警戒心の強い人を除けば、ほぼ常に、ほぼ全員がこれに該当する）を守ります。npmがこの設定をデフォルトで安全なものにしたのは、正しい判断です。これを実現するのに1年もの間、公の場で混乱が続く必要はなかったはずですし、これで全てが解決するわけではありませんが、この変更が実施されたことを嬉しく思います。
