npm 12 отключил install-скрипты пакетов: крупнейшая перестройка защиты реестра

Что изменилось в npm 12

В начале июля 2026 вышла npm 12 — новая мажорная версия менеджера пакетов, который поставляется вместе с Node.js. Разработчики называют её самым крупным изменением модели безопасности за 16-летнюю историю npm. Суть проста: несколько небезопасных по своей природе операций, которые раньше выполнялись автоматически и незаметно, теперь по умолчанию отключены и требуют явного разрешения.

По умолчанию npm 12 больше не делает следующего:

• Не запускает install-скрипты устанавливаемых зависимостей — хуки preinstall, install и postinstall из чужих пакетов не выполняются сами по себе.
• Не ставит git-зависимости напрямую из репозиториев — для этого нужен явный флаг (--allow-git).
• Не тянет пакеты по произвольным URL — установка из удалённых tarball-архивов вне реестра также требует явного разрешения (--allow-remote).
• Не выполняет неявную сборку нативных модулей через node-gyp, которую запускал файл binding.gyp.

Предупреждения об этих изменениях появились заранее — начиная с версии npm 11.16.0, чтобы у команд было время подготовиться до того, как 12-я ветка станет установкой по умолчанию.

Что такое install-скрипты и почему они опасны

Install-скрипт — это команда, которую пакет описывает в своём файле package.json и которую npm выполняет в момент установки. Классический пример — postinstall: он задуман для полезных задач вроде сборки нативного кода или загрузки бинарников под конкретную платформу. Проблема в том, что скрипт запускается автоматически и с правами текущего пользователя, стоит лишь добавить пакет в зависимости.

Для атакующего это идеальная точка входа. Если злоумышленник опубликует вредоносную версию популярной библиотеки или её транзитивной зависимости, то postinstall отработает на машине разработчика или на раннере CI ещё до того, как хоть одна строка кода приложения будет запущена. Такой скрипт успевает собрать переменные окружения, токены, SSH-ключи и содержимое кошельков и отправить их на сервер злоумышленника.

Почему npm пошёл на такой шаг

Решение — прямая реакция на серию громких атак на цепочку поставок за последний год, где вектором почти всегда был именно install-скрипт:

• Nx / «s1ngularity» (август 2025). Через вредоносный postinstall-скрипт кампания собрала порядка 2300 учётных данных и секретов с машин разработчиков.
• Червь Shai-Hulud (ноябрь 2025). Самораспространяющийся вредонос затронул более 500 пакетов, используя хуки установки для заражения соседних проектов.
• Компрометация axios (март 2026). В одну из популярнейших HTTP-библиотек через postinstall встроили троян удалённого доступа; атаку связывают со спонсируемой государством группировкой.
• «Mini Shai-Hulud» (май 2026). Волна preinstall-червя прокатилась по пакетам известных проектов, снова эксплуатируя автозапуск скриптов.

Общий знаменатель у всех инцидентов один: пользователю достаточно было выполнить обычную установку зависимостей, чтобы чужой код тихо запустился в его окружении. Отключив автозапуск, npm убирает саму возможность такого «тихого старта» по умолчанию — вредоносный пакет теперь придётся ещё и явно допустить до выполнения.

Кого это касается и что сломается

Изменение затрагивает практически любого, кто работает с Node.js. Но у части легитимных пакетов install-скрипты — не прихоть, а необходимость: через них собираются нативные модули (например, обёртки над C/C++ библиотеками) и докачиваются платформенные бинарники. После перехода на npm 12 такие пакеты без разрешения соберутся неполностью.

Самое коварное — как это проявляется в автоматических сборках. Конвейеры CI/CD, где выполняется npm install без подготовки, рискуют получить не явную ошибку, а «тихий» сбой: установка завершается с кодом 0, будто всё в порядке, но нужный скрипт не отработал, и приложение падает уже дальше по пайплайну — на сборке или в рантайме. Отследить такой сбой сложнее, чем честное падение установки.

Что делать разработчику

1. Проверьте, какие из ваших зависимостей реально используют install-скрипты, и составьте их список — npm 12 предоставляет для этого команды управления разрешениями (например, предпросмотр того, что будет заблокировано).
2. Явно разрешите (allowlist) только те пакеты, которым скрипты действительно нужны, — командой npm approve-scripts, и зафиксируйте изменения в package.json и lock-файле.
3. В пайплайнах CI/CD заранее протестируйте сборку на npm 12, чтобы не поймать «тихий» сбой с кодом 0 уже в проде.
4. Если вам нужны git- или remote-зависимости, добавьте соответствующие флаги (--allow-git, --allow-remote) осознанно, а не «на всякий случай».
5. Регулярно прогоняйте npm audit и обновляйте зависимости — отключённые скрипты снижают риск, но не отменяют гигиену цепочки поставок.

Тема разбора и запуска кода из недоверенных источников выходит далеко за пределы одного менеджера пакетов. О том, как безопасно принимать, проверять и хранить файлы, — в разделе безопасность файлов. Близкие сюжеты последних недель: gzip-бомба в библиотеке node-tar и вредоносные ZIP-архивы под видом проектов с GitHub — все они об одном: код и файлы из чужих рук нужно запускать с оглядкой.

Источники

• Обсуждение подготовки к npm v12 в GitHub Community (install-скрипты и non-registry источники становятся opt-in) — github.com/orgs/community/discussions
• Aikido Security: разбор блокировки postinstall в npm v12 — aikido.dev
• Tech Times: «npm v12 Ships This Month, Blocking Install Scripts» — techtimes.com

Данные приведены на 2 августа 2026 по материалам GitHub Community, Aikido Security и Tech Times. Названия команд, версий и хронология атак указаны по первоисточникам.