Введение: Когда доверие становится главной уязвимостью

Представь: обычное рабочее утро, ты завариваешь кофе и привычно вводишь npm install. Ты доверяешь библиотекам семейства TanStack так же, как доверяешь гравитации — это фундаментальный слой, на котором держится твой фронтенд. React Query, TanStack Table и Router стали де-факто стандартом индустрии, их используют все: от пет-проектов до гигантов вроде Microsoft и Airbnb.

Но что, если «база», на которой строится твой проект, внезапно оборачивается против тебя? Недавний инцидент с компрометацией пакетов TanStack в реестре NPM стал холодным душем для всего сообщества. Это была классическая Supply Chain Attack: в мире, где типичное приложение тянет за собой тысячи зависимостей, один взломанный аккаунт мейнтейнера превратился в «мастер-ключ» от данных миллионов пользователей. Давайте разберем, как именно это произошло и почему ваш CI/CD мог стать соучастником кражи.

Хронология инцидента: От первого алерта до глобального отзыва

Всё началось не с громких заголовков, а с тихих алертов автоматизированных систем мониторинга. Исследователи из Socket и Snyk первыми заметили странную активность в свежих минорных версиях пакетов @tanstack. Пока разработчики спали, их терминалы уже исполняли чужой код.

Точки входа: Кто оказался под ударом?

Злоумышленники, получив доступ к аккаунту одного из мейнтейнеров, действовали быстро и прицельно. Вредоносный код был внедрен в самые популярные библиотеки:

  • @tanstack/react-query
  • @tanstack/query-core
  • @tanstack/react-table

Представь ситуацию: твой CI-пайплайн настроен на автоматическое обновление минорных версий (через ^ в package.json). В ту секунду, когда вредонос попал в реестр, каждая новая сборка проекта становилась зараженной. Скорость распространения была пугающей: всего за два часа «отравленные» пакеты скачали более 50 000 раз.

Механика атаки: Скрытый postinstall

Хакеры не стали ломать логику самой библиотеки — это слишком заметно, ведь UI мог просто «поплыть». Вместо этого они использовали легитимный механизм NPM — скрипт postinstall. В файле package.json появилась неприметная строка:


"scripts": {
  "postinstall": "node ./dist/scripts/setup.js"
}

Скрипт setup.js был тщательно обфусцирован, чтобы не мозолить глаза при беглом просмотре кода. Его единственная задача — тихо собрать «цифровое золото» из твоего окружения.

Технический разбор: Что именно крал вредонос?

Целью атаки были переменные окружения (Environment Variables). В современных облачных реалиях именно там хранятся ключи доступа к AWS, секретные токены Stripe, пароли от баз данных и конфигурации CI/CD. Получив их, злоумышленник получает полный контроль над твоей инфраструктурой.

Как работал алгоритм эксфильтрации:

  1. Сбор данных: Скрипт сканировал process.env, а также целенаправленно искал файлы .env, .env.local и конфиги .npmrc в корне проекта и в домашней директории пользователя.
  2. Упаковка и отправка: Все найденные секреты кодировались в Base64 и улетали обычным HTTP-запросом на удаленный сервер. Чтобы не привлекать внимания фаерволов, запрос маскировался под безобидную аналитику или проверку обновлений.
  3. Заметание следов: В некоторых случаях скрипт пытался модифицировать локальные файлы, чтобы скрыть факт своего присутствия после выполнения основной задачи.
«Это кошмар любого мейнтейнера. Вы просыпаетесь от сотен уведомлений и понимаете, что ваше честное имя теперь ассоциируется не с удобным инструментом, а с вектором атаки на тысячи компаний», — так описывают состояние команды TanStack в первые часы расследования.

Выводы: Как не стать следующей жертвой

Инцидент с TanStack — это не просто досадный баг, это напоминание о том, что безопасность в JS-экосистеме висит на волоске. Чтобы не оказаться в ситуации, когда ваши AWS-ключи гуляют по даркнету, стоит пересмотреть подход к зависимостям:

  • Используйте Lock-файлы: package-lock.json или yarn.lock должны быть законом. Не позволяйте CI качать то, что вы не проверили локально.
  • Запретите скрипты при установке: Используйте флаг --ignore-scripts для подозрительных или новых пакетов.
  • Мониторинг: Внедрите инструменты вроде npm audit или Snyk в ваш CI/CD цикл, чтобы блокировать сборку при обнаружении известных уязвимостей.

Доверие в Open Source больше не может быть безусловным. Проверьте свои зависимости сегодня, ведь безопасность вашего проекта начинается не с фаервола, а с того, что написано в вашем package.json.