Mini Shai-Hulud: атака на TanStack, Mistral и UiPath через npm и PyPI

Mini Shai-Hulud задел TanStack, Mistral AI SDK и UiPath через npm и PyPI. Разбираем подтверждённые факты, спорные цифры и практические шаги для команд.

Mini Shai-Hulud: постмортем TanStack о supply-chain атаке через npm

По состоянию на 12 мая 2026 года история с Mini Shai-Hulud уже выросла в новую волну самораспространяющейся supply-chain атаки. Она одновременно задела frontend-инфраструктуру TanStack, AI SDK у Mistral и, по данным threat-intel-исследователей, пакеты в scope @uipath.

Самое важное здесь — не потерять границу между подтверждённым и предполагаемым. У TanStack есть подробный официальный постмортем от 11 мая 2026 года. У Mistral есть собственный security advisory от 12 мая 2026 года. По UiPath на момент подготовки материала публичного корпоративного advisory я не нашёл, поэтому всё, что касается масштаба внутри @uipath, нужно атрибутировать сторонним security-исследователям, а не самой компании.

Именно поэтому этот кейс важен для аудитории Toolarium. Он показывает, что атака на пакетные экосистемы теперь проходит по связке GitHub Actions -> cache poisoning -> OIDC trusted publishing -> developer workstation, а закрепление идёт не только через зависимости, но и через локальные AI-конфиги вроде .claude/settings.json и IDE-задачи в .vscode/tasks.json.

Что официально подтвердил TanStack

В постмортеме TanStack описан не абстрактный «взлом npm», а очень конкретная цепочка событий. 11 мая 2026 года атакующий открыл вредоносный pull request в репозиторий TanStack Router, дальше сработал опасный паттерн pull_request_target, затем произошло poisoning кэша GitHub Actions, а уже на фазе релиза вредоносный код получил OIDC-токен из runner memory и опубликовал заражённые пакеты прямо в реестр.

По официальной временной шкале TanStack, между 19:20 и 19:26 UTC в npm ушли две волны публикаций. Итоговая подтверждённая область поражения у TanStack — 42 пакета и 84 вредоносные версии. Важная деталь: компания отдельно пишет, что npm-токены не были украдены, а штатный publish workflow не был скомпрометирован в привычном смысле. Атакующий воспользовался доверенным OIDC publishing-контуром через вредоносный код, который уже работал на runner'е.

Вывод неприятный, но важный для точности. Речь идёт не о банальной краже одного секрета и не о случайной публикации плохого пакета. Здесь сработала целая цепочка доверия: pull_request_target, кэш, OIDC и автоматизированный релиз. Если вам нужен близкий соседний кейс про то, как ломается доверенный pipeline, у нас уже есть отдельный разбор GitHub RCE через git push. Новый инцидент отличается тем, что удар дошёл до реального publish в npm и начал размножаться дальше.

Для пострадавших хостов TanStack рекомендует жёсткий сценарий: считать установившие затронутые версии системы потенциально скомпрометированными и ротировать GitHub-, npm-, SSH-, cloud- и Vault-учётные данные. Это не та ситуация, где достаточно просто обновить пакет и сделать вид, что ничего не произошло.

Почему Mistral делает эту историю важной для AI SDK

Если бы всё ограничилось только TanStack, это был бы крупный, но всё же фронтендовый и JavaScript-инфраструктурный инцидент. Mistral резко расширяет картину. В официальном advisory компания пишет, что была затронута supply-chain атакой, связанной с TanStack incident, и что в цепочке публикации участвовало скомпрометированное устройство разработчика, а не сама инфраструктура Mistral.

По состоянию на 12 мая 2026 года Mistral подтверждает две разные зоны риска. Первая — npm: затронутые версии были доступны только между 22:45 UTC 11 мая и 01:53 UTC 12 мая. Вторая — PyPI: релиз mistralai==2.4.6 был загружен около 00:05 UTC 12 мая и затем помещён в quarantine. В advisory отдельно сказано, что у npm-версий вредоносный Setup.mjs фактически безвреден, потому что ссылается на несуществующий файл, а вот PyPI-пакет уже запускает вредоносный код при импорте и поднимает фоновой процесс для кражи учётных данных.

Для Toolarium здесь важнее всего то, что удар по AI SDK идёт не где-то на периферии, а прямо по библиотеке, которую команды могут тянуть в Python- и JavaScript-проекты. Мы уже видели похожий паттерн в материале про взлом LiteLLM на PyPI, где вредоносная поставка била по AI-инфраструктуре через пакетный канал. История с Mistral показывает, что такой риск перестаёт быть единичным исключением.

Отдельно важно, чего в этом кейсе нет. Mistral прямо пишет, что у компании нет признаков компрометации собственной инфраструктуры. Поэтому формулировки уровня «Mistral взломали целиком» здесь были бы просто ложными. Корректнее говорить о компрометации конкретных SDK-пакетов и exposure window, а не о тотальном breach компании.

Страница Mistral Security Advisories с advisory MAI-2026-002 про атаку, связанную с TanStack
Mistral отдельно указала окно экспозиции по npm и quarantined-релиз mistralai==2.4.6 на PyPI. Источник: Mistral Docs

Почему в заголовке фигурирует UiPath, хотя у компании нет публичного postmortem

Это как раз тот участок, где редакции проще всего ошибиться. Если ориентироваться на официальные страницы, по TanStack и Mistral у нас есть прямые подтверждения. По UiPath на 12 мая 2026 года у меня через публичный поиск нет найденного corporate advisory по этой волне. Но у threat-intel-источников UiPath появляется стабильно.

Например, Mend 12 мая пишет о 172 уникальных пакетах и 403 вредоносных версиях на npm и PyPI за 48 часов, отдельно перечисляя среди затронутых scope'ов @tanstack, @uipath, @mistralai и @opensearch-project. Более осторожный OX Security в тот же день пишет про 170+ пакетов. Эти цифры уже сами по себе показывают, почему не стоит механически повторять число 404, пришедшее из вторичных пересказов. Разные исследователи считают волну в разный момент и по немного разной методике.

UiPath здесь важен ещё и по смыслу, а не только по счётчику. Официальная документация компании показывает, что UiPath CLI в public preview с 7 мая 2026 года распространяется через npm как пакет @uipath/cli. То есть сюжет выходит за пределы библиотек для фронтенда и AI SDK: он задевает ещё и enterprise automation tooling. Но подавать это нужно аккуратно: корректная формулировка — «по данным Mend, волна затронула scope @uipath», а не «UiPath официально подтвердила компрометацию».

Страница UiPath CLI release notes с public preview npm-пакета @uipath/cli
UiPath официально документирует public preview CLI на npm как @uipath/cli, но публичного advisory по этой волне на момент проверки не видно. Источник: UiPath Documentation

Почему Mini Shai-Hulud уже не просто про npm

Самое сильное наблюдение в этой истории даёт не TanStack и не Mistral по отдельности, а общий TTP кампании. По данным Socket, с конца апреля Mini Shai-Hulud использует общую архитектуру: preinstall- или import-time hook, загрузка Bun runtime, кража developer и CI/CD secrets, повторная публикация в доступные через украденные токены пакеты и persistence через .claude/settings.json и .vscode/tasks.json.

Для обычного разработчика это означает неприятную, но простую вещь: граница атаки проходит уже не только по node_modules. Она проходит по рабочей станции, где лежат SSH-ключи, cloud credentials, токены GitHub и конфиги локальных помощников. В этом смысле кейс рифмуется с нашим материалом о том, как ИИ-агенты атакуют разработчиков через тестовые задания. Там вредоносная логика тоже пряталась не в «главном приложении», а в доверенном рабочем окружении разработчика.

Отсюда и главный аналитический вывод. Supply-chain риск 2026 года уже нельзя описывать только как «плохой пакет украл секреты». Теперь это цепочка registry -> CI/CD -> trusted publishing -> workstation persistence. Чем больше в ней автоматизации, тем быстрее атака выходит из одного экосистемного кармана и перескакивает в соседние: из frontend-пакетов в AI SDK, из AI SDK в automation tooling, из package install в локальные конфиги агента.

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

Если упростить реакцию до практики, получается короткий чеклист.

  1. Проверьте lockfiles, build artifacts, package caches и container images на затронутые версии TanStack и Mistral. Для Mistral особенно важен mistralai==2.4.6 в Python-проектах.
  2. Если затронутые версии действительно ставились в окно экспозиции, безопаснее считать хост потенциально скомпрометированным, а не «надеяться, что именно у нас ничего не выполнилось».
  3. Ротируйте GitHub-, npm-, SSH-, cloud- и Vault-секреты, к которым могла иметь доступ машина или CI-runner.
  4. Проверьте GitHub Actions workflows с pull_request_target, политику кэшей, права id-token: write и вообще всё, что связано с trusted publishing.
  5. Просмотрите локальные AI-tool конфиги и рабочие директории: ~/.claude, .vscode/tasks.json, странные background-процессы, неожиданные артефакты в /tmp и сетевые запросы к неизвестным хостам.
  6. Если вы поддерживаете пакеты, пересмотрите не только секреты, но и саму архитектуру релизов: какой код может исполняться в trusted-контексте до этапа публикации.

В official postmortem TanStack и в advisory Mistral уже достаточно материала, чтобы понять: на уровне процессов проблема шире конкретного бренда. А если смотреть на расследования Mend, OX и Socket, становится ещё неприятнее: волна не закончилась на одном проекте и одном publish окне.

Итог

Mini Shai-Hulud важен не цифрой в заголовке и не только громкими именами TanStack или Mistral. Он важен как сигнал, что пакетная атака теперь живёт сразу в нескольких доверенных слоях: в CI/CD, в trusted publishing и на рабочей станции разработчика. Пока эти слои рассматривали по отдельности, можно было думать, что речь идёт о редком совпадении. После мая 2026 года это уже выглядит как новый нормальный сценарий риска.

Если коротко, вывод для команд разработки такой: мало проверять, что пакет «подписан» или опубликован легитимным publisher identity. Надо ещё понимать, какой путь код прошёл до этой публикации, что может исполниться в trusted-контексте и какие локальные инструменты превращаются в persistence-слой после установки зависимости.

Читайте также

Источники и проверка фактов

Telegram-канал @toolarium