Slopsquatting — это атака на цепочку поставок, при которой злоумышленник регистрирует на npm или PyPI пакет с именем, которое нейросеть просто придумала. Разработчик или AI-агент ставит его по совету модели, а получает чужой код на своей машине. В статье разберем, откуда берутся такие галлюцинации, сколько их реально в AI-коде и как проверить пакет за минуту до того, как набрать npm install.
Slopsquatting эксплуатирует склонность нейросетей выдумывать имена npm и PyPI пакетов: 19.7% рекомендаций из исследования USENIX Security 2025 оказались вымышленными. Кейс react-codeshift показал, как один такой пакет разошелся по 237 репозиториям без единой злой руки. Ниже — механика атаки, цифры и рабочий чек-лист проверки зависимостей.
Что такое slopsquatting и откуда взялось название?
Slopsquatting — портманто из "AI slop" (мусорный AI-контент) и "typosquatting". Термин ввел Сет Ларсон, security developer-in-residence Python Software Foundation.
Механика простая. AI-инструмент для кода советует установить библиотеку, которой никогда не было в реестре. Атакующий регистрирует это имя первым и кладет туда вредоносный payload. Дальше он просто ждет, пока следующий разработчик или агент выполнит установку.
В отличие от классического тайпсквоттинга slopsquatting не строится на опечатке. Атакующий не делает reqeusts из requests, он берет ровно то имя, которое модель предложит снова и снова. Из-за этого фильтры схожести имен, которые реестры годами затачивали против опечаток, тут попросту не срабатывают — новое имя не похоже ни на что существующее, поэтому не вызывает тревоги при регистрации.
Мы в VibeCoderz регулярно тестируем Cursor, Windsurf и Claude Code для каталога вайбкодинг-инструментов, и вопрос "а точно ли эта библиотека существует" за последний год стал таким же рутинным, как проверка синтаксиса.
Почему нейросеть выдумывает npm пакет, которого нет?
Модель не врет намеренно, она статистически достраивает правдоподобное имя по паттернам из обучающих данных, когда точного совпадения не находит.
Исследователи из USENIX Security 2025 разобрали галлюцинации на три типа: 51% — чистая выдумка без реального прототипа, 38% — конфляция, то есть склейка двух настоящих пакетов в одно правдоподобное имя, и 13% — вариации, близкие к опечаткам. Именно конфляция дает самые опасные имена: они звучат как логичный продукт двух известных библиотек, а не как случайный набор букв.
Открытые модели галлюцинируют заметно чаще коммерческих. В том же исследовании open-source модели ошибались в среднем в 21.7% случаев, у коммерческих моделей показатель был на уровне 5.2%. У некоторых версий CodeLlama доля доходила до трети всех рекомендаций. При этом хорошая новость есть: часть моделей, включая GPT-4 Turbo и DeepSeek, смогли сами распознать свою же выдумку с точностью выше 75%, если их попросить перепроверить ответ.
Насколько это массовая проблема на самом деле?
Больше 200 000 уникальных выдуманных имен пакетов зафиксировано в одном исследовании, а почти каждая пятая AI-рекомендация оказывается фантомом.
USENIX Security 2025 прогнали 16 моделей через 576 000 образцов кода и получили 19.7% галлюцинированных пакетов, всего 205 474 уникальных несуществующих имени. Отдельно проверили повторяемость: одинаковый промт запускали десять раз подряд, и 43% выдуманных имен всплывали при каждом повторе без исключений. Для атакующего это значит одно: не нужно гадать, достаточно прогнать популярную модель пару десятков раз и зарегистрировать то, что повторяется чаще всего.
| Показатель | Значение | Источник |
|---|---|---|
| Доля галлюцинированных пакетов | 19.7% из 576 000 образцов | USENIX Security 2025 |
| Уникальных выдуманных имен | 205 474 | USENIX Security 2025 |
| Повторяемость при 10 прогонах | 43% имен совпадают каждый раз | USENIX Security 2025 |
| Галлюцинации open-source моделей | 21.7% в среднем | USENIX Security 2025 |
| Галлюцинации коммерческих моделей | 5.2% в среднем | USENIX Security 2025 |
| Репозиториев заразил react-codeshift | 237 | Aikido Security, январь 2026 |
Свежая переоценка новых флагманских моделей ("The Range Shrinks, the Threat Remains", 2026) показала, что частота отдельной модели упала до 4.6-6.1%. Но нашлось 127 имен, которые независимо выдумали сразу пять разных моделей — 109 на PyPI и 18 на npm. Для атакующего такое совпадение ценнее всего: один зарегистрированный пакет ловит пользователей сразу нескольких AI-инструментов.
Как react-codeshift заразил 237 репозиториев?
В январе 2026 исследователь Aikido Charlie Eriksen нашел на GitHub несуществующий npm пакет react-codeshift, который AI-агенты пытались установить каждый день, и зарегистрировал имя раньше злоумышленников.
История началась с обычного вайбкодинга. Кто-то в октябре 2025 собрал набор agent skills для миграции проектов между фреймворками. Внутри было два скилла, которые вызывали через npx пакет react-codeshift — имя-гибрид из двух реальных инструментов, jscodeshift и react-codemod. Пакета никогда не существовало, никто его не публиковал.
Файлы со скиллами разошлись по форкам, их переводили на японский, где-то заменили npx на bunx. К моменту, когда Eriksen обнаружил проблему, имя фигурировало в 237 репозиториях, и агенты продолжали дергать npm install по одной-четыре загрузки в день. Он зарегистрировал пакет сам, просто чтобы никто не успел раньше. Атаки не случилось только потому, что первым оказался исследователь, а не злоумышленник.
Похожий случай раньше произошел с huggingface-cli: модели вместо правильной команды pip install -U "huggingface_hub[cli]" упорно советовали короткое несуществующее имя. Исследователь Bar Lanyado зарегистрировал его как пустышку и за три месяца получил больше 30 000 честных загрузок, включая копипаст в публичном README Alibaba.
Чем это опасно для вайбкодеров в Cursor, Windsurf и Claude Code?
Агентные IDE ставят зависимости автоматически, без паузы на человеческое ревью, поэтому одна галлюцинация превращается в установку без единого клика подтверждения.
Раньше слопсквоттинг был социальной инженерией: нужно было, чтобы разработчик поверил подсказке и сам вбил npm install. Сейчас Cursor, Windsurf, GitHub Copilot и Claude Code умеют читать задачу, писать код, добавлять зависимость и запускать её сами. Если агент работает в режиме автоматического подтверждения команд, между галлюцинацией модели и выполнением вредоносного постинсталл-скрипта не остается ни одного человека.
Максим: «GoBanana мы собрали за 3 часа после выхода модели, и это принесло 12 млн рублей без единого рубля на рекламу. Но чем быстрее катишь фичу через агента, тем легче пропустить момент, когда он сам добавил зависимость, которой нет в природе. У нас теперь ручная проверка новых пакетов — отдельный пункт чеклиста перед деплоем, а не что-то по желанию.»
Для вайбкодеров, которые собирают MVP за вечер, это не абстрактная угроза, а конкретный шаг в процессе. Один пропущенный npm install с чужим payload способен слить переменные окружения или токены доступа раньше, чем продукт увидит первого пользователя.
Как проверить пакет перед npm install?
Перед установкой любого нового имени стоит проверить его существование в реестре, дату публикации, число загрузок и автора — это занимает меньше минуты и снимает большую часть риска.
Пять шагов, которые стоит превратить в привычку:
- Открыть
npm view имя-пакетав терминале до установки. Если реестр вернет ошибку 404, пакета просто нет, и нейросеть его выдумала. - Зайти на npmjs.com или pypi.org и посмотреть карточку пакета: дату первой публикации, число еженедельных загрузок, наличие README и репозитория на GitHub.
- Свежая регистрация без истории, с горсткой загрузок и без внятного автора — сигнал остановиться и погуглить название отдельно от контекста нейросети.
- Сверить название с официальной документацией технологии, если речь про известный фреймворк. Конфляция вроде react-codeshift обычно звучит правдоподобно именно потому, что мешает два настоящих имени.
- Для агентных IDE отключить автоматическое подтверждение установки пакетов и включить ручное одобрение каждой новой зависимости в настройках агента.
Какие инструменты защищают от slopsquatting?
Специализированные SCA-сканеры и package-firewall решения ловят подозрительные пакеты по возрасту, числу загрузок и паттернам имен до того, как код попадет в сборку.
Ручная проверка хорошо работает на старте, но не масштабируется на команду или CI/CD. Здесь на сцену выходят инструменты для анализа состава ПО.
| Инструмент | Что делает | Когда подключать |
|---|---|---|
| npm audit signatures | Проверяет криптографические подписи provenance у пакетов npm | В каждый CI-пайплайн по умолчанию |
| Socket.dev | Сканирует зависимости на подозрительные паттерны имен и поведение постинсталл-скриптов | Для команд с активным AI-кодогенерацией |
| Aikido SafeChain | Перехватывает команду установки пакета и сверяет её с threat intelligence до загрузки | Для агентных IDE с автоустановкой |
| Snyk | Добавляет отдельную детекцию slopsquatting-паттернов: свежие даты, минимум загрузок | Для крупных монорепозиториев |
| Lock-файлы + npm ci | Фиксируют уже проверенные версии и блокируют подмену при повторной сборке | Всегда, но не заменяет проверку при первой установке |
Ни один из инструментов не закрывает вопрос полностью в одиночку. Аудит USENIX и разборы Aikido сходятся в одном: работает только связка из нескольких слоев — сканер плюс ручное ревью плюс ограничение прав агента на автоустановку.
Что делать, если пакет уже установлен?
Если выдуманное имя уже стоит в node_modules, нужно убрать его, проверить постинсталл-скрипты и сменить все секреты, которые могли быть доступны системе во время установки.
Порядок действий такой: удалить пакет из package.json и node_modules, посмотреть package-lock.json на предмет странных postinstall или preinstall хуков, прогнать проект через антивирус или SCA-сканер и ротировать токены, API-ключи и переменные окружения, к которым процесс установки теоретически имел доступ. Даже если payload не сработал явно, разумнее считать секреты скомпрометированными и поменять их, чем надеяться на удачу.
Отдельно стоит проверить agent skill файлы и общие шаблоны промтов в команде. Кейс react-codeshift разошелся именно через копипаст скиллов между репозиториями, а не через прямую атаку — значит зараженная инструкция может тихо сидеть в шаблоне, которым пользуется вся команда.
Итог: как не попасться на slopsquatting в 2026 году
По состоянию на июль 2026 года slopsquatting перестал быть теоретическим риском: реальные кейсы вроде react-codeshift и huggingface-cli накопили десятки тысяч установок. Главная защита та же, что и для любой другой цепочки поставок: не доверять имени пакета только потому, что его предложила уверенная в себе модель. Проверка занимает минуту, а откат последствий заражения — недели.
Если собираете продукт на связке Cursor, Windsurf или Claude Code и хотите выстроить процесс безопасной работы с зависимостями с нуля, посмотрите обзоры инструментов в каталоге AI IDE или запишитесь на консультацию к Максиму: он разберет ваш конкретный стек и процесс деплоя.
Глоссарий
- Slopsquatting — атака, при которой злоумышленник регистрирует в npm или PyPI пакет с именем, придуманным нейросетью.
- Тайпсквоттинг — классическая атака на опечатке в названии пакета, например reqeusts вместо requests.
- Halлюцинация модели — уверенный, но фактически неверный ответ нейросети, в данном случае несуществующее имя библиотеки.
- Конфляция — склейка двух реальных названий в одно правдоподобное несуществующее имя.
- SCA (Software Composition Analysis) — класс инструментов, которые анализируют состав зависимостей проекта на риски.
- Agent skill — файл с инструкциями и примерами кода, который AI-агент подключает автоматически при совпадении ключевых слов в задаче.
- Package provenance — криптографическая подпись, подтверждающая происхождение пакета в реестре npm.
Частые вопросы про slopsquatting
Что такое slopsquatting простыми словами? Атака, при которой злоумышленник регистрирует пакет с именем, которое придумала нейросеть, и кладет туда вредоносный код вместо ожидаемой библиотеки.
Чем slopsquatting отличается от обычного тайпсквоттинга? Тайпсквоттинг рассчитан на опечатку человека. Slopsquatting использует имя, которое нейросеть выдумала с нуля, поэтому фильтры схожести в реестрах его не ловят.
Как часто нейросети выдумывают пакеты? По данным USENIX Security 2025, почти каждая пятая рекомендация пакета в AI-коде — 19.7% из 576 000 образцов — оказалась несуществующей.
Можно ли доверять коду из Cursor, Windsurf или Claude Code? Логике кода — да, после ревью. Каждую новую зависимость все равно стоит проверять вручную или сканером до установки, независимо от инструмента.
Как проверить npm пакет перед установкой? Выполнить npm view имя-пакета, открыть карточку на npmjs.com и посмотреть дату публикации, число загрузок и автора.
Что делать, если уже установил несуществующий пакет? Удалить его из node_modules и package.json, проверить postinstall-скрипты, просканировать проект и сменить токены и переменные окружения.
Спасают ли lock-файлы от slopsquatting? Они фиксируют уже проверенные версии и защищают повторную сборку, но не мешают первой установке выдуманного имени — нужна проверка до неё.
Обновлено: июль 2026. Данные о ценах и функциях AI-инструментов актуальны на момент публикации и могут измениться.