Mini Shai-Hulud ударил по Mistral и TanStack: доверенные сборки больше не гарантируют безопасность

В open-source экосистеме произошёл новый инцидент цепочки поставки: вредоносные версии попали в десятки популярных пакетов TanStack, а затем волна затронула SDK Mistral AI, OpenSearch, UiPath и другие проекты. Исследователи связывают атаку с кампанией Mini Shai-Hulud — самораспространяющимся вредоносным кодом, который крадёт учётные данные из окружения разработчиков и CI, а потом пытается заражать новые пакеты от имени уже скомпрометированного владельца.

На первый взгляд это очередная история про «не ставьте свежие зависимости вслепую». Но здесь важнее другое: часть вредоносных публикаций выглядела формально доверенной. Они прошли через официальный механизм OIDC trusted publishing, а в некоторых разборках подчёркивается, что пакеты могли иметь валидные provenance-аттестации. То есть тревожный урок не в том, что кто-то украл пароль от npm, а в том, что атакующий научился использовать доверие к CI как транспорт для заражения.

Что произошло

TanStack в собственном postmortem пишет, что 11 мая 2026 года между 19:20 и 19:26 UTC злоумышленник опубликовал 84 вредоносные версии в 42 пакетах @tanstack/*. Среди затронутых семейств были router-пакеты, включая широко используемый @tanstack/react-router. По данным Socket, некоторые из них имеют миллионы загрузок в неделю, поэтому инцидент быстро стал не локальной проблемой одного проекта, а угрозой для большого числа приложений и CI-систем.

Позже исследователи обнаружили похожую инфекцию в других пакетах, включая @mistralai/mistralai и связанные SDK. Techmeme вынес историю в топ с формулировкой, что были скомпрометированы многие npm-пакеты для Mistral, UiPath и TanStack, а Microsoft расследует компрометацию PyPI-пакета Mistral AI версии 2.4.6. На момент публикации речь идёт о быстро развивающемся инциденте, поэтому точный список затронутых пакетов нужно проверять по advisory и базам безопасности, а не по одному скриншоту из соцсетей.

Команда TanStack заявляет, что все известные вредоносные версии были deprecated, npm security привлечена к удалению tarball-файлов, кэши GitHub Actions очищены, а workflow усилены. Но если заражённый пакет уже устанавливался на машине разработчика или в CI, простой npm update проблему не закрывает: такой хост нужно считать потенциально скомпрометированным.

Как сработала атака

Схема неприятна именно потому, что она бьёт по привычным «правильным» практикам. По версии TanStack, злоумышленник использовал цепочку из трёх элементов: опасный паттерн pull_request_target, отравление кэша GitHub Actions и извлечение OIDC-токена из памяти runner-процесса во время легитимного workflow.

Упрощённо это выглядит так. В репозитории появляется pull request из форка. Часть workflow запускается в контексте базового репозитория, но при этом выполняет код из внешнего PR. Этот код отравляет dependency cache так, чтобы при следующем релизном запуске официальный CI восстановил уже заражённое содержимое. Затем вредоносный код в ходе легитимного workflow получает доступ к короткоживущему OIDC-токену и публикует пакеты напрямую в npm registry.

Важная деталь: по словам TanStack, npm-токены не были украдены, а сам шаг публикации в workflow даже не обязан был успешно завершиться. Публикация произошла потому, что инфраструктура доверенного издателя приняла запрос, пришедший из допустимого CI-контекста. Для внешнего наблюдателя это уже не выглядит как грубый взлом пароля; это похоже на легитимную автоматизацию, которую заставили сделать чужую работу.

Почему это касается не только разработчиков

Современный софт собирается из тысяч зависимостей. Даже если пользователь никогда не слышал о TanStack или Mistral SDK, он может пользоваться продуктом, который тянет такие библиотеки транзитивно. Поэтому атаки на цепочку поставки — это не внутренняя драма GitHub-команд, а вопрос устойчивости всего цифрового слоя: банковских сервисов, SaaS-приложений, корпоративных панелей, медицинских систем и обычных сайтов.

AI-эпоха усиливает проблему. Разработчики всё чаще подключают SDK моделей, агентные фреймворки, плагины для автоматизации, библиотеки для векторных баз и инструменты генерации кода. Многие из них ставятся быстро, обновляются часто и живут внутри CI, где лежат ключи к облакам, репозиториям, контейнерным registry и production-инфраструктуре. Вредоносная зависимость в таком месте получает не просто ноутбук программиста, а почти карту доступа к фабрике ПО.

Именно поэтому в истории с Mini Shai-Hulud важен не бренд Mistral или TanStack сам по себе, а класс уязвимости. Если атакующий умеет превращать доверенную сборочную систему в издателя вредоносного пакета, рынок должен пересмотреть, что именно означает «официальная» поставка.

Provenance оказалась не серебряной пулей

За последние годы индустрия продвигала SLSA, Sigstore, OIDC trusted publishing и provenance как ответ на хаос с токенами и поддельными пакетами. Это действительно полезные механизмы: они уменьшают риск украденных долгоживущих секретов и дают возможность проверить, откуда пришёл артефакт. Но этот инцидент показывает границу обещания.

Provenance может подтвердить, что пакет был собран и опубликован определённым workflow в определённом репозитории. Она не доказывает, что в момент сборки workflow не восстановил отравленный кэш, не выполнил чужой код и не дал злоумышленнику временный токен. Другими словами, подпись отвечает на вопрос «какая машина это выпустила», но не всегда отвечает на вопрос «была ли сама машина в безопасности».

Это болезненный, но полезный урок. Доверенная сборка — не финальная печать качества, а один слой защиты. Если вокруг неё остаются опасные PR-workflow, общие кэши между недоверенным и релизным кодом, широкие права runner-ов и автоматические lifecycle-скрипты пакетов, атакующий всё равно найдёт щель.

Что делать компаниям прямо сейчас

Первый практический шаг — проверить, устанавливались ли затронутые версии 11 мая и позже. Для TanStack команда указывает конкретный advisory и tracking issue; Socket, Snyk, StepSecurity и другие компании публикуют индикаторы компрометации и списки пакетов. Если такой пакет был установлен на developer machine или в CI, безопасная позиция жёсткая: считать окружение скомпрометированным и ротировать доступные секреты.

Второй шаг — пересмотреть CI. Workflow, которые используют pull_request_target и одновременно выполняют код из форка, должны попасть в красную зону. Кэши между недоверенными PR и release-процессами нельзя считать нейтральным ускорителем сборки. OIDC-права должны быть минимальными и выдаваться только тем job, где публикация действительно нужна, а не всему pipeline «на всякий случай».

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

Главный вывод

Mini Shai-Hulud — не просто ещё один supply-chain инцидент. Это демонстрация новой планки атак: вредоносный пакет может прийти не из тёмного угла npm, а через официальную инфраструктуру проекта, с короткоживущими токенами, автоматическими сборками и внешне приличной историей происхождения.

Для обычного читателя смысл простой: безопасность цифрового мира всё меньше похожа на замок на двери и всё больше — на контроль всей фабрики, где эту дверь производят. Если фабрика автоматизирована, подключена к облакам и ускорена ИИ-инструментами, то одна ошибка в доверии к workflow может стать проблемой для тысяч компаний.

Для разработчиков и CTO вывод ещё прямее: пора относиться к CI/CD как к критической инфраструктуре, а не как к скучной папке .github/workflows. В эпоху агентного кода и быстрых зависимостей вопрос уже не «можем ли мы подписать пакет», а «можем ли мы доказать, что весь путь до подписи не был заражён».