Как чужой репозиторий взламывает Claude Code в 2026: 7 правил защиты

Опубликовано 03.07.202617 мин чтенияСредний
Выделенный текст из репозитория деформируется в опасные команды, взламывающие терминал Claude Code.
Что узнаешь
  • Как README безобидного на вид репозитория превращается в reverse shell на твоей машине
  • Почему заголовок Pull Request или отчёт об ошибке из Sentry работает как команда для агента
  • Готовый settings.json, который закрывает Claude Code доступ к SSH-ключам и токенам
  • Почему --dangerously-skip-permissions выключает защиту именно от этой атаки
  • Чек-лист на 7 пунктов - что проверить перед тем как отдать Claude Code чужой код
Применить за 20 мин
Средний
6просмотров

Каждый день в Telegram-канале - что нового в вайб-кодинге: инструменты, примеры, ошибки. Подпишись, чтобы быть в курсе.

Что случилось за две недели: 4 способа угнать ИИ-агента без единой строчки вредоносного кода

Формально это называется непрямой промпт-инъекцией (indirect prompt injection): вредоносная инструкция приходит не от тебя напрямую, а через данные, которые агент обрабатывает по ходу задачи - чужой README, текст ошибки, комментарий в GitHub, ответ от внешнего сервиса. Термин можешь забыть сразу после этого абзаца - дальше говорю обычными словами.

Четыре находки этого окна:

  1. Mozilla 0Din показала, как безобидный на вид репозиторий превращается в reverse shell.
  2. Исследователь Aonan Guan раскрыл технику «Comment and Control» - заголовок Pull Request угонял сразу три разных ИИ-агента.
  3. Tenet Security нашла способ подсунуть агенту фейковый отчёт об ошибке из Sentry вместо реального.
  4. Microsoft прямым текстом предупредила: описание MCP-инструмента управляет твоим агентом не хуже системного промпта.

Отдельно стоит история про GuardFall от Adversa AI - она не про Claude Code, но показывает, что проблема системная: 10 из 11 популярных open-source агентов пропускают опасные команды, замаскированные под безобидные.

Как README безобидного репозитория превращается в reverse shell?

Механика, которую 29 июня 2026 разобрал SecurityWeek, устроена так, что ни один слой по отдельности не выглядит подозрительно:

  1. Клонируешь на вид обычный репозиторий и просишь Claude Code его запустить.
  2. Репозиторий тянет за собой Python-пакет, который специально ломается при первом использовании.
  3. Текст ошибки вежливо подсказывает команду-«починку»: python3 -m axiom init.
  4. Команда init запускает setup.sh.
  5. Скрипт обращается к DNS-записи типа TXT (обычно там хранят служебные пометки о домене, но поле принимает любой текст) - атакующий кладёт туда закодированную в base64 команду (это просто способ превратить любые данные в обычный текст без пробелов и спецсимволов) и пайпит её прямо в bash.
  6. Значение DNS-записи можно менять в любой момент - получаешь интерактивный reverse shell с правами твоего пользователя и доступом ко всем секретам на машине.

Reverse shell отделён от всего, что Claude Code реально оценивал, тремя шагами косвенности: доверенное сообщение об ошибке, скрипт, который просто забрал значение, и DNS-запись, которую никто не увидел.

- Исследователи Mozilla 0Din, https://www.securityweek.com/new-attack-abuses-claude-code-and-harmless-looking-repositories-to-hijack-developer-machines/

Статические сканеры тут бессильны по той же причине: обычный DNS-запрос, обычный base64, обычная обработка ошибки установки - каждый шаг сам по себе банален. Важная оговорка: 0Din прямо пишет, что это proof-of-concept, зафиксированных атак в реальном мире пока нет. Но исследователи предупреждают, что распространять такие репозитории можно как угодно - через фейковые вакансии, обзоры, посты в блогах, личные сообщения.

Как заголовок Pull Request угнал сразу три разных ИИ-агента?

Ядро проблемы Aonan Guan формулирует так:

Заголовок Pull Request подставлялся прямо в промпт агента без какой-либо очистки от инструкций.

- Aonan Guan, https://oddguan.com/blog/comment-and-control-prompt-injection-credential-theft-claude-code-gemini-cli-github-copilot/

Три вендора закрывали одну и ту же дыру по-разному - и это хорошая иллюстрация того, что «мы используем закрытый инструмент, значит нас это не касается» не работает:

АгентКак заходила атакаЧто утекалоСтатус на сегодня
Claude Code Security Reviewзаголовок PR интерполировался прямо в системный промпт без очисткиANTHROPIC_API_KEY, GITHUB_TOKENПофикшено, CVSS снижен с 9.4 до 0 (20 апреля 2026)
Gemini CLI Actionподдельная секция «Trusted Content» в комментарии обходила защитные инструкцииGEMINI_API_KEYGoogle добавил отдельные guardrail-промпты в системный промпт
GitHub Copilot Agentpayload прятался в невидимом HTML-комментарии markdownGITHUB_COPILOT_API_TOKEN, COPILOT_JOB_NONCEGitHub считает архитектурным ограничением, не багом

Между первыми и последними отчётами этого цикла раскрытия легло почти 5 месяцев (первый репорт по Claude Code - 17 октября 2025, последнее закрытие бага у GitHub Copilot - 9 марта 2026) - дыра в Claude Code давно закрыта, это свежий разбор уже завершённой истории. Ценность для тебя - в самой схеме атаки: непроверенные данные из GitHub попадают в агента, агент выполняет команды, секреты утекают через тот же GitHub, внешний сервер атакующему вообще не нужен.

Два разбора - и уже понятен паттерн: точечно закрывать каждую следующую находку не вариант, дыры такого рода всплывают каждые две недели. Явно прописать правила безопасности в CLAUDE.md и settings.json вместо того, чтобы держать их в голове, - это и есть часть контекст-инжиниринга: заданное один раз работает при каждой новой сессии Claude Code само, без напоминаний. На практикуме за 3 эфира собираешь все три кита: ИИ-клон + Второй мозг + Контекст-инжиниринг - именно эта связка превращает Claude Code из исполнителя, который доверяет всему подряд, в агента с явными правилами.

Практикум по вайб-кодингу
+Твой второй мозг
3 вечера - стек, метод, первый проект
Старт 14–16 июля  ·  2 000 ₽
Записаться →

Может ли фейковый отчёт об ошибке из Sentry захватить твоего агента?

Атака не требует ничего, кроме DSN-ключа Sentry - публичного идентификатора, который у многих проектов лежит прямо в клиентском коде:

Отправить сфабрикованное событие об ошибке в endpoint приёма Sentry можно без какой-либо аутентификации, кроме самого DSN. Атакующий полностью контролирует содержимое события.

- Tenet Security, https://tenetsecurity.ai/blog/agentjacking-coding-agents-with-fake-sentry-errors/

Дальше механика простая: разработчик просит агента разобрать открытые ошибки из Sentry, агент запрашивает их через MCP-сервер, получает вредоносное событие вперемешку с настоящими и читает встроенную в него команду как доверенную инструкцию по устранению ошибки - потому что формально это ровно та задача, о которой его попросили.

Цифры у Tenet Security точные и проверяемые: пассивная разведка нашла 2 388 организаций с рабочими, доступными для инъекции DSN-ключами, 71 из них входит в top-1M самых посещаемых доменов по Tranco. В контролируемых волнах тестирования больше 100 связок агент+модель среагировали на подставное событие - включая Claude Code, Cursor и Codex - success rate 85%.

Такая атака не оставляет следов ни в EDR, ни в WAF, ни в файрволе: атакующий вообще не касается инфраструктуры жертвы. Агент честно делает то, о чём его попросили - просто саму задачу ему незаметно подменили.

Почему описание MCP-инструмента так же опасно, как системный промпт?

Формулировка Microsoft - самая точная из всех, что я нашёл на эту тему:

Уязвимость не в какой-то одной системе - она в границе доверия между системами.

- Microsoft Security, https://www.microsoft.com/en-us/security/blog/2026/06/30/securing-ai-agents-ai-tools-move-from-reading-acting/

Первым эту технику - назвали её 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.

- Adversa AI, https://adversa.ai/blog/opensource-ai-coding-agents-shell-injection-vulnerability/

Важная точность: список из 11 протестированных агентов - это открытые проекты вроде opencode, Goose, Cline, Aider, OpenHands. Claude Code и Cursor в их выборку не входили - это не значит, что они автоматически защищены, это значит, что конкретно это исследование про другой класс инструментов. Из 11 агентов 10 пропускают опасные команды хотя бы одним из четырёх способов - у каждого свой трюк с синтаксисом bash (лишние кавычки, служебные переменные, вложенные команды, base64-пайпинг), из-за которого простой фильтр по регулярному выражению видит безобидную строку, а сам bash - деструктивную команду. Только один агент, Continue, реализовал защиту правильно.

Вывод один на все четыре находки: полагаться на то, что «код выглядит нормально», нельзя в принципе - каждый отдельный шаг атаки и правда безобиден. Работает только один подход: ограничить то, что агент физически способен сделать, даже если его уже обманули.

Что Claude Code уже умеет сам - и почему этого мало?

Anthropic прямо признаёт проблему в своей документации, а не прячет её:

Промпт-инъекция - это техника, при которой атакующий пытается переопределить или изменить инструкции ИИ-ассистента, вставляя вредоносный текст. Claude Code включает несколько защит от таких атак.

- Документация Claude Code, https://code.claude.com/docs/en/security

Из документации: агент анализирует запрос целиком на подозрительные инструкции, не одобряет curl и wget автоматически, держит веб-контент в отдельном контекстном окне, чтобы он не подмешивался в основной, и требует подтверждения доверия при первом запуске в новой кодовой базе или подключении нового MCP-сервера.

Но есть жёсткая оговорка, которую Anthropic формулирует без обиняков:

Режим bypassPermissions не даёт никакой защиты от промпт-инъекции или непреднамеренных действий.

- Документация Claude Code, https://code.claude.com/docs/en/permission-modes

Если ты хоть раз в раздражении запускал Claude Code с --dangerously-skip-permissions, чтобы он «не доставал вопросами» - именно в этот момент ты выключил все механизмы, которые могли бы остановить ровно те четыре атаки, что разобраны выше. Я держу этот флаг выключенным сознательно, даже когда Claude Code переспрашивает на десятый раз подряд за сессию - раздражает, но именно эти вопросы и есть граница между «агент прочитал подозрительный текст» и «агент его выполнил». Разумная связка для непрограммиста - обычный режим разрешений (default или acceptEdits) плюс включённый sandbox: обычные правки файлов идут без лишних вопросов, а команды в терминале физически не могут выйти за пределы песочницы, даже если агента обманули.

Как включить sandbox-режим и закрыть дыру, которую он не закрывает по умолчанию?

Включить на постоянной основе для всех проектов - одна правка ~/.claude/settings.json:

json
{
  "sandbox": { "enabled": true }
}

По умолчанию sandbox-команды пишут только в рабочую папку проекта и временную папку сессии, а сетевой доступ идёт через прокси - ни один домен не разрешён заранее, при первом обращении к новому домену Claude Code спросит подтверждение. Anthropic указывает, что это резко сокращает число вопросов о разрешениях - на 84% по внутренним замерам компании, потому что sandbox сам решает часть безопасных случаев вместо того, чтобы каждый раз спрашивать тебя.

Дыра, о которой молчит стандартная настройка: sandbox по умолчанию ограничивает запись, но не запрещает чтение файлов вроде ~/.aws/credentials и ~/.ssh. Ровно эти файлы и переменные окружения были целью в разборах Mozilla 0Din и «Comment and Control» выше. Закрыть это - отдельный блок в том же файле:

json
{
  "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 поставить прямо сегодня?

Минимальный набор под непрограммиста, который закрывает основные цели всех четырёх атак сразу:

json
{
  "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-сервер перед тем, как доверить их агенту?

По репозиториям - короткий чек перед тем, как отдавать их агенту:

  1. Не переходи сразу к установке по ссылке из письма, поста или обзора с незнакомого источника - именно так, по предупреждению 0Din, такие репозитории и распространяются.
  2. Если при установке появляется ошибка с инструкцией «запусти команду X, чтобы исправить» - прочитай, что X реально делает, прежде чем разрешать Claude Code её выполнить. Инструкция из разбора выше выглядела как совершенно рутинная - в этом и был расчёт.
  3. Смотри на возраст репозитория и историю коммитов, а не только на число звёзд - свежесозданные репозитории со звёздами легко накрутить специально под такую атаку.
  4. Если репозиторий незнакомый - запускай установку в виртуальной машине, а не на рабочей машине с реальными ключами. Это прямая рекомендация самой Anthropic для работы с внешними сервисами.

По MCP-серверам позиция Anthropic сформулирована открыто:

Мы советуем писать собственные MCP-серверы или использовать серверы от провайдеров, которым вы доверяете. Anthropic проверяет коннекторы по своим критериям листинга перед добавлением в каталог, но не проводит security-аудит и не управляет ни одним MCP-сервером.

- Документация Claude Code, https://code.claude.com/docs/en/security

Это значит, что ответственность за проверку стороннего MCP-сервера лежит на тебе, а не на площадке, откуда ты его поставил. Отдельные команды - в основном security-стартапы - уже делают под это инструменты: сканеры конфигурации MCP на предмет отравленных описаний, «пиннинг» инструмента, при котором хэш описания сохраняется при первой установке и любое изменение задним числом сигнализирует тревогу. Технологии молодые, полагаться на них как на единственную защиту рано - но держать в поле зрения стоит, особенно если ты подключаешь MCP-серверы к продакшену.

7 правил защиты: чек-лист на сегодня

  1. Включи sandbox-режим (/sandbox или "sandbox": {"enabled": true} в ~/.claude/settings.json) и добавь блок credentials, закрывающий чтение ~/.ssh и ~/.aws/credentials.
  2. Добавь permissions.deny на чтение секретных файлов и на опасные bash-команды (curl, wget, sudo) - запрет всегда побеждает разрешение.
  3. Никогда не запускай --dangerously-skip-permissions на чужом или непроверенном коде - это выключает вообще все защиты разом, включая ту, что могла бы остановить ровно эти атаки.
  4. Не разрешай Claude Code автоматически выполнять «команду-починку» из текста ошибки - сначала прочитай, что она реально делает.
  5. Ставь MCP-серверы только из источников, которым доверяешь, и держи в голове, что Anthropic их не проверяет на безопасность за тебя.
  6. Разделяй сессии по правам: одна работает с твоими личными данными и не видит внешние данные, вторая разбирает чужие письма/репозитории/тикеты, но не имеет доступа к секретам, третья публикует наружу - и только то, что подтвердил лично ты. Я у себя в проектах держу это строго: сессия с доступом к платёжным ключам никогда не читает произвольные внешние тикеты и репозитории, а сессия, которая парсит чужой код, вообще не видит секретов. Не смешивай эти роли в одном чате.
  7. Держи Claude Code и подключённые сценарии автоматизации обновлёнными - большая часть разобранных здесь дыр к моменту публикации гайда уже закрыта патчами, а новые закрываются похожим образом.

Что дальше

Ни один из этих слоёв не работает как гарантия - Anthropic сама честно пишет, что ни одна защита не даёт полного иммунитета. Я не жду от Claude Code, что он сам распознает подвох в тексте ошибки или в комментарии к issue - для меня sandbox и permissions.deny встроены в то, как я вообще держу контекст проекта: что агент видит, чему он доверяет по умолчанию, и что происходит, когда он ошибается.

Источники

Полная схема по вайб-кодингу за вечер: ИИ-клон + Второй мозг + Контекст-инжиниринг. 3 эфира. Записи остаются у тебя.

Практикум по вайб-кодингу
+Твой второй мозг
3 вечера - стек, метод, первый проект
Старт 14–16 июля  ·  2 000 ₽
Записаться →

Новые материалы - дайджестом, без спама

Гайды выходят регулярно. Подпишись, чтобы не пропускать: пришлю подборку в Telegram или на email. Раз в неделю или каждый день - выбираешь сам.

Была инструкция полезна?
Артемий Миллер
Автор
Артемий Миллер
Предприниматель и вайб-кодер

Артемий Миллер - предприниматель и вайб-кодер. Бывший программист, собирает продукты исключительно вместе с ИИ-агентами, без найма разработчиков.

Связанные инструкции

Связанные концепты