Технический контекст
Я полез в постмортем TanStack сразу после публикации, потому что это не просто очередной npm-инцидент. Тут неприятнее: вредоносные пакеты вышли через официальный release pipeline, а значит любая команда, которая строит AI integration или обычный прод на доверии к provenance, должна напрячься.
Окно атаки было коротким: 11 мая 2026 с 19:20 до 19:26 UTC. За эти шесть минут злоумышленник опубликовал 84 вредоносные версии в 42 пакетах @tanstack/*.
Пароли мейнтейнеров не украли. npm publish workflow напрямую тоже не ломали. Атакующий подменил входы в CI так, что пайплайн TanStack сам выпустил зараженные сборки своим доверенным OIDC-identity.
И вот здесь я реально завис на минуту: релизы имели валидные provenance attestation. То есть привычная логика “подпись есть, trusted publishing есть, значит все чисто” в этом кейсе не сработала.
Цепочка атаки выглядела очень по-современному. Сначала использовали опасный паттерн pull_request_target, тот самый Pwn Request. Потом отравили GitHub Actions cache на границе fork и base repository. А уже в release job вытащили короткоживущий OIDC token прямо из памяти runner-процесса.
По сути, CI украл токен сам у себя в момент публикации. Это уже не история про “не храните секреты в репо”. Это история про то, что cache, артефакты и trust boundary в GitHub Actions нужно считать враждебными по умолчанию.
Если вы тянули @tanstack/* в эти даты, я бы не ограничивался обновлением версии. Я бы пересобрал проект с чистым lockfile, снес cache, проверил CI-логи на странные сетевые запросы и ротировал секреты, если зараженный пакет хоть раз исполнялся в pipeline.
Что это меняет для бизнеса и автоматизации
Проигрывают команды, у которых релизы держатся на “ну у нас же trusted publishing”. Выигрывают те, кто разделяет untrusted PR, build и publish по разным зонам доверия.
Второй вывод еще практичнее: supply chain security больше нельзя вести вручную по чеклисту раз в квартал. Нужны нормальные правила, сканирование lockfile, контроль cache, реакция на инциденты и автоматизация отката.
Мы в Nahornyi AI Lab как раз закрываем такие места на практике: проектируем AI solutions architecture вокруг DevSecOps-процессов, чтобы команда не ловила компрометацию постфактум по логам. Если у вас CI/CD уже разросся и никто не может быстро доказать, что именно безопасно, давайте разберем это и соберем AI automation под ваш реальный workflow, а не для красивой схемы в Notion.