Больше 400 пакетов в npm оказались заражены новым червём из семейства Shai-Hulud, а часть вредоносных релизов вышла с валидными provenance-аттестациями. Для команд, которые привыкли считать зелёную галочку в реестре быстрым признаком «всё нормально», это неприятный сигнал: атака на npm показала, что подписанная цепочка сборки не спасает, если в саму цепочку уже успели залезть злоумышленники. Для разработчиков, DevOps и ИТ-руководителей смысл простой: защищать теперь нужно не только артефакт, но и репозиторий, релизный workflow и права публикации.
Как пишет The New Stack, 4 августа 2026 года атакующие получили доступ к GitHub-аккаунту мейнтейнера, связанного с библиотекой keyv и соседними пакетами из того же семейства кеширующих утилит. В первой волне исследователи зафиксировали заражённые релизы keyv 6.0.0, flat-cache 6.1.24, file-entry-cache 11.1.6, cacheable 2.5.1, cache-manager 7.2.10 и ещё нескольких пакетов, которые живут в той же экосистеме. По оценке Aikido Security, уже к 5 августа кампания ушла далеко за отметку в 400 затронутых пакетов, а совокупный месячный объём установок у связанных библиотек измерялся миллиардами. И это как раз тот случай, когда масштаб важен не ради красивой цифры: чем «скучнее» инфраструктурная библиотека, тем глубже она сидит в проде и тем дольше может жить инцидент, пока его не заметят.
Технически схема была неприятно прагматичной. В package.json добавлялся preinstall-хук, который запускал setup.mjs; тот quietly подтягивал Bun и передавал управление основному обфусцированному payload-файлу. Дальше начинался нормальный корпоративный кошмар: кража npm-токенов, GitHub-токенов, AWS-ключей, секретов Kubernetes и Vault, поиск .env-файлов, SSH-ключей и Terraform state, шифрование добычи и выгрузка в публичные GitHub-репозитории с описанием Shai-Hulud: Here We Go Again. Если на машине или в CI находились подходящие учётные данные, червь пытался идти дальше и публиковать заражённые версии других пакетов. Отдельно исследователи описали ещё один неприятный штрих: в ряде случаев вредоносный код добавлял хуки в конфиги VS Code и Claude Code, чтобы закрепиться уже не только в install-цепочке, но и в повседневной среде разработки. Иными словами, это не история про «плохую зависимость», которую можно просто убрать из lockfile. Это уже полноценный инцидент на уровне рабочей станции и пайплайна.
Самый показательный момент во всей истории связан именно с provenance-аттестациями. Они здесь не были подделаны, не были сломаны и не «обошли» криптографию. Наоборот: система честно зафиксировала, что пакет собрал и опубликовал штатный GitHub Actions workflow из официального репозитория. Проблема была выше по стеку доверия: к моменту запуска workflow вредоносный код уже лежал в основной ветке. Поэтому зелёная галочка рядом с релизом на практике стала не защитой, а маскировкой. Сама технология provenance не провалилась; она выполнила свою работу и подтвердила происхождение артефакта. Просто этот инцидент наглядно показал неприятную границу её полезности: provenance отвечает на вопрос «откуда приехал пакет», но не отвечает на вопрос «безопасно ли то, что в него уже закоммитили». Для инженеров это дорогой, но очень полезный урок. Если доверенный pipeline собирает вредоносный код, на выходе получится безупречно подписанный вредоносный код.
Контекст делает историю ещё неприятнее. В мае 2026 года злоумышленники, связывавшие себя с TeamPCP, выложили исходники Shai-Hulud в открытый доступ и фактически открыли дорогу copycat-кампаниям. После этого похожие волны уже били по экосистемам TanStack, Mistral и другим открытым проектам, а акцент всё чаще смещался с поддельных пакетов на компрометацию легитимных репозиториев и CI/CD. Для рынка это плохая новость по очень приземлённой причине: защититься от фейкового пакета сравнительно просто, а вот отличить нормальный релиз популярной библиотеки от релиза, выпущенного тем же самым официальным workflow после захвата аккаунта или ветки, заметно сложнее. Старый рефлекс «пакет официальный, значит можно ставить» начинает работать против самих команд. Атака на npm в таком сценарии бьёт уже не по одной экосистеме JavaScript, а по базовому операционному доверию к автоматизированной публикации.
Для разработчиков и ИТ-бизнеса вывод здесь довольно жёсткий. Если затронутый пакет хотя бы раз ставился на рабочую станцию, build-агент или self-hosted runner, простого удаления зависимости уже недостаточно. Нужно перевыпускать npm-, GitHub- и облачные токены, пересобирать CI-раннеры, проверять новые workflow и подозрительные коммиты в связанных репозиториях, смотреть, не появились ли в проекте неожиданные install-скрипты, а также жёстче делить права на merge и release. Для мейнтейнеров и компаний с собственными npm-пакетами это ещё и напоминание, что trusted publishing без защиты аккаунтов, обязательной MFA, passkeys или hardware keys и минимальных permissions у GitHub Actions даёт только половину картины. Вторая половина — это контроль над тем, кто вообще может положить код в main и кто может запустить публикацию. И да, короткая пауза между публикацией свежей версии и её автоматическим подъёмом в production внезапно снова выглядит хорошей инженерной привычкой, а не бюрократией.
Главный вопрос после этой истории звучит довольно неприятно: что считать доверенным артефактом, если доверенный pipeline способен аккуратно и криптографически безупречно доставить вам вредоносный код? Похоже, следующий этап защиты supply chain будет строиться уже не вокруг одних только подписей, а вокруг постоянной проверки самих изменений, прав доступа и поведения релизов ещё до того, как зелёная галочка успеет кого-то успокоить.