Технічний контекст
Я занурився в постмортем TanStack одразу після публікації, бо це не просто черговий npm-інцидент. Тут гірше: шкідливі пакети вийшли через офіційний release pipeline, а отже, будь-яка команда, що будує AI-інтеграції чи звичайний прод на довірі до provenance, повинна напружитися.
Вікно атаки було коротким: 11 травня 2026 року з 19:20 до 19:26 UTC. За ці шість хвилин зловмисник опублікував 84 шкідливі версії у 42 пакетах @tanstack/*.
Паролі мейнтейнерів не вкрали. npm publish workflow безпосередньо теж не зламали. Атакуючий підмінив вхідні дані в CI так, що пайплайн TanStack сам випустив заражені збірки під своєю довіреною OIDC-ідентичністю.
І ось тут я реально завис на хвилину: релізи мали валідні атестації походження (provenance attestation). Тобто звична логіка "підпис є, trusted publishing є, значить все чисто" в цьому кейсі не спрацювала.
Ланцюжок атаки виглядав дуже сучасно. Спочатку використали небезпечний патерн `pull_request_target`, той самий Pwn Request. Потім отруїли кеш GitHub Actions на межі між форком та основним репозиторієм. А вже в release job витягли короткоживучий OIDC-токен прямо з пам'яті процесу runner-а.
По суті, CI вкрав токен сам у себе в момент публікації. Це вже не історія про "не зберігайте секрети в репо". Це історія про те, що кеш, артефакти та межі довіри (trust boundary) в GitHub Actions потрібно вважати ворожими за замовчуванням.
Якщо ви завантажували @tanstack/* у ці дати, я б не обмежувався оновленням версії. Я б перезібрав проєкт із чистим lockfile, зніс кеш, перевірив CI-логи на дивні мережеві запити та ротував секрети, якщо заражений пакет хоч раз виконувався в пайплайні.
Що це змінює для бізнесу та автоматизації
Програють команди, чиї релізи тримаються на "ну в нас же trusted publishing". Виграють ті, хто розділяє недовірені PR, збірку та публікацію за різними зонами довіри.
Другий висновок ще практичніший: безпекою ланцюга постачання більше не можна займатися вручну за чеклістом раз на квартал. Потрібні надійні правила, сканування lockfile, контроль кешу, реакція на інциденти та автоматизація відкату.
Ми в Nahornyi AI Lab якраз закриваємо такі місця на практиці: проєктуємо архітектуру AI-рішень навколо DevSecOps-процесів, щоб команда не виявляла компрометацію постфактум за логами. Якщо ваш CI/CD вже розрісся і ніхто не може швидко довести, що саме є безпечним, давайте розберемо це і створимо AI-автоматизацію під ваш реальний workflow, а не для красивої схеми в Notion.