Українське техношоу «УТ‑2» у свіжому випуску розбирає одну з найгучніших історій безпеки JavaScript‑світу останніх місяців: компрометацію екосистеми TanStack, коли зловмисник зумів підмінити понад 80 npm‑пакетів через маніпуляцію кешем у GitHub Actions. На перший погляд це ще один «supply chain» інцидент, але деталі роблять його показовим кейсом про те, наскільки крихкою стала сучасна культура JavaScript‑залежностей і CI‑інфраструктури.
Злам ланцюжка постачання TanStack: не код, а кеш
TanStack — це популярний набір бібліотек для React та інших фронтенд‑фреймворків, який використовується у тисячах проєктів. Саме тому атака на його ланцюжок постачання стала такою чутливою: мова не про один пакет, а про цілу екосистему, яка автоматично підтягується через npm.
Ключовий момент: зловмисник не починав із класичного зламу репозиторію з кодом. Поворотним кроком стало викрадення npm‑токена з правами запису в репозиторій. Маючи цей токен, атакувальник отримав можливість впливати не лише на публікацію пакетів, а й на те, як працює CI‑процес, зокрема кешування залежностей у GitHub Actions.
Саме через цей вектор і відбулася підміна понад 80 npm‑пакетів TanStack. Замість того, щоб безпосередньо змінювати вихідний код у репозиторії, зловмисник отруїв кеш pnpm, який використовувався в GitHub Actions. У результаті CI‑система збирала й публікувала пакети, що містили шкідливий код, навіть якщо сам репозиторій виглядав «чистим» для огляду.
Це важливий зсув у розумінні supply chain‑ризиків. Раніше основна увага була на захисті вихідного коду, прав доступу до репозиторію, рев’ю pull‑реквестів. Інцидент із TanStack показує, що CI‑інфраструктура, кеші та токени публікації стають не менш критичними елементами ланцюжка довіри.
Отруєний кеш pnpm: як CI сам собі підклав вірус
Механіка атаки обертається навколо однієї з найпопулярніших практик оптимізації CI — агресивного кешування залежностей. У JavaScript‑проєктах це особливо актуально: десятки й сотні дрібних пакетів, які при кожній збірці тягнуть гігабайти даних із реєстру. pnpm, як і інші менеджери пакетів, активно використовує кеш, а GitHub Actions дозволяє зберігати його між запусками workflow.
У випадку TanStack саме цей кеш став точкою ін’єкції. Маючи npm‑токен із правами запису, зловмисник зміг записувати отруєний кеш pnpm і підсовувати його CI‑процесам. Далі все відбувалося автоматично:
CI запускає збірку пакета.
Замість «чистих» залежностей із реєстру підтягується кеш, у якому вже лежать модифіковані артефакти.
Пакет збирається й публікується в npm із вбудованим шкідливим кодом.
Критично те, що для цього не потрібно було змінювати вихідний код пакета в репозиторії. З погляду розробників, історія комітів могла виглядати абсолютно нормально. Ніяких підозрілих PR, ніяких дивних змін у файлах. Уся «магія» відбувалася в CI‑шарі, який зазвичай сприймається як технічна інфраструктура, а не як потенційне джерело компрометації.
Це створює небезпечну ілюзію безпеки. Команди, які покладаються на рев’ю коду як основний бар’єр, виявляються беззахисними перед отруєним кешем. Будь‑який токен, що дозволяє писати в кеш або публікувати пакети, фактично стає ключем до всього ланцюжка постачання.
Інцидент із TanStack оголює ще одну проблему: складність відстеження таких атак. Якщо шкідливий код не присутній у репозиторії, а з’являється лише в опублікованому артефакті, розслідування потребує аналізу CI‑логів, стану кешу, історії токенів. Це вже не просто «подивитися diff», а повноцінна форензика інфраструктури.
Що шукав вірус: від AWS‑ключів до systemd‑персистентності
Компрометація TanStack не обмежилася демонстрацією технічної витонченості. Шкідливий код, вбудований у скомпрометовані пакети, був цілком прагматичним: він полював за найціннішими активами розробників і серверів.
По‑перше, вірус намагався викрасти AWS‑креденшали. Це логічна ціль: доступ до AWS‑акаунтів відкриває шлях до баз даних, сховищ, черг, секретів, а іноді й до повного контролю над інфраструктурою компанії. Для атакувальника це можливість як для подальшого шантажу, так і для розгортання нових атак уже всередині хмарного середовища жертви.
По‑друге, шкідливий код збирав SSH‑ключі. Це ще один класичний інструмент горизонтального руху в мережі. Компрометований SSH‑ключ може дозволити доступ до репозиторіїв, серверів, CI‑систем, внутрішніх інструментів. У поєднанні з AWS‑ключами це створює потужний набір для подальшої ескалації.
По‑третє, вірус встановлював systemd‑сервіс для збереження персистентності на скомпрометованих машинах. Це вже не просто «одноразовий скрипт», який відпрацьовує під час встановлення пакета. Це спроба закріпитися в системі на довгий час, пережити перезавантаження, оновлення й навіть частину заходів очищення.
Така поведінка наближає атаку до повноцінного malware‑класу, а не до «разового» supply chain‑інциденту. Вона показує, що зловмисник мислив не категоріями «погратися з npm», а прагнув побудувати стійку інфраструктуру доступу до машин розробників і серверів.
Усе це підкреслює ще одну неприємну істину: розробницькі машини давно стали високовартісними цілями. На них зосереджені ключі до хмар, репозиторіїв, CI, секретів. Атака на TanStack лише ще раз нагадує, що «dev‑ноутбук» — це не просто робочий інструмент, а критичний вузол безпеки компанії.
Новий клас цілей: AI‑токени, Claude Code, VS Code
Окрема деталь, яка робить атаку на TanStack симптоматичною для 2025–2026 років, — це інтерес зловмисника до інструментів розробки з підтримкою AI. Шкідливий код містив хуки для інструментів на кшталт Claude Code та VS Code і збирав токени доступу до AI‑API.
Це важливий сигнал: токени до AI‑сервісів стають новим класом цінних цілей. Якщо раніше основна увага була на AWS, GCP, Azure, GitHub, GitLab, то тепер у цьому списку з’являються OpenAI, Anthropic, інші провайдери моделей і AI‑IDE.
Причин кілька.
По‑перше, AI‑токени часто мають широкий доступ і слабкі обмеження. Багато команд видають їх «на всіх» для зручності, не налаштовуючи жорсткі квоти, IP‑фільтри чи окремі ключі на користувача. Це робить їх привабливими для зловмисників: один токен може відкрити доступ до значних обсягів обчислювальних ресурсів і даних.
По‑друге, через AI‑інструменти часто проходять фрагменти коду, конфігурацій, навіть секретів. Якщо атакувальник отримує доступ до історії запитів або може підміняти відповіді, це відкриває нові сценарії атак — від витоку інтелектуальної власності до ін’єкції в ланцюжок розробки.
По‑третє, AI‑інструменти інтегруються в IDE, CI, репозиторії. Це створює додаткові точки входу. Хук у VS Code або Claude Code — це можливість не лише вкрасти токен, а й спостерігати за роботою розробника, підсовувати йому змінений код, впливати на автодоповнення.
Той факт, що шкідливий код у TanStack‑атаці вже враховував Claude Code і VS Code, показує, наскільки швидко зловмисники адаптуються до нової реальності. Для них AI‑екосистема — це не модна іграшка, а ще один ресурс, який можна монетизувати або використати для подальших атак.
Для компаній це означає, що політика безпеки має поширюватися й на AI‑інструменти. Токени до моделей, плагіни IDE, інтеграції з AI‑сервісами мають розглядатися так само серйозно, як доступи до хмарних акаунтів чи репозиторіїв.
Культура npm: мікрозалежності, автоматична довіра і «злі» пакетні менеджери
На тлі інциденту з TanStack ведучі «УТ‑2» переходять до ширшої критики культури npm і JavaScript‑екосистеми загалом. Їхній тезис простий: сучасні пакетні менеджери, особливо в світі JavaScript, створюють надмірну поверхню атаки через мікрозалежності та автоматичну довіру до сторонніх пакетів.
JavaScript‑проєкт із кількома десятками прямих залежностей легко розростається до сотень і тисяч транзитивних. Багато з них — це крихітні пакети, які реалізують одну‑дві функції. У нормальних умовах це зручно: можна швидко збирати функціональність із готових блоків. Але з погляду безпеки кожен такий блок — це ще одна потенційна точка компрометації.
У поєднанні з автоматичним оновленням залежностей і агресивним кешуванням у CI це створює ідеальне середовище для supply chain‑атак. Один скомпрометований пакет, одна отруєна версія, один зламаний токен — і шкідливий код розповсюджується по всій екосистемі, часто без будь‑якого ручного втручання з боку розробників.
Ведучі використовують кейс TanStack, щоб підкреслити: проблема не лише в одному зловмиснику чи одному токені. Проблема в тому, як влаштована культура розробки на npm. Занадто багато довіри до сторонніх пакетів, занадто мало обмежень на те, що може робити код під час встановлення, занадто велика залежність від кешів і автоматизації.
Фраза «package managers are evil» у цьому контексті звучить не як буквальне звинувачення, а як констатація: інструменти, покликані спростити життя розробникам, одночасно створили величезну й слабо контрольовану поверхню атаки. І поки екосистема не перегляне свої базові практики, подібні інциденти будуть повторюватися.
Чому JavaScript‑стек вразливіший: порівняння з pip, Rust, Go, Zig
Щоб зрозуміти, наскільки специфічною є ситуація з npm, ведучі порівнюють її з іншими екосистемами — Python (pip, uv), Rust, Go, Zig. У кожної з них є свої проблеми, але JavaScript‑світ виглядає особливо вразливим через поєднання кількох факторів.
По‑перше, дрібнозернисті залежності. У Rust чи Go теж є сторонні бібліотеки, але культура «одна функція — один пакет» там менш розповсюджена. У Zig, наприклад, часто віддають перевагу вбудованим можливостям мови й стандартної бібліотеки, а не нескінченним зовнішнім модулям. У результаті типовий проєкт має менше транзитивних залежностей, а отже, менше потенційних точок зламу.
По‑друге, модель розповсюдження. Go за замовчуванням тягне залежності з їхніх репозиторіїв, Rust використовує crates.io з досить прозорою моделлю, Python‑світ поступово рухається в бік більш контрольованих інструментів на кшталт uv. У JavaScript‑світі npm став де‑факто єдиним центром, через який проходить усе, і будь‑яка компрометація в цьому ланцюжку миттєво б’є по величезній кількості проєктів.
По‑третє, агресивне кешування. Усі екосистеми намагаються пришвидшити збірки, але в JavaScript це часто робиться без достатнього усвідомлення безпекових наслідків. Кеші в GitHub Actions, локальні кеші менеджерів пакетів, артефакти CI — усе це використовується як чорна скринька: «воно просто працює швидше». Атака на TanStack показує, що саме ці чорні скриньки можуть стати головним вектором зламу.
По‑четверте, культура швидких оновлень. У JavaScript‑світі нормою є часті релізи, автоматичні оновлення, залежність від останніх версій. Це добре для інновацій, але погано для безпеки: вікно між публікацією скомпрометованої версії й її потраплянням у продакшн може бути ліченими годинами.
У підсумку JavaScript‑стек виявляється особливо чутливим до атак на ланцюжок постачання. TanStack — лише один із прикладів, але він добре ілюструє, як поєднання мікрозалежностей, автоматичної довіри й кешування створює ідеальні умови для зловмисників.
Що це означає для розробників і компаній
Історія з TanStack — це не просто ще один інцидент, який можна забути після оновлення пакетів. Вона ставить незручні запитання до всієї індустрії.
По‑перше, чи достатньо уваги приділяється захисту токенів? npm‑токен із правами запису виявився ключем до всієї атаки. Це означає, що політика зберігання, ротації й обмеження прав таких токенів має стати пріоритетом. Мінімально необхідні привілеї, окремі токени для CI, жорсткі обмеження на те, де вони можуть використовуватися, — усе це вже не «best practice», а базова гігієна.
По‑друге, чи не час переглянути ставлення до кешів у CI? Кешування залежностей економить хвилини й долари, але може коштувати репутації й безпеки. Можливо, для критичних пакетів варто відмовитися від кешів або принаймні валідувати їхній вміст, перевіряти хеші, використовувати підписані артефакти.
По‑третє, чи не занадто ми довіряємо стороннім пакетам? Культура «постав ще одну залежність, щоб не писати дві стрічки коду» виглядає привабливо, але кожна така залежність — це ще один ризик. Можливо, варто свідомо обмежувати кількість сторонніх бібліотек, особливо дрібних, і частіше обирати стандартні засоби мови.
По‑четверте, чи готові ми сприймати AI‑інструменти як повноцінний об’єкт безпеки? Токени до моделей, плагіни IDE, інтеграції з Claude Code чи VS Code — усе це має потрапити в поле зору security‑команд. Інакше наступні атаки будуть націлені не лише на AWS‑ключі, а й на AI‑інфраструктуру компаній.
TanStack‑інцидент не дає простих відповідей, але чітко показує: JavaScript‑екосистема досягла точки, де зручність і швидкість почали прямо конфліктувати з безпекою. Ігнорувати це стає дедалі дорожче.
Висновок: час переосмислити довіру в JavaScript‑світі
Компрометація понад 80 npm‑пакетів TanStack через отруєний кеш pnpm у GitHub Actions — це не випадковість і не «дивна аномалія». Це логічний результат того, як побудована сучасна JavaScript‑екосистема: мікрозалежності, автоматичні оновлення, агресивне кешування, широка довіра до сторонніх пакетів і сервісів.
Зловмисник, який викрав npm‑токен із правами запису, зумів використати саму інфраструктуру CI проти її власників. Шкідливий код, що полює за AWS‑креденшалами, SSH‑ключами, AI‑токенами й закріплюється через systemd‑сервіс, показує, наскільки цінними стали машини розробників і наскільки привабливою мішенню є їхній стек інструментів.
Порівняння з іншими екосистемами — від pip і uv до Rust, Go та Zig — лише підкреслює: JavaScript‑світ опинився в особливо вразливій позиції. Вихід із неї потребує не лише патчів і ротації токенів, а й переосмислення самої культури залежностей, кешування й довіри до інструментів.
Поки цього не станеться, історії на кшталт TanStack залишатимуться не винятком, а передвісником наступних, можливо ще масштабніших атак.
Джерело
Samsung страйкує, npm горить, Anthropic рахує мільярди. UUIDи крутяться – лавешка мутиться. mvc #28