Как взломали популярные пакеты TanStack: что грозит сайтам

11 мая 2026 года злоумышленники подменили 84 версии в 42 готовых блоках кода (их называют пакетами) семейства @tanstack/*. Эти блоки используют тысячи сайтов на React и Next.js. Через два дня компания OpenAI призналась: у двух её сотрудников взломали рабочие компьютеры и украли цифровые подписи приложений для Mac, iPhone, Windows и Android. Если ваш сайт собран на TanStack Router, Start или Devtools - ниже простой план действий. Делать его нужно по порядку: если первым шагом отозвать рабочий доступ к GitHub, можно потерять всю папку разработчика.

Что вообще произошло

Современный сайт собирается не с нуля. Разработчик берёт сотни готовых блоков кода из реестра npm (главный склад библиотек для JavaScript) и подключает их одной командой. Если кто-то подменит такой блок и зальёт туда зловредный код, заражёнными окажутся все сайты, которые поставят свежую версию.

Это и называют атакой на цепочку поставок. Один взломанный склад - сотни заражённых проектов.

Похожая история уже случалась в сентябре 2025 года: тогда злоумышленники запустили в npm червя по имени Shai-Hulud (отсылка к песчаным червям из «Дюны»). Май 2026 - это его младший брат: Mini Shai-Hulud. Тот же сценарий, но через другую дыру и с более жестоким финалом.

TanStack - набор популярных библиотек от Таннера Линсли. В семейство входят TanStack Query, Router, Table, Form. Это привычные инструменты для тех, кто делает сайты на React и Next.js. Самая популярная библиотека из набора скачивается, по разным оценкам, от 12 до 36 миллионов раз в неделю. То есть жертвой могла стать практически любая команда.

Главное отличие от атак на работающий сайт: тут под удар попадает компьютер программиста и серверы автоматической сборки. А именно на них хранятся ключи от всего - от облака, баз данных и серверов вашего клиента.

Хронология: как ломали

10 мая злоумышленник с прозвищем zblgg сделал свою копию репозитория TanStack/router на GitHub. 11 мая в 13:49 по Москве он предложил безобидное на вид изменение под названием «WIP: simplify history build». Это автоматически запустило один из служебных скриптов проекта.

Скрипт был написан так, что прозрачно подтягивал и исполнял код из присланного предложения - с правами основного проекта. Среди специалистов по безопасности такую ошибку называют «Pwn Request». Дальше в 14:29 МСК злоумышленник подкинул в общий кэш сборки (около 1,1 ГБ) подменённые служебные программы. Кэш пролежал в системе около 8 часов.

В 22:15 МСК команда TanStack залила в основной код плановое обновление. Сборка автоматически запустилась - и подцепила тот самый отравленный кэш. Подменённые программы выполнились уже от имени самого проекта TanStack.

Дальше их интересовал короткоживущий ключ для публикации в npm. У современного npm можно отказаться от постоянных паролей и пользоваться временным ключом, который генерируется только для одного выпуска. Подменённые программы вытащили его прямо из памяти сборщика и за шесть минут опубликовали 84 заражённые версии. Подробный разбор - в постмортеме TanStack. Через 20 минут заметили независимые исследователи, ещё через несколько часов npm уже знал о проблеме.

Что делал зловредный код, когда попадал на компьютер программиста или на сервер сборки: искал пароли, ключи доступа к GitHub, к Amazon, к Google, к платным сервисам с искусственным интеллектом. Найденное отправлял злоумышленникам по защищённому каналу. После этого пытался опубликовать заражённые версии всех других пакетов, которые поддерживает этот разработчик. Так атака размножалась.

И главное - ловушка для администраторов. Если на компьютере находился рабочий ключ доступа к GitHub, зловред оставлял на машине маленькую программу-сторожа. На Mac она прописывалась в автозапуск как com.user.gh-token-monitor, на Linux - как фоновая служба пользователя. Раз в минуту она проверяла, жив ли ключ. Как только администратор пытался ключ отозвать (обычная первая реакция: «утекло - отзывай»), сторож понимал, что его пора заметать следы, и выполнял команду rm -rf ~/. Это команда полного удаления домашней папки разработчика. Со всеми проектами, ключами и письмами. Разбор у TheHackerNews.

В случае оригинального Shai-Hulud такой ловушки не было. Тут она новая и опасная.

Что взломали у OpenAI

13 мая OpenAI подтвердила: у двоих сотрудников рабочие компьютеры заразили через npm-пакеты TanStack. Через эти компьютеры злоумышленники добрались до части внутренних хранилищ кода и вынесли часть служебных ключей. Самое чувствительное из вынесенного - цифровые подписи, которыми OpenAI подписывает свои приложения: ChatGPT, Codex, Atlas. Без такой подписи Mac, например, просто откажется запускать программу.

Что важно: ни данные пользователей, ни рабочие серверы OpenAI не пострадали. По крайней мере так пишет сама компания. Формулировку стоит читать буквально: «доказательств не нашли» не равно «точно ничего не было».

Главное практическое следствие - для тех, у кого на Mac установлены приложения OpenAI. Старые подписи отзываются 12 июня 2026 года. После этой даты Mac заблокирует запуск приложений со старой подписью. Поэтому к 12 июня надо обновить у себя ChatGPT Desktop, Codex App, Codex CLI и браузер Atlas. Пользователям iPhone, Windows и Android делать ничего не нужно - там обновления приходят сами через магазины приложений.

Если хотите глубже разобраться, как делать ИИ-инструменты безопасно для своих клиентов, у нас есть разбор подхода Codex и материал про Ollama и Codex App с локальными моделями.

Что делать, если ваш сайт использует TanStack

Главное правило, ещё раз: на возможно заражённом компьютере не отзывайте ключи в первую очередь. Сначала уберите сторожа, иначе можно остаться без домашней папки.

Делать так:

1. Отключите от сети компьютер или сервер, на котором между вечером 11 мая и публикацией исправлений запускалось обновление пакетов.
2. Проверьте автозапуск. На Mac: ls -la ~/Library/LaunchAgents/com.user.gh-token-monitor.plist. На Linux: systemctl --user status gh-token-monitor.service. Если файл нашёлся, остановите его и удалите.
3. Поищите процессы: ps aux | grep token-monitor. Что нашли - снимайте по идентификатору.
4. Теперь и только теперь отзывайте ключи: к GitHub, к npm, к облакам Amazon, Google и Yandex, к закрытым серверам, к сервисам с искусственным интеллектом, к почте, к базам данных. Заодно меняйте все пароли, которые лежали на этой машине открытым текстом.
5. Сверьте свой проект со списком заражённых версий в официальном сообщении TanStack. Команда для проверки: npm ls @tanstack/router @tanstack/start @tanstack/devtools. Незатронутыми остались @tanstack/query, @tanstack/table, @tanstack/form, @tanstack/virtual, @tanstack/store - этими можно пользоваться спокойно.
6. Прогоните проект через готовую проверялку: mini-shai-hulud-checker. Запускается одной командой, ищет следы заражения.

Что стоит сделать, чтобы такая атака не пробила вас в следующий раз:

• Поставьте задержку на свежие пакеты. Команда npm config set minimum-release-age 7 означает «не ставь ничего моложе семи дней». OpenAI после инцидента включила это правило у себя на сборках. Не панацея, но шесть-семь дней - реальное время, за которое атаку успевают заметить.
• Фиксируйте конкретные версии в файле зависимостей. Без значков ^ и ~, которые разрешают подтягивать свежие выпуски.
• На каждом ревью смотрите, что нового появилось в файле package-lock.json. Если туда внезапно подтянулась библиотека от незнакомого автора - повод задержаться.
• Разделите доступы. Один ключ для сервера сборки, другой - для машины разработчика. Если утечёт один, другой останется живым.

У нас на digitalimpuls.ru сайт собран на Next.js со статической сборкой. Зависимости зафиксированы по версиям, никаких автоматических обновлений в боевой выкладке нет. Для клиентов в экспресс-сайтах и техническом SEO мы держим тот же подход: фиксированные версии, отдельные ключи для сборки, задержка на свежие пакеты. Это не серебряная пуля, но окно для подобной атаки становится узким. Подробнее - на странице о нашей команде.

Где мы не уверены

Точную цифру скачиваний TanStack Query называют по-разному: 12 миллионов в неделю в одних источниках, 36 в других. Для оценки риска неважно - это в любом случае десятки миллионов.

Сколько именно служебных ключей утекло у OpenAI и какие именно - в публичном заявлении не раскрывается. Сказано «ограниченное количество». Что туда входит помимо подписей - можно только догадываться.

И главное: ровно та же атака может повториться через любую другую популярную библиотеку из npm. Изученный метод не делается секретным, и других популярных репозиториев с похожей дырой в сборке - десятки.

Что будет дальше

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

Мы у себя в работе уже включили задержку в семь дней на свежие пакеты и поделили ключи между сборкой и компьютерами команды. Дальше - аккуратные обновления и тщательная проверка package-lock.json на каждом ревью. Будем рассказывать что получится в нашем канале @digitalimpulschannel - там короткие разборы релизов и заметки о том, что мы пробуем в работе.