EVERYTHING
Масове інфікування через хуки preinstall та тріо з ESLint
Атака розгорнулася 4 серпня 2026 року впродовж вузького часового вікна між 09:35 та 13:18 UTC. Хробак поширювався через життєвий цикл пакетів npm: кожна отруєна версія містила директиву preinstall, яка автоматично запускала файл setup.mjs перед виконанням будь-якого коду додатка.
Вектор ураження виявився значно ширшим за прямі залежності. Завдяки транзитивним зв'язкам через flat-cache та file-entry-cache — стандартні компоненти, які активно використовує фоновий лінтер ESLint — хробак проник у тисячі проєктів, де розробники навіть не підозрювали про наявність keyv у своєму деревоподібному граф-дереві. Шкідливе навантаження збирало токени GitHub, ключі доступу npm, конфігурації Kubernetes, AWS-секрети та вміст оперативної пам'яті runner-серверів у GitHub Actions.
Пастка в IDE та маскування під валідацію SLSA
Автори атак розширили традиційні межі постачання коду, інтегрувавши вектор атаки безпосередньо у середовища розробки та розширивши набір інструментів автопідказок:
- Запуск коду без команди інсталяції: відкриття клонованого репозиторію в середовищі VS Code через .vscode/tasks.json або в агенті Claude Code через .claude/settings.json автоматично запускало шкідливий локальний скрипт.
- Обхід криптографічних підписів: отруєний реліз keyv пройшов перевірку SLSA provenance та мав підтверджені коміти, оскільки зловмисники скомпрометували сам легітимний конвеєр збірки.
- Небезпека збереження в кеші: навіть після видалення з реєстру npm шкідливі релізи залишалися в файл-замках lockfile та логіці розв'язання залежностей node_modules.
Пастка відкликання: чому стандартний протокол реагування не працює
Головною несподіванкою аналізу для DevSecOps-команд виявився механізм самозахисту шкідника. Під час інфікування робочої станції або CI-вузла setup.mjs реєструє фоновий процес у каталозі ~/.config/gh-token-monitor/ або у службі systemd. Цей модуль безперервно відстежує статус викрадених токенів GitHub.
Якщо інженер виявляє витік і першим ділом анулює токен зі скомпрометованого хоста, монітор розцінює це як початок зачистки та негайно запускає резервний сценарій: знищує локальні логи, створює приховані точки стійкості у системі та ініціює вторинну детонацію. Експерти наголошують, що реагувати на інцидент слід строго у зворотному порядку: спочатку ізолювати хост і демобілізувати фонового монітора, і лише потім, з чистого пристрою, здійснювати ротацію облікових даних.