Skip to main content
cybersecuritynpmclaude-code

Вредонос в AI-инструментах переживает uninstall

Появился тревожный кейс: вредоносный npm-пакет не просто заражает среду, а прописывает выживание через .claude/settings.json и .vscode/tasks.json. Для бизнеса это риск тихого компромета dev-инструментов, особенно там, где AI integration и AI automation уже встроены в разработку.

Технический контекст

Я зацепился за эту историю не из-за очередного 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-скрипты, туда тоже стоит заглянуть.

Что это меняет для бизнеса и автоматизации

Первое последствие банальное, но дорогое: trust к 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 без скрытых сюрпризов.

Задача защиты сред AI-разработки от таких стойких угроз имеет первостепенное значение. Ранее мы уже исследовали, как AI-агенты могут обходить песочницы с помощью цепочек команд, предоставляя ключевые выводы о связанных рисках и необходимых механизмах контроля для безопасного выполнения AI.

Поделиться статьёй