Каждый день в Telegram-канале - что нового в вайб-кодинге: инструменты, примеры, ошибки. Подпишись, чтобы быть в курсе.
Что случилось за две недели: 4 способа угнать ИИ-агента без единой строчки вредоносного кода
Формально это называется непрямой промпт-инъекцией (indirect prompt injection): вредоносная инструкция приходит не от тебя напрямую, а через данные, которые агент обрабатывает по ходу задачи - чужой README, текст ошибки, комментарий в GitHub, ответ от внешнего сервиса. Термин можешь забыть сразу после этого абзаца - дальше говорю обычными словами.
Четыре находки этого окна:
- Mozilla 0Din показала, как безобидный на вид репозиторий превращается в reverse shell.
- Исследователь Aonan Guan раскрыл технику «Comment and Control» - заголовок Pull Request угонял сразу три разных ИИ-агента.
- Tenet Security нашла способ подсунуть агенту фейковый отчёт об ошибке из Sentry вместо реального.
- Microsoft прямым текстом предупредила: описание MCP-инструмента управляет твоим агентом не хуже системного промпта.
Отдельно стоит история про GuardFall от Adversa AI - она не про Claude Code, но показывает, что проблема системная: 10 из 11 популярных open-source агентов пропускают опасные команды, замаскированные под безобидные.
Как README безобидного репозитория превращается в reverse shell?
Механика, которую 29 июня 2026 разобрал SecurityWeek, устроена так, что ни один слой по отдельности не выглядит подозрительно:
- Клонируешь на вид обычный репозиторий и просишь Claude Code его запустить.
- Репозиторий тянет за собой Python-пакет, который специально ломается при первом использовании.
- Текст ошибки вежливо подсказывает команду-«починку»:
python3 -m axiom init. - Команда
initзапускаетsetup.sh. - Скрипт обращается к DNS-записи типа TXT (обычно там хранят служебные пометки о домене, но поле принимает любой текст) - атакующий кладёт туда закодированную в base64 команду (это просто способ превратить любые данные в обычный текст без пробелов и спецсимволов) и пайпит её прямо в bash.
- Значение DNS-записи можно менять в любой момент - получаешь интерактивный reverse shell с правами твоего пользователя и доступом ко всем секретам на машине.
Reverse shell отделён от всего, что Claude Code реально оценивал, тремя шагами косвенности: доверенное сообщение об ошибке, скрипт, который просто забрал значение, и DNS-запись, которую никто не увидел.
Статические сканеры тут бессильны по той же причине: обычный DNS-запрос, обычный base64, обычная обработка ошибки установки - каждый шаг сам по себе банален. Важная оговорка: 0Din прямо пишет, что это proof-of-concept, зафиксированных атак в реальном мире пока нет. Но исследователи предупреждают, что распространять такие репозитории можно как угодно - через фейковые вакансии, обзоры, посты в блогах, личные сообщения.
Как заголовок Pull Request угнал сразу три разных ИИ-агента?
Ядро проблемы Aonan Guan формулирует так:
Заголовок Pull Request подставлялся прямо в промпт агента без какой-либо очистки от инструкций.
Три вендора закрывали одну и ту же дыру по-разному - и это хорошая иллюстрация того, что «мы используем закрытый инструмент, значит нас это не касается» не работает:
| Агент | Как заходила атака | Что утекало | Статус на сегодня |
|---|---|---|---|
| Claude Code Security Review | заголовок PR интерполировался прямо в системный промпт без очистки | ANTHROPIC_API_KEY, GITHUB_TOKEN | Пофикшено, CVSS снижен с 9.4 до 0 (20 апреля 2026) |
| Gemini CLI Action | поддельная секция «Trusted Content» в комментарии обходила защитные инструкции | GEMINI_API_KEY | Google добавил отдельные guardrail-промпты в системный промпт |
| GitHub Copilot Agent | payload прятался в невидимом HTML-комментарии markdown | GITHUB_COPILOT_API_TOKEN, COPILOT_JOB_NONCE | GitHub считает архитектурным ограничением, не багом |
Между первыми и последними отчётами этого цикла раскрытия легло почти 5 месяцев (первый репорт по Claude Code - 17 октября 2025, последнее закрытие бага у GitHub Copilot - 9 марта 2026) - дыра в Claude Code давно закрыта, это свежий разбор уже завершённой истории. Ценность для тебя - в самой схеме атаки: непроверенные данные из GitHub попадают в агента, агент выполняет команды, секреты утекают через тот же GitHub, внешний сервер атакующему вообще не нужен.
Два разбора - и уже понятен паттерн: точечно закрывать каждую следующую находку не вариант, дыры такого рода всплывают каждые две недели. Явно прописать правила безопасности в CLAUDE.md и settings.json вместо того, чтобы держать их в голове, - это и есть часть контекст-инжиниринга: заданное один раз работает при каждой новой сессии Claude Code само, без напоминаний. На практикуме за 3 эфира собираешь все три кита: ИИ-клон + Второй мозг + Контекст-инжиниринг - именно эта связка превращает Claude Code из исполнителя, который доверяет всему подряд, в агента с явными правилами.
Может ли фейковый отчёт об ошибке из Sentry захватить твоего агента?
Атака не требует ничего, кроме DSN-ключа Sentry - публичного идентификатора, который у многих проектов лежит прямо в клиентском коде:
Отправить сфабрикованное событие об ошибке в endpoint приёма Sentry можно без какой-либо аутентификации, кроме самого DSN. Атакующий полностью контролирует содержимое события.
Дальше механика простая: разработчик просит агента разобрать открытые ошибки из Sentry, агент запрашивает их через MCP-сервер, получает вредоносное событие вперемешку с настоящими и читает встроенную в него команду как доверенную инструкцию по устранению ошибки - потому что формально это ровно та задача, о которой его попросили.
Цифры у Tenet Security точные и проверяемые: пассивная разведка нашла 2 388 организаций с рабочими, доступными для инъекции DSN-ключами, 71 из них входит в top-1M самых посещаемых доменов по Tranco. В контролируемых волнах тестирования больше 100 связок агент+модель среагировали на подставное событие - включая Claude Code, Cursor и Codex - success rate 85%.
Такая атака не оставляет следов ни в EDR, ни в WAF, ни в файрволе: атакующий вообще не касается инфраструктуры жертвы. Агент честно делает то, о чём его попросили - просто саму задачу ему незаметно подменили.
Почему описание MCP-инструмента так же опасно, как системный промпт?
Формулировка Microsoft - самая точная из всех, что я нашёл на эту тему:
Уязвимость не в какой-то одной системе - она в границе доверия между системами.
Первым эту технику - назвали её tool poisoning - показала Invariant Labs ещё в апреле 2025: спрятала инструкцию в описание безобидного инструмента-калькулятора и заставила редактор Cursor прочитать личный SSH-ключ пользователя и отправить его наружу. Microsoft в июньском блоге ссылается на эту находку как на первоисточник паттерна, который к 2026 году распространился на растущий список корпоративных агентов.
Академический бенчмарк MCPTox (arXiv 2508.14925) прогнал этот сценарий на 20 моделях. Здесь важна точность: средний показатель успешной атаки по всем моделям - 36,5%. Максимум показала o1-mini - 72,8%. Именно эта цифра обычно кочует по пересказам, хотя описывает только одну, самую уязвимую модель.
Claude 3.7 Sonnet вышла лучшей по устойчивости в этом тесте, но и у неё отказ выполнять отравленную инструкцию срабатывал меньше чем в 3% случаев - устойчивость даже лучшей модели держится скорее на везении, чем на защите. Контр-интуитивный вывод бенчмарка: чем точнее модель следует инструкциям, тем хуже она отличает легитимную команду от команды, спрятанной в метаданных - сила модели работает против неё же.
Что общего у всех этих атак - и почему антивирус тут бессилен?
История с GuardFall от Adversa AI (30 июня 2026) показывает ту же болезнь под новым углом - слабое место тут в самом способе, которым агент передаёт команды в bash. Формулировка Adversa AI бьёт точно в суть проблемы:
Агент, который может выполнять произвольные команды shell на машине оператора под контролем регулярного выражения над строкой, которую сгенерировала модель, - это не защита. Она не срабатывает именно тогда, когда полностью включена и правильно настроена, потому что сопоставление строк не может смоделировать то, что реально выполнит bash.
Важная точность: список из 11 протестированных агентов - это открытые проекты вроде opencode, Goose, Cline, Aider, OpenHands. Claude Code и Cursor в их выборку не входили - это не значит, что они автоматически защищены, это значит, что конкретно это исследование про другой класс инструментов. Из 11 агентов 10 пропускают опасные команды хотя бы одним из четырёх способов - у каждого свой трюк с синтаксисом bash (лишние кавычки, служебные переменные, вложенные команды, base64-пайпинг), из-за которого простой фильтр по регулярному выражению видит безобидную строку, а сам bash - деструктивную команду. Только один агент, Continue, реализовал защиту правильно.
Вывод один на все четыре находки: полагаться на то, что «код выглядит нормально», нельзя в принципе - каждый отдельный шаг атаки и правда безобиден. Работает только один подход: ограничить то, что агент физически способен сделать, даже если его уже обманули.
Что Claude Code уже умеет сам - и почему этого мало?
Anthropic прямо признаёт проблему в своей документации, а не прячет её:
Промпт-инъекция - это техника, при которой атакующий пытается переопределить или изменить инструкции ИИ-ассистента, вставляя вредоносный текст. Claude Code включает несколько защит от таких атак.
Из документации: агент анализирует запрос целиком на подозрительные инструкции, не одобряет curl и wget автоматически, держит веб-контент в отдельном контекстном окне, чтобы он не подмешивался в основной, и требует подтверждения доверия при первом запуске в новой кодовой базе или подключении нового MCP-сервера.
Но есть жёсткая оговорка, которую Anthropic формулирует без обиняков:
Режим bypassPermissions не даёт никакой защиты от промпт-инъекции или непреднамеренных действий.
Если ты хоть раз в раздражении запускал Claude Code с --dangerously-skip-permissions, чтобы он «не доставал вопросами» - именно в этот момент ты выключил все механизмы, которые могли бы остановить ровно те четыре атаки, что разобраны выше. Я держу этот флаг выключенным сознательно, даже когда Claude Code переспрашивает на десятый раз подряд за сессию - раздражает, но именно эти вопросы и есть граница между «агент прочитал подозрительный текст» и «агент его выполнил». Разумная связка для непрограммиста - обычный режим разрешений (default или acceptEdits) плюс включённый sandbox: обычные правки файлов идут без лишних вопросов, а команды в терминале физически не могут выйти за пределы песочницы, даже если агента обманули.
Как включить sandbox-режим и закрыть дыру, которую он не закрывает по умолчанию?
Включить на постоянной основе для всех проектов - одна правка ~/.claude/settings.json:
{
"sandbox": { "enabled": true }
}По умолчанию sandbox-команды пишут только в рабочую папку проекта и временную папку сессии, а сетевой доступ идёт через прокси - ни один домен не разрешён заранее, при первом обращении к новому домену Claude Code спросит подтверждение. Anthropic указывает, что это резко сокращает число вопросов о разрешениях - на 84% по внутренним замерам компании, потому что sandbox сам решает часть безопасных случаев вместо того, чтобы каждый раз спрашивать тебя.
Дыра, о которой молчит стандартная настройка: sandbox по умолчанию ограничивает запись, но не запрещает чтение файлов вроде ~/.aws/credentials и ~/.ssh. Ровно эти файлы и переменные окружения были целью в разборах Mozilla 0Din и «Comment and Control» выше. Закрыть это - отдельный блок в том же файле:
{
"sandbox": {
"enabled": true,
"credentials": {
"files": [
{ "path": "~/.aws/credentials", "mode": "deny" },
{ "path": "~/.ssh", "mode": "deny" }
],
"envVars": [
{ "name": "GITHUB_TOKEN", "mode": "deny" },
{ "name": "NPM_TOKEN", "mode": "deny" }
]
}
}
}Смысл в том, что даже если reverse shell из первого разбора всё-таки откроется внутри песочницы, эти переменные и файлы физически вычищаются из окружения процесса до его запуска - воровать становится нечего.
Какие permissions.deny поставить прямо сегодня?
Минимальный набор под непрограммиста, который закрывает основные цели всех четырёх атак сразу:
{
"permissions": {
"deny": [
"Read(~/.ssh/**)",
"Read(~/.aws/credentials)",
"Read(.env)",
"Bash(curl *)",
"Bash(wget *)",
"Bash(sudo *)"
]
}
}Из документации Claude Code: правила запрета всегда выигрывают у правил разрешения - значит, даже если ты (или сам агент) где-то в другом месте случайно разрешишь более широкий доступ, конкретный deny всё равно сработает первым. Это единственный уровень защиты в этом гайде, который не зависит от того, распознал ли агент атаку - он просто физически не может выполнить запрещённое действие.
Отдельно у Claude Code есть режим auto, где действия перед выполнением проверяет отдельная модель-классификатор - не та же самая, что ведёт диалог с тобой. По умолчанию она блокирует, среди прочего, ровно паттерн «скачать код и сразу его выполнить» (curl | bash) - то есть именно то, чем заканчивается атака Mozilla 0Din. Anthropic прямо предупреждает, что это исследовательский режим, который снижает число вопросов, но не гарантирует безопасность сам по себе - относись к нему как к дополнительному слою, не как к замене sandbox и permissions.deny.
Как проверить репозиторий и MCP-сервер перед тем, как доверить их агенту?
По репозиториям - короткий чек перед тем, как отдавать их агенту:
- Не переходи сразу к установке по ссылке из письма, поста или обзора с незнакомого источника - именно так, по предупреждению 0Din, такие репозитории и распространяются.
- Если при установке появляется ошибка с инструкцией «запусти команду X, чтобы исправить» - прочитай, что X реально делает, прежде чем разрешать Claude Code её выполнить. Инструкция из разбора выше выглядела как совершенно рутинная - в этом и был расчёт.
- Смотри на возраст репозитория и историю коммитов, а не только на число звёзд - свежесозданные репозитории со звёздами легко накрутить специально под такую атаку.
- Если репозиторий незнакомый - запускай установку в виртуальной машине, а не на рабочей машине с реальными ключами. Это прямая рекомендация самой Anthropic для работы с внешними сервисами.
По MCP-серверам позиция Anthropic сформулирована открыто:
Мы советуем писать собственные MCP-серверы или использовать серверы от провайдеров, которым вы доверяете. Anthropic проверяет коннекторы по своим критериям листинга перед добавлением в каталог, но не проводит security-аудит и не управляет ни одним MCP-сервером.
Это значит, что ответственность за проверку стороннего MCP-сервера лежит на тебе, а не на площадке, откуда ты его поставил. Отдельные команды - в основном security-стартапы - уже делают под это инструменты: сканеры конфигурации MCP на предмет отравленных описаний, «пиннинг» инструмента, при котором хэш описания сохраняется при первой установке и любое изменение задним числом сигнализирует тревогу. Технологии молодые, полагаться на них как на единственную защиту рано - но держать в поле зрения стоит, особенно если ты подключаешь MCP-серверы к продакшену.
7 правил защиты: чек-лист на сегодня
- Включи sandbox-режим (
/sandboxили"sandbox": {"enabled": true}в~/.claude/settings.json) и добавь блокcredentials, закрывающий чтение~/.sshи~/.aws/credentials. - Добавь
permissions.denyна чтение секретных файлов и на опасные bash-команды (curl,wget,sudo) - запрет всегда побеждает разрешение. - Никогда не запускай
--dangerously-skip-permissionsна чужом или непроверенном коде - это выключает вообще все защиты разом, включая ту, что могла бы остановить ровно эти атаки. - Не разрешай Claude Code автоматически выполнять «команду-починку» из текста ошибки - сначала прочитай, что она реально делает.
- Ставь MCP-серверы только из источников, которым доверяешь, и держи в голове, что Anthropic их не проверяет на безопасность за тебя.
- Разделяй сессии по правам: одна работает с твоими личными данными и не видит внешние данные, вторая разбирает чужие письма/репозитории/тикеты, но не имеет доступа к секретам, третья публикует наружу - и только то, что подтвердил лично ты. Я у себя в проектах держу это строго: сессия с доступом к платёжным ключам никогда не читает произвольные внешние тикеты и репозитории, а сессия, которая парсит чужой код, вообще не видит секретов. Не смешивай эти роли в одном чате.
- Держи Claude Code и подключённые сценарии автоматизации обновлёнными - большая часть разобранных здесь дыр к моменту публикации гайда уже закрыта патчами, а новые закрываются похожим образом.
Что дальше
Ни один из этих слоёв не работает как гарантия - Anthropic сама честно пишет, что ни одна защита не даёт полного иммунитета. Я не жду от Claude Code, что он сам распознает подвох в тексте ошибки или в комментарии к issue - для меня sandbox и permissions.deny встроены в то, как я вообще держу контекст проекта: что агент видит, чему он доверяет по умолчанию, и что происходит, когда он ошибается.
Источники
- SecurityWeek - New Attack Abuses Claude Code and Harmless-Looking Repositories to Hijack Developer Machines
- Aonan Guan - Comment and Control: Prompt Injection to Credential Theft in Claude Code, Gemini CLI, and GitHub Copilot Agent
- SecurityWeek - Claude Code, Gemini CLI, GitHub Copilot Agents Vulnerable to Prompt Injection via Comments
- Tenet Security - Agentjacking: Coding Agents With Fake Sentry Errors
- Microsoft Security Blog - Securing AI Agents: AI Tools Move From Reading to Acting
- Adversa AI - Open-Source AI Coding Agents Shell Injection Vulnerability (GuardFall)
- MCPTox: A Benchmark for Tool Poisoning Attack on Real-World MCP Servers - arXiv:2508.14925
- Claude Code Docs - Permission Modes
- Anthropic Engineering - Claude Code Sandboxing
- Claude Code Docs - Permissions
- Claude Code Docs - Security Best Practices
- Claude Code Docs - Model Context Protocol (MCP)
- Разбор родственной уязвимости в Claude Code GitHub Action
- Как настроить Claude Code, чтобы он не сломал твой проект ночью
- MCP-серверы Claude Code: 7 готовых связок и пошаговая установка
- Безопасность вайб-кодинга: как не дать взломать приложение на ИИ
Полная схема по вайб-кодингу за вечер: ИИ-клон + Второй мозг + Контекст-инжиниринг. 3 эфира. Записи остаются у тебя.
Новые материалы - дайджестом, без спама
Гайды выходят регулярно. Подпишись, чтобы не пропускать: пришлю подборку в Telegram или на email. Раз в неделю или каждый день - выбираешь сам.

