Технічний контекст
Я зачепився за цю історію не через черговий npm-інцидент, а через механіку виживання. Тут шкідливий код не тримається за пакет як такий. Він використовує нормальні, легітимні хуки в Claude Code та VS Code, щоб запускатися знову на подіях інструменту.
За описом з публікацій, мета проста й неприємна: прописатися в .claude/settings.json та .vscode/tasks.json. Після цього звичайний npm uninstall вже не вирішує проблему, тому що точка перезапуску залишилася в конфізі. І ось це вже зовсім інший клас атаки на ланцюжок постачання.
Я такі речі завжди перевіряю з позиції практичної AI integration, а не лише security-теорії. Якщо в команди Claude Code бере участь у генерації, рефакторингу чи внутрішніх AI automation сценаріях, компрометація перетворюється не просто на зараження машини, а на постійний доступ до робочого циклу розробника.
Що тут особливо неприємно: зловмисник не ламає екзотику, а використовує те, що й так вважається штатною функцією IDE. Це означає, що багато команд можуть тижнями шукати пакет, хоча реальний механізм виживання вже сидить у локальних налаштуваннях проєкту чи користувача.
Поки що публічних технічних деталей небагато, і з цим треба бути чесним. Але навіть без повного набору IOC картина зрозуміла: якщо npm-пакет колись модифікував ці файли, видалення залежності не дорівнює очищенню середовища.
Я б дивився мінімум на три речі: несподівані task entries у VS Code, підозрілі hooks у Claude Code та будь-які автозапуски, що з'явилися без явного рішення команди. Якщо у вас є шаблони репозиторіїв, налаштування devcontainer або bootstrap-скрипти, туди теж варто зазирнути.
Що це змінює для бізнесу та автоматизації
Перший наслідок банальний, але дорогий: довіру до AI developer tooling більше не можна будувати лише на списку залежностей. Потрібен контроль конфігів і post-install поведінки, інакше AI implementation у розробці стає зайвою точкою входу.
Друге: програють команди, де IDE та агентні інструменти підключені без базової політики hardening. Виграють ті, хто зберігає еталонні конфіги, перевіряє drift і відокремлює локальні експерименти від production-ланцюжка.
Ми в Nahornyi AI Lab якраз закриваємо такі стики між безпекою та automation with AI: де потрібен не красивий демо-агент, а нормальна AI architecture з перевіреними хуками, sandboxing та аудитом dev-процесу. Якщо у вас AI-інструменти вже вбудовані в розробку і хочеться зрозуміти, де там тихо може жити така зараза, давайте розберемо ваш workflow і зберемо AI automation без прихованих сюрпризів.