Slopsquatting — принципиально новый тип атаки на цепочку поставок программного обеспечения. AI-модели стабильно галлюцинируют одни и те же имена пакетов, а злоумышленник может зарегистрировать эти «фантомные» имена и наполнить их малварью. По данным крупнейшего исследования (USENIX Security 2025), 19,7% ссылок на пакеты в сгенерированном LLM коде указывают на несуществующие пакеты: от 5,2% у коммерческих моделей до 21,7% у открытых — и каждое такое фантомное имя может стать вектором атаки.
Термин «slopsquatting» предложил в апреле 2025 года Сет Ларсон (Seth Larson), инженер по безопасности Python Software Foundation, а популяризовал разработчик Эндрю Несбитт (Andrew Nesbitt). Слово образовано от «slop» — жаргонного обозначения некачественного или ошибочного AI-контента — и «squatting» — техники захвата имён (по аналогии с typosquatting, когда регистрируются домены с опечатками). Само явление описано раньше: ещё в 2023 году исследователь Бар Ланьядо (Bar Lanyado) продемонстрировал, что галлюцинированные имена пакетов можно превратить в вектор атаки. Slopsquatting объединяет две проблемы: воспроизводимость AI-галлюцинаций и открытость реестров пакетов для регистрации.
В отличие от typosquatting, где злоумышленник рассчитывает на опечатки разработчика, slopsquatting эксплуатирует ошибки AI-модели. Жертва не делает опечатку — она следует рекомендации инструмента, которому доверяет. Это делает атаку особенно эффективной: разработчик не подозревает, что рекомендованный пакет может быть вредоносным, потому что он получил совет от «умного» инструмента.
Механизм slopsquatting-атаки состоит из нескольких этапов, каждый из которых элегантно прост:
Ключевая особенность: значительная часть галлюцинаций LLM воспроизводима. В эксперименте Spracklen et al. (USENIX Security 2025) 43% фантомных имён повторялись во всех десяти повторных одинаковых запросах, а 58% — более одного раза. Это означает, что злоумышленник может заранее определить, какие имена модель будет рекомендовать жертвам снова и снова.
Исследования показывают, что в среднем 19,7% ссылок на пакеты в сгенерированном LLM коде указывают на несуществующие пакеты: около 5,2% у коммерческих моделей и 21,7% у открытых. Точный процент зависит от модели, языка программирования и формулировки запроса, но даже 5% — это колоссальная поверхность атаки, учитывая масштабы использования AI-инструментов для разработки.
Если предположить, что миллионы разработчиков ежедневно используют AI для написания кода, и в среднем каждая пятая сгенерированная ссылка на пакет — фантом, речь идёт о сотнях тысяч потенциальных установок несуществующих (а значит — доступных для захвата) зависимостей ежемесячно. При этом каждая такая установка может привести к компрометации не только машины разработчика, но и продакшн-системы, в которую попадёт заражённая зависимость.
Исследователи из Университета Техаса в Сан-Антонио, Университета Оклахомы и Virginia Tech (Spracklen et al., arXiv:2406.10279, USENIX Security 2025) провели масштабный эксперимент: они сгенерировали 576 000 образцов кода с помощью 16 различных LLM. Модели выдали около 2,23 млн ссылок на пакеты, из которых 440 445 (19,7%) оказались галлюцинациями; уникальных фантомных имён среди них — 205 474. Иными словами, фантомом оказалась примерно каждая пятая рекомендованная ссылка.
Публично подтверждённых slopsquatting-пакетов с вредоносной нагрузкой и реальными жертвами пока не зафиксировано — известные случаи оказались исследовательскими демонстрациями. Но арсенал полезной нагрузки хорошо известен по соседней технике — typosquatting, где вредоносные пакеты в NPM и PyPI находят регулярно. Slopsquatting-пакет может нести те же типы нагрузки:
Инфостилеры. Самый распространённый тип: при установке пакет собирает пароли из браузеров, токены аутентификации, SSH-ключи, содержимое файлов .env и ~/.aws/credentials, и отправляет их на сервер злоумышленника. Инфостилер маскируется под легитимный код — например, как «телеметрия» или «проверка обновлений».
Бэкдоры. Пакет устанавливает обратное соединение (reverse shell) к серверу злоумышленника, давая ему постоянный доступ к машине разработчика. Бэкдор может активироваться не сразу, а через определённое время или по команде, что затрудняет обнаружение.
Криптомайнеры. Менее опасный, но более заметный тип: пакет запускает майнинг криптовалюты в фоновом режиме, потребляя ресурсы процессора и видеокарты. Криптомайнеры обычно обнаруживаются быстрее из-за заметного влияния на производительность.
Загрузчики. Пакет сам по себе безвреден, но скачивает и выполняет дополнительную полезную нагрузку с внешнего сервера. Это позволяет злоумышленнику обходить статический анализ: при проверке пакет выглядит чистым, а вредоносный код доставляется позже.
Slopsquatting — не чисто теоретическая угроза: работоспособность вектора уже подтверждена экспериментами. Важная оговорка: в обоих известных случаях фантомные имена первыми заняли исследователи, а не злоумышленники.
huggingface-cli. Исследователь Бар Ланьядо (Bar Lanyado) из Lasso Security заметил, что LLM-модели стабильно рекомендуют pip install huggingface-cli для работы с Hugging Face Hub, хотя официальная установка выглядит иначе (pip install -U "huggingface_hub[cli]"). В конце 2023 года он зарегистрировал фантомное имя на PyPI и загрузил под ним пустой безвредный пакет — исследовательский proof-of-concept. За три месяца пустышку скачали более 30 000 раз, а команда установки успела попасть в README публичного репозитория Alibaba. Вредоносной нагрузки в пакете не было — но окажись на месте исследователя злоумышленник, счёт потенциальных жертв шёл бы на тысячи.
react-codeshift. Аналогичная история в экосистеме NPM. В январе 2026 года исследователь Чарли Эриксен (Charlie Eriksen) из Aikido Security обнаружил, что LLM-модели рекомендуют несуществующий пакет react-codeshift — «склейку» имён реальных инструментов jscodeshift и react-codemod. К этому моменту фантомное имя успело разойтись по 237 репозиториям на GitHub — через сгенерированные AI-инструкции, форки и переводы. Эриксен зарегистрировал имя защитно, раньше злоумышленников; после регистрации пакет продолжал получать по несколько скачиваний в день — AI-агенты выполняли инструкции по установке без участия человека.
Оба эксперимента показывают: вектор работает в масштабе. Десятки тысяч установок пакет получил только потому, что его рекомендовал AI, — и лишь по счастливому стечению обстоятельств оба имени первыми заняли исследователи, а не атакующие.
Если для человека-разработчика slopsquatting — серьёзная, но потенциально обнаружимая угроза (можно заметить незнакомый пакет, проверить его на NPM), то для автономных AI-агентов это катастрофический риск.
Современные AI-агенты (Cursor Agent, Devin, Claude Code, GitHub Copilot Workspace) могут самостоятельно устанавливать зависимости как часть выполнения задачи. Агент решает, что для решения задачи нужен пакет X, выполняет npm install X или pip install X, и продолжает работу. Человек может вообще не участвовать в этом процессе.
Это создаёт полностью автоматизированную цепочку атаки:
Ни на одном этапе человек не принимает решения и не имеет возможности заметить атаку. Это делает slopsquatting потенциально одной из самых масштабируемых атак на цепочку поставок ПО.
Slopsquatting идеально подходит для автоматизации. Злоумышленник может создать пайплайн, который:
Весь процесс может быть автоматизирован от начала до конца. Стоимость атаки минимальна: API-вызовы к LLM дешевы, регистрация пакетов бесплатна, а потенциальная отдача — доступ к тысячам машин разработчиков — несоизмеримо выше.
Традиционные инструменты анализа состава ПО (Software Composition Analysis, SCA) — Snyk, Dependabot, Renovate — проверяют известные уязвимости в известных пакетах. Они работают с базой данных CVE и advisory. Но slopsquatting-пакеты — это не «известные пакеты с уязвимостями». Это новые пакеты, зарегистрированные злоумышленником, которые пока не находятся ни в одной базе.
Для SCA-инструмента slopsquatting-пакет выглядит как легитимный: он зарегистрирован в реестре, имеет валидный package.json или setup.py, содержит работающий код. Вредоносная нагрузка может быть обфусцирована, закодирована в base64, или загружаться с внешнего сервера — всё это затрудняет статический анализ.
Новое поколение инструментов — Socket.dev, Phylum — анализирует поведение пакета при установке: сетевые подключения, доступ к файловой системе, выполнение shell-команд. Это более эффективный подход, но он тоже не идеален: продвинутые слоп-сквоттинг-пакеты могут использовать отложенную активацию или запускать вредоносный код только при определённых условиях.
До тех пор, пока индустрия не решит проблему на уровне инфраструктуры, каждый разработчик должен уметь выявлять потенциально вредоносные пакеты. Основные признаки:
postinstall в package.json или setup.py. Легитимные пакеты редко выполняют сложные действия при установке.Единственный надёжный способ защиты от slopsquatting на уровне организации — это allowlist (белый список) разрешённых пакетов. Вместо того чтобы пытаться обнаружить вредоносные пакеты (blocklist-подход), организация определяет список одобренных зависимостей и запрещает всё остальное.
Allowlist-подход требует начальных инвестиций: необходимо провести аудит текущих зависимостей, создать процесс одобрения новых пакетов, настроить инструменты для контроля. Но он фундаментально решает проблему: если пакет не в списке, он не будет установлен — независимо от того, рекомендует его AI или нет.
Для AI-агентов allowlist-подход критически важен. Если агент может устанавливать только пакеты из заранее одобренного списка, slopsquatting-атака становится невозможной. Агент может рекомендовать «фантомный» пакет, но система просто не позволит его установить.
Внедрение allowlist в организации — это не просто техническая мера. Это изменение культуры: от «устанавливаю что хочу» к «добавляю зависимости через процесс одобрения». Такой подход может замедлить начальную разработку, но он многократно окупается предотвращением инцидентов.
Slopsquatting будет только усиливаться по мере роста adoption AI-инструментов для разработки. Чем больше разработчиков и агентов полагаются на рекомендации LLM, тем выше отдача от slopsquatting-атак. Реестры пакетов (NPM, PyPI) пока не имеют эффективных механизмов противодействия, хотя дискуссия активно ведётся.
Возможные направления защиты на уровне инфраструктуры: LLM-провайдеры могут верифицировать рекомендуемые пакеты перед выдачей ответа; реестры могут ввести механизмы верификации для новых пакетов, имена которых похожи на распространённые галлюцинации; AI-IDE могут встраивать проверку пакетов перед установкой.
Пока эти меры не реализованы, ответственность за защиту лежит на разработчиках и организациях. Allowlist, проверка метаданных, SCA нового поколения, запрет автоматической установки — все эти меры должны стать стандартной практикой.