PackageGate - это шесть zero-day уязвимостей в npm, pnpm, vlt и Bun, раскрытых в январе 2026. Главная проблема для npm: обход флага --ignore-scripts через git-зависимости с инъекцией .npmrc. Если вы полагаетесь на этот флаг в CI/CD, ваша защита пробита - атакующий запускает RCE без предупреждений.

Это реальная угроза для npm-проектов. Злоумышленник пихает вредоносный .npmrc в git-репо, и npm выполняет его скрипты вместо git. npm отказался патчить, сказав, что сами ветируйте пакеты. Пора разбирать, как защитить стек и не попасть на удой.

Как работает обход --ignore-scripts в npm

npm клонирует git-зависимость и парсит .npmrc внутри неё. Атакующий пишет в .npmrc строку вроде git=./malicious-script.sh и добавляет вложенную git-зависимость. При обработке nested dep npm запускает фейковый git - полный RCE, даже с --ignore-scripts. Это не теория: есть доказательства PoC с reverse shell в wild.

Флаг --ignore-scripts блокирует lifecycle-скрипты вроде postinstall, но git-процесс вне его зоны. npm считает это expected behavior и не фиксит. В итоге ваша pipeline думает, что скрипты заблокированы, а на деле выполняется произвольный код с правами юзера.

Вот типичный вектор атаки:

• Зависимость: “evil-pkg”: “git+https://github.com/attacker/malicious.git”
• В malicious.git/.npmrc: git=./pwn.sh
• pwn.sh содержит reverse shell или копирует секреты

Ключевой момент: nested git deps обрабатываются рекурсивно, каждый раз читая локальный .npmrc.

Нюанс: работает только если git deps разрешены в проекте. Но кто их запрещает?

Git-зависимости: красный флаг для безопасности

Git deps - это прямой импорт из репозитория, без registry. Удобно для private пакетов или bleeding-edge версий, но сканеры вроде Snyk их не видят. Атакующий форкает популярный репозиторий, пихает .npmrc и подменяет dep в pull request’е. CI/CD тянет git и выполняет код.

В PackageGate это основной вектор. npm не проверяет .npmrc на безопасность при git-клоне. Другие менеджеры (pnpm, Bun) пофиксили свои дыры, но npm стоит на позиции “vet yourselves”. В реальных проектах git deps часто в lockfile, и их сложно вырезать.

Проверьте свой package.json и package-lock.json:

• grep -r "git+" package-lock.json
• Сканируйте на подозрительные .npmrc в deps
• Блокируйте git deps в .npmrc: git=never

Опасные паттерны:

• git+https://github.com/user/private-pkg#branch
• Зависимости от форков без audit
• CI без git credential isolation

Важно: lockfile не спасает - attacker меняет git ref после фикса.

Защита npm-проекта: шаг за шагом

Начните с аудита: отключите git deps полностью или мигрируйте на tarball. В .npmrc добавьте git=never - npm будет падать на git-зависимостях. Для CI используйте audit + sigstore для верификации артефактов. Переход на pnpm: он пофиксил PackageGate и имеет onlyBuiltDependencies по дефолту.

Не полагайтесь только на --ignore-scripts - комбинируйте меры. Просканируйте текущие deps на уязвимости, настройте pre-commit хуки для проверки .npmrc. В больших командах внедрите policy: no git deps без review. Тестируйте: создайте PoC локально и убедитесь, что ваша защита держит.

Конкретные шаги:

1. npm config set git never - глобальный бан git deps
2. Замените git deps на версии из registry: “pkg”: “1.0.0”
3. В package.json: скрипт “audit”: “npm audit && npm ls --all”
4. CI: npm ci --ignore-scripts --audit-level=high
5. Мониторинг: GitHub Dependabot + Socket.dev для git scans

Киллер-фича pnpm: onlyBuiltDependencies - скрипты только для trusted build deps.

Подводный камень: после миграции пересоберите lockfile.

Фикс, который не случился: что дальше с npm

npm закрыл баг как “wontfix”, поставив ответственность на юзеров. Это two-tier security: enterprise версии фиксят приватно, open-source остаётся с дырой. В 2026 PackageGate показал - JS экосистема зрелая, но менеджеры пакетов отстают.

Остаётся думать о hybrid подходе: npm для legacy + pnpm для новых проектов. Или полный переход на Deno/Bun с встроенной безопасностью. Git deps останутся болью, пока registry не заблокирует их по дефолту. Тестируйте свою защиту на PoC из Koi Security - лучше узнать дыру в lab, чем в проде.