Цепочка компрометаций TanStack, Nx Console и GitHub (май 2026): что проверить разработчикам

Затронуты 42 пакета Router/Start, 84 версии, включая @tanstack/react-router, @tanstack/react-start, @tanstack/router-core и @tanstack/history (полный список — в бюллетене GitHub GHSA-g7cv-rxg3-hmpx). TanStack говорит, что Query, Table, Form, Virtual и другие её пакеты затронуты не были. Проверяйте не только текущее содержимое lock-файла, но и историю его изменений около 11 мая 2026 года. Вредоносные версии удалили из npm за несколько часов, поэтому установка в это окно может не отражаться в сегодняшнем lock-файле. В CI ищите задания, которые выполняли установку после 19:20 UTC 11 мая.

В разборе Nx показано, как проверить установленную версию командой code --list-extensions --show-versions (ID расширения содержит angular-console). Затронута только v18.95.0, и она была доступна 18 мая с 12:30 до 13:09 UTC. Nx просит всех, у кого в это окно была Nx Console с включённым автообновлением, считать машину скомпрометированной — какая бы из цифр установок ни оказалась верной. В разборе также перечислены файлы и процессы, которые нужно искать (индикаторы компрометации); если вы затронуты, пройдите по этому списку.

TanStack и Nx перечисляют одни и те же цели: токены GitHub, токены npm, ключи SSH, учётные данные облаков (AWS, GCP, Azure), Kubernetes, токены Vault и содержимое любых файлов .env. Nx добавляет учётные данные, которые инструменты на машине могли выпустить в это окно (временные учётные данные облаков, токены GitHub CLI и т. д.), и рекомендует после смены рассмотреть полную переустановку машины. О порядке отзыва и о том, что делать с закрепившимся вредоносным ПО, см. раздел «если есть подозрение на заражение» в статье защита от червей в цепочке поставок npm.

По словам TanStack, код искал другие пакеты, которые поддерживает жертва, и пытался переопубликовать их с тем же внедрением. Если вы публикуете в npm, проверьте историю версий своих пакетов на версии, которые вы не публиковали, начиная с 11 мая.

По словам Nx, украденным учётным данным был токен GitHub CLI. В той среде он хранился в файле на диске и был доступен для чтения любому процессу, запущенному от имени пользователя, и был использован против API GitHub в течение 74 секунд. Выполните gh auth status, чтобы увидеть, где хранится ваш; если он лежит в обычном файле, подумайте о переносе в связку ключей ОС или в интеграцию с менеджером паролей, которая подставляет учётные данные только во время запуска. После инцидента политика Nx запрещает прямое использование GitHub CLI на машинах разработчиков. О сокращении срока жизни и прав токенов см. защиту от червей в цепочке поставок npm.

По словам Nx, в проекте скомпрометированного участника в .npmrc было указано minimum-release-age=10080 (7 дней), но проект закреплял pnpm 10.14, которая не поддерживает эту настройку и молча её игнорировала. Поддержка появилась в pnpm 10.16. На момент установки вредоносной версии было всего 77 минут, так что работающая настройка её бы заблокировала. Проверьте версию, закреплённую в поле packageManager файла package.json, и пусть CI проверяет, что она достаточно новая. Аналогичная настройка для npm описана в статье защита от червей в цепочке поставок npm.

26 мая GitHub объявил, что меняет ключи, включая ключ, которым подписываются пакеты обновлений GitHub Enterprise Server. Администраторы должны сменить открытые ключи GPG в своём экземпляре; иначе будущие обновления завершатся ошибкой о том, что файл не является корректным пакетом GHES. Инструкции и дайджест SHA256 вспомогательного скрипта приведены в публикации GitHub. GitHub также просит скачивать обновления GHES только из официального источника и готовиться в ближайшие месяцы устанавливать обновления безопасности чаще. Клиентам GitHub Enterprise Cloud ничего делать не нужно.

По словам TanStack, workflow для проверки размера бандла запускался на pull_request_target и внутри него получал и собирал код из pull request форка. pull_request_target выполняется с правами основного репозитория, и TanStack отмечает, что проверка одобрения для новых участников не применяется к этому триггеру. Оставьте его для задач, которые никогда не запускают чужой код, — например, расстановки меток и комментариев. После инцидента TanStack убрала из своего CI все использования pull_request_target.

По словам TanStack, кэш GitHub Actions общий на уровне репозитория: запуски pull_request_target и push в main используют одну и ту же область. Сохранение в кэш также не блокируется, если задать permissions: workflow только на чтение. В результате workflow релиза восстановил кэш, записанный заданием, которое выполняло чужой код. После инцидента TanStack отключила кэш пакетов в пайплайне релиза и очистила все кэши. Не восстанавливать кэш в workflow, которые публикуют, — самая простая граница.

У workflow релиза TanStack было id-token: write для доверенной публикации в npm (OIDC). Согласно разбору, вредоносная публикация произошла не на шаге публикации, определённом в workflow: код, выполнявшийся на другом этапе того же запуска, извлёк токен и опубликовал пакеты напрямую. Собственный вывод TanStack: у привязки доверенного издателя нет проверки каждой публикации. Выделите публикацию в отдельное задание, отдельно от сборки и тестов, дайте право только ему и поставьте его за окружение GitHub с обязательными рецензентами. После инцидента Nx сделала обязательным для публикации одобрение человеком, отличным от того, кто запустил процесс.

После инцидента и TanStack, и Nx закрепили все ссылки на actions по SHA коммита вместо тега или ветки. TanStack называет подвижные ссылки «постоянным риском для цепочки поставок, не зависящим от этого инцидента».

Nx обнаружила подменённый релиз благодаря обычному письму, которое магазин расширений отправляет при каждой загрузке. Мейнтейнер, не ожидавший релиза, понял, что это аномалия, и снял публикацию примерно за 11 минут. Во втором канале распространения такого уведомления не было, и удаление там заняло около 36 минут. Тем временем действия с украденным токеном, например удаление запусков workflow, неделю лежали в журнале аудита незамеченными. Проверьте, что уведомления о публикации доходят до кого-то в команде и что кто-то следит за удалением запусков workflow в журнале аудита.