Активний supply-chain хробак, який виявили через keyv і cacheable, 4 серпня 2026 року отруїв сотні npm-пакетів. SafeDep зафіксувала 2 234 шкідливі версії у 444 пакетах між 09:35 і 13:18 UTC, а Socket та Aikido незалежно відстежили початковий злам сімейства Keyv [1][2][3].
Якщо машина розробника або CI runner встановили один із цих релізів, не починайте з відкликання GitHub-токенів на тому самому хості. Проаналізований payload може встановити watcher, який реагує, коли викрадений токен перестає працювати. Спочатку ізолюйте систему й приберіть цю persistence, а облікові дані змінюйте потім із чистого пристрою.
Кому потрібно перевірити залежності
Перевірте проєкти, які отримали [email protected], уражені пакети cacheable або пізніші отруєні версії зі scopes на кшталт @ornikar і @hubsync. Ризик не обмежується прямими залежностями: flat-cache і file-entry-cache потрапляють у проєкти через ESLint, тому Keyv може не бути явно зазначений у manifest.
Поточний стан npm registry уже не дає повної відповіді. Частину шкідливих версій видалили, але вони можуть залишатися в lockfiles, CI caches і наявних каталогах node_modules. Під час розслідування SafeDep також бачила, що latest для багатьох назв усе ще вказував на отруєний реліз. Перевіряйте точну resolved-версію та її lifecycle scripts, а не припускайте, що оновлення безпечне.
| Що сталося | Ризик і наступна дія |
|---|---|
| Пакет є лише в lockfile і його не встановлювали | Заблокуйте інсталяцію, замініть отруєну версію, очистьте dependency caches і створіть lockfile заново з надійного джерела. |
npm install запускався на workstation або CI runner | Вважайте хост і доступні процесу облікові дані скомпрометованими. Ізолюйте систему до ротації токенів. |
| Репозиторій Keyv клонували, але не відкривали | Саме клонування не запускає описані hooks. Перевіряйте checkout, не відкриваючи його у VS Code або Claude Code. |
| Checkout відкривали у VS Code або Claude Code | Доданий task або session hook міг виконатися навіть без npm install. Перевіряйте хост як потенційно скомпрометований. |
Як запускається шкідливий код Keyv
Кожен отруєний реліз додавав команду preinstall, яка запускала setup.mjs ще до коду застосунку. Дослідники виявили збір GitHub- і npm-токенів, cloud credentials, Vault- і Kubernetes-токенів, database URLs, private keys та secrets із пам’яті GitHub Actions runner.
У репозиторії Keyv був і другий шлях виконання. Шкідливі .vscode/tasks.json та .claude/settings.json посилалися на локальні setup scripts, тому відкриття репозиторію в editor або coding-agent session могло запустити той самий ланцюг. Verified commit у GitHub і valid SLSA provenance не зробили реліз безпечним: справжній workflow зібрав код, який уже контролював атакувальник.
Це новий exact-package інцидент після попередньої хвилі Shai-Hulud проти AntV. Базовий урок той самий, але випадок Keyv додає до рішення IDE hooks і тригер на відкликання токена.
Реагуйте у правильному порядку
- Ізолюйте уражені машини розробників і runners. Призупиніть package publishing та deployment workflows, які використовували ті самі identities.
- Знайдіть token watcher до відкликання. Перевірте
~/.config/gh-token-monitor/, macOS LaunchAgentcom.user.gh-token-monitorі user servicegh-token-monitor.service. Видаліть unit і вимкніть lingering, якщо його активували. - Перевірте артефакти залежностей і репозиторіїв. Шукайте в lockfiles, caches і
node_modulesуражені назви,setup.mjs,Math_Symbol.jsабоmath_init.js. У доступних репозиторіях перевірте.claude/settings.json,.claude/setup.mjs,.vscode/tasks.json,.vscode/setup.mjs, workflow з назвоюRun Copilotі рядокtoJSON(secrets). - Змінюйте credentials із чистої системи. Замініть GitHub PATs і app tokens, npm tokens, cloud- і Vault-credentials, Kubernetes service-account tokens, database secrets та private keys, доступні скомпрометованому процесу.
- Перебудуйте середовище замість довіри до uninstall. Видаліть dependency caches і робочі копії, встановіть лише перевірені чисті версії з вимкненими lifecycle scripts, де це можливо, і перегляньте package-publishing history.
- Перевірте цілісність source. Застосуйте ті самі repository checks, що й після атак через AI-конфігурації в npm, PyPI і Crates.io: protected branches, workflow files, deploy keys та downstream clones.
Чого не слід припускати
- «Пакет видалили, тому ми в безпеці». Lockfiles і caches можуть зберігати неопубліковану шкідливу версію.
- «У релізу є provenance, отже він чистий». Provenance може правильно підтвердити, що скомпрометований trusted workflow зібрав отруєний source.
- «Ми змінили токен, тож інцидент завершено». У цій кампанії відкликання токена може активувати watcher, якщо responders не видалили його спочатку.
- «Ми не запускали npm install». Відкриття скомпрометованого checkout Keyv у підтримуваних інструментах розробника могло виконати додані repository hooks.
Для порівняння механізмів перевірте також зламані пакети Joyfill у npm, де ризик ішов через шкідливі production bundles, а не через IDE hooks.
Джерела
- SafeDep Team. “npm Worm Poisons keyv, cacheable and 400+ Other Packages Across Twelve Organisations.” SafeDep, 4 серпня 2026 року; дата доступу: 4 серпня 2026 року. Дослідження та перелік уражених версій.
- Socket Research. “Popular npm Packages in the keyv and Cacheable Namespaces Compromised in Active Supply Chain Attack.” Socket, опубліковано й оновлено 4 серпня 2026 року; дата доступу: 4 серпня 2026 року. Аналіз інциденту.
- Aikido Security. “Keyv and Friends Compromised in npm Supply Chain Attack.” Aikido, 4 серпня 2026 року; дата доступу: 4 серпня 2026 року. Висновки про пакети й акаунт мейнтейнера.
