npm v12でインストールスクリプトが既定で無効に：サプライチェーン攻撃への備えと移行準備

2026年6月9日、GitHubはnpm v12で予定している破壊的変更を公表しました。依存パッケージのインストールスクリプトが既定で実行されなくなり、GitやリモートURLからの依存も既定でブロックされます。6月にもnpmを狙ったサプライチェーン攻撃が起きており、その背景と、今のうちに進めておきたい準備を整理します。

何が発表されたのか

GitHub Changelogで告知されたv12の変更は、どれも npm install の自動的な挙動を「明示的に許可したときだけ動く」方式に切り替えるものです。

対象	v12での既定	先行して使えるバージョン
依存パッケージのインストールスクリプト（preinstall / install / postinstall）	プロジェクトで許可したものだけ実行	npm 11.16.0以降で警告を表示
Git依存（直接・間接とも）	--allow-git が none	npm 11.10.0以降
リモートURL依存（httpsのtarballなど）	--allow-remote が none	npm 11.15.0以降

インストールスクリプトの対象には、binding.gyp を持つパッケージで暗黙に実行される node-gyp rebuild も含まれます。つまり、明示的なインストールスクリプトがなくても、ネイティブモジュールのビルドは止まります。Git・file・link依存の prepare スクリプトも同様です。一方、--allow-file と --allow-directory の既定は変わりません。

許可リストは package.json の allowScripts に保存され、新しい npm approve-scripts と npm deny-scripts コマンドで管理します。v12のリリースは2026年7月の見込みとされています。Node.jsに同梱されるnpmのバージョンについては、Node 24と26へのバックポートが検討されていますが、最終的な判断はNode.jsのリリースチームが行うとされています。

なぜ重要なのか

これまで npm install は、依存パッケージに含まれるスクリプトを何も聞かずに実行してきました。便利な反面、乗っ取られたパッケージが1つ紛れ込むだけで、開発者のPCやCI環境で任意のコードが動く状態でした。攻撃者にとっては最も手軽な入口です。

実際、6月17日には、AIエージェント開発フレームワークMastraの @mastra スコープを中心に144のパッケージが改ざんされたと報告されています。Orca Securityの分析によると、公開権限が取り消されていなかった元コントリビューターのアカウントが乗っ取られ、各パッケージの依存に easy-day-js という偽のパッケージが追加されました。これは日付ライブラリdayjsに似せた名前で、postinstall で不正なスクリプトを実行し、ブラウザのデータや暗号資産ウォレットの情報などを狙うものでした。利用者がやったことは npm install だけです。

v12の既定であれば、新しく紛れ込んだパッケージのスクリプトは許可リストにないため、少なくとも自動では実行されなかったはずだと私は理解しています。もちろん、これだけで全ての攻撃を防げるわけではありません。ただ、「インストールしただけで感染する」経路を既定で塞ぐ効果は大きいと考えています。

Git依存の既定ブロックにも理由があります。GitHubは、Git依存に含まれる .npmrc によってGitの実行ファイルを差し替えられ、--ignore-scripts を付けていてもコードが実行される経路があったと説明しています。

実務での影響・対応

開発者がやっておくこと

GitHubとnpmチームの案内をもとに、移行の手順をまとめます。

1. npmを11.16.0以降に上げて、普段どおりインストールする。表示される警告から、v12でブロックされるものを把握できます。
2. 許可待ちのパッケージを一覧にする。npm approve-scripts --allow-scripts-pending は読み取り専用で、何も変更しません。
3. 信頼できるものを許可し、不要なものを拒否する。許可は既定でインストール済みのバージョンに固定されます。
4. 更新された package.json をコミットする。チーム全員とCIで同じ許可リストが使われるようになります。

# v12でブロックされるスクリプトを確認する（読み取り専用）
npm approve-scripts --allow-scripts-pending

# 信頼できるパッケージのスクリプトを許可する
npm approve-scripts <パッケージ名>

# 不要なスクリプトを明示的に拒否する
npm deny-scripts <パッケージ名>

CIについては、注意点がいくつかあります。まず、.npmrc などに ignore-scripts=true が残っていると、すべてのスクリプトが止まり許可リストより優先されます。許可リストを整えたら整理しておきましょう。次に、GitHub Communityの移行スレッドでは、メンテナーがローカルでは厳格モードを切り、CIでは strict-allow-scripts を有効にして未確認のスクリプトでビルドを失敗させる運用を勧めています。また、Git依存を使っている場合は allow-git の設定が必要です。値は all / none / root のいずれかで、true は無効な値として扱われる点に注意してください。

なお、全ての制限を外す --dangerously-allow-all-scripts や、将来のバージョンまで許可する --no-allow-scripts-pin も用意されています。私は、移行で困ったときの一時しのぎ以上には使わない方がよいと考えています。

事業者の方へ

自社のWebサイトや業務システムを外部に委託している場合、v12への切り替えでビルドが止まる可能性があります。特に、ネイティブモジュールを使っているプロジェクトや、Git上のリポジトリを直接依存にしているプロジェクトは影響を受けやすいはずです。委託先に「npm v12への準備はできているか」「許可リストは誰がどう確認しているか」を一度確認しておくと安心です。

AIエージェントに任せる場合の注意

最近はAIのコーディングエージェントが npm install を実行する場面も増えました。npmチームの議論でも、許可リストはコード実行の許可そのものであり、自動化ツールに人の確認なしで変更させるべきではないと注意されています。許可リストの変更は人がレビューする、というルールを、エージェントへの指示書（AGENTS.md など）やレビュー手順に明記しておくことをおすすめします。

まとめ

npm v12では、依存パッケージのインストールスクリプト、Git依存、リモートURL依存が、いずれも明示的に許可したときだけ動く方式に変わります。6月のMastraの事例のように、インストールしただけで感染する攻撃が続いているなかで、この既定の見直しは妥当な判断だと考えています。

リリースは7月の見込みです。npm 11.16.0以降なら今すぐ警告を確認できるので、正式リリースを待たずに許可リストの整備とCIの見直しを進めておくのが、いちばん手戻りの少ない進め方です。

参考リンク

• Upcoming breaking changes for npm v12（GitHub Changelog）
• Preparing for npm v12: install scripts and non-registry sources become opt-in（GitHub Community Discussion）
• Mastra npm supply chain attack（Orca Security）