2026 年 7 月公開予定の npm v12 から、依存パッケージの postinstall / preinstall / install スクリプトが **標準で実行されなくなる**。これまで npm install しただけで任意コードが走るのが当たり前だった JavaScript エコシステムが、ようやくデフォルトで黙る側に振れる。
「install しただけで詰む」が当たり前だった世界 #
install スクリプトは元々ネイティブ拡張のビルドや CLI のリンク張りといった正当な用途のために存在してきた。しかし攻撃者にとっては「npm install 一発で被害者の環境でコードを実行できる」最高の起爆点でもあった。
過去数年で表沙汰になった主要なサプライチェーン事件 ― ua-parser-js 乗っ取り、段階的 takeover、直近の Red Hat 配下を経由した worm 系 ― は ほとんどすべてが postinstall を最終ペイロードのトリガにしていた。「依存を一つ追加した瞬間に CI ランナーとローカル PC で同じコードが走る」という構造そのものが脆弱性だった。
反対の声を押し切った判断 #
| 立場 | 主張 |
|---|---|
| 反対 (一部メンテナ) | ネイティブビルドが壊れる、移行コストが大きい |
| 賛成 (セキュリティ側) | postinstall は攻撃面として大きすぎ、デフォルトオフが唯一の構造的解 |
| npm 公式 | 明示的に許可した依存だけスクリプトを走らせる opt-in 方式 |
pnpm は既に同等の挙動を採用していたが、エコシステム最大手の npm が同じ路線に乗るインパクトは段違いだ。package-lock.json を共有している全プロジェクトに、強制的に新しい契約が降ってくる。
ハッカー視点での意味 #
postinstall のドアが閉じても、攻撃者は ライブラリ側のエントリポイント ― require / import された時点で動く副作用コード ― へ重心を移すだけだ。すでに colors.js のように import 直後にプロセスを汚染する事例は出ている。npm v12 以降の防御は、
- ロックファイルの署名検証 (Sigstore 系統合)
- ランタイム側での権限分離 (Node の
--permission、Deno モデル) - 依存追加時の SBOM 自動レビュー
を 同時に積む 必要がある。「postinstall が消えたから安全」と思い込んだ瞬間に次のキャンペーンが刺さる、というのがエコシステム移行期の典型的なリスクだ。
COMMENTS 0
まだコメントはありません。最初のコメントを投稿しよう。