Заявка в GitHub становилась командой: у Claude Code, Gemini CLI и Codex нашли опасные цепочки атак

Специалисты Novee Security раскрыли несколько цепочек атак на инструменты программирования Claude Code, Gemini CLI и Codex. Исследователи проверяли сценарии автоматизации, работавшие в официальных репозиториях Anthropic, Google и OpenAI.

В отдельных конфигурациях точкой входа могла стать обычная заявка в GitHub Issues. Её автор помещал в описание скрытую инструкцию, после чего ИИ-агент пытался выполнить действие через разрешенные инструменты.

Последствия зависели от настроек конкретного задания GitHub Actions. Агенту могли быть доступны командная оболочка, файлы рабочего каталога, сетевые запросы, API-ключи и токен GitHub. Ошибка в одном из этих уровней превращала текст из внешней заявки в команду для инфраструктуры.

Полный технический отчет опубликовали 6 августа 2026 года. Исследователи описали три последовательных обхода защиты Claude Code, критическую проблему Gemini CLI и ошибку в построении многоэтапного сценария Codex. Разработчики изменили инструменты и собственные задания автоматизации до раскрытия подробностей.

Публичных подтверждений использования этих цепочек в массовых атаках нет. В отчёте разобраны контролируемые проверки на инфраструктуре разработчиков и сценарии возможной эксплуатации.

Проблема находилась между моделью и инфраструктурой

ИИ-агент — это не одна языковая модель. Вокруг неё работает программная система, которая передаёт файлы, запускает команды, управляет разрешениями, хранит состояние и подключается к внешним службам.

Описание заявки, сообщение коммита или файл проекта могут содержать скрытую инструкцию. Модель способна принять её за часть задания. Такой прием называют внедрением инструкций.

Сам по себе вредоносный текст ещё не означает взлом. Реальная угроза появляется, когда агент получает возможность:

• запускать системные команды;

• читать файлы за пределами проекта;

• обращаться к сети;

• работать с секретами;

• оставлять данные следующему запуску.

Документация Codex относит к недоверенному вводу описания запросов на изменение кода, сообщения коммитов, изображения и проектные файлы AGENTS.md. Эти данные могут незаметно изменить поведение агента.

Claude Code: разрешённая команда Git запускала чужой код

Первую цепочку исследователи обнаружили в исторической конфигурации Claude Code. Агенту разрешали несколько команд Git, включая строки, начинающиеся с git push.

Перед запуском Claude Code проверял команду с помощью набора фильтров. Они искали подстановки, управляющие символы, обращения к /proc и другие опасные конструкции.

Содержимое кавычек исключалось из части проверок. Для командной оболочки это логично: текст внутри одинарных кавычек обычно считается обычной строкой.

Исследователи использовали параметр Git --receive-pack. Он позволяет указать программу, которую Git должен запустить на удаленной стороне или передать транспортному механизму.

Опасная конструкция помещалась внутрь кавычек. Проверка видела разрешенный вызов git push, а Git воспринимал содержимое параметра как отдельную команду.

В демонстрации это позволяло выполнить код на сервере GitHub Actions. Доступные после этого возможности определялись полномочиями задания. При наличии токена с правом записи атакующий потенциально мог изменить содержимое репозитория или затронуть процесс публикации пакетов.

Команды для чтения выходили за пределы проекта

После первого исправления разработчики сократили набор разрешенных операций. Несколько утилит для чтения и преобразования текста продолжали запускаться без отдельного подтверждения.

Проверка пути действовала для распространённых команд cat, head и tail. Утилиты tac, rev, fold, expand и unexpand не проходили такую же проверку.

Это позволяло попытаться прочитать данные за пределами рабочей папки. В Linux переменные окружения процесса доступны через виртуальную файловую систему /proc.

Фильтр блокировал буквальное слово environ. Пустые кавычки меняли строку для проверяющего кода, но после обработки оболочкой путь снова становился действительным.

Данные можно было пропустить через rev, которая записывает символы в обратном порядке. Система скрытия секретов GitHub Actions ищет исходные значения токенов и ключей. После преобразования она могла их не распознать.

Результат попадал в сводку задания, где его мог прочитать человек с доступом к журналам.

API-ключ передавался через счётчики загрузок

Третья проблема Claude Code получила номер CVE-2026-54316.

Инструмент WebFetch мог обращаться к домену huggingface.co без дополнительного запроса разрешения. Правило распространялось на любые пути внутри домена, включая репозитории обычных пользователей.

Hugging Face ведёт счётчики загрузок файлов моделей. Исследователь мог создать несколько репозиториев и назначить каждому определённый символ.

Агент читал символ из секрета и обращался к соответствующему файлу. Изменение счётчика показывало владельцу репозитория, какой символ выбран. Повторение запроса позволяло восстановить значение по частям.

Секрет не отправлялся в адресе и не передавался одним сообщением. Каналом утечки становилась последовательность обращений к заранее разрешённому домену.

Официальный бюллетень подтверждает возможность передачи таким способом содержимого файлов, переменных окружения и результатов команд. Для успешной атаки злоумышленник должен был сначала поместить недоверенный текст в контекст Claude Code.

Проблема затрагивала версии Claude Code от 0.2.54 до 2.1.162 включительно. Исправление вошло в версию 2.1.163. Пользователи стандартного автоматического обновления уже получили новую сборку.

Anthropic оценила уязвимость в 6,0 балла по CVSS 4.0 и присвоила ей средний уровень опасности. Оценка учитывает необходимость предварительно внедрить недоверенный текст в контекст агента.

Gemini CLI автоматически доверял рабочей папке

Google раскрыла две связанные проблемы Gemini CLI и действия run-gemini-cli.

Первая затрагивала работу без графического или текстового диалога с пользователем. Такой режим применяется в системах автоматической сборки и проверки кода.

Старые версии Gemini CLI автоматически считали рабочую папку доверенной. Инструмент мог загрузить из неё настройки и переменные окружения до отдельной проверки содержимого.

Опасные файлы в каталоге .gemini или локальный .env могли повлиять на выполнение программы. Google указывает, что обработка недоверенного каталога в таком режиме создавала риск удалённого выполнения кода.

Исправленная версия требует явно разрешить доверие к рабочей папке. Старые задания автоматизации после обновления могут перестать загружать локальные настройки. Их владельцам придётся проверить конфигурацию вручную.

Режим автоматического подтверждения игнорировал ограничения

Вторая проблема проявлялась при использовании параметра --yolo. В этом режиме Gemini CLI выполняет вызовы инструментов без подтверждения человека.

Администратор мог разрешить только отдельную команду, например run_shell_command(echo). Предполагалось, что агент сможет вызвать echo, но не получит полный доступ к оболочке.

Старые версии игнорировали точное ограничение при работе с --yolo. Разрешение одной команды фактически открывало весь инструмент запуска команд.

Внешняя заявка могла содержать инструкцию, убеждавшую агента выполнить другую программу. Google прямо указывает на возможность удалённого выполнения кода через внедрение инструкций при сочетании недоверенного ввода, --yolo и разрешённой командной оболочки.

Исследователи также описали чтение переменных окружения родительского процесса через /proc. Gemini CLI удалял секреты из окружения дочерней команды, но основной процесс продолжал их хранить. Общий пользователь и пространство идентификаторов процессов позволяли попытаться прочитать эти данные.

Google оценила совокупную проблему в 10 баллов по CVSS 3.1. Номер CVE ей не присвоен. Бюллетень опубликован под идентификатором GHSA-wpqr-6v78-jr5g.

Исправления доступны в Gemini CLI 0.39.1, предварительной версии 0.40.0-preview.3 и run-gemini-cli 0.1.22.

Codex: первый запуск оставлял инструкции второму

Случай Codex отличался от уязвимостей Claude Code и Gemini CLI. Отдельного CVE или официального бюллетеня для него нет.

Исследователи нашли опасное сочетание настроек в старом сценарии поиска похожих заявок в репозитории Codex.

Сценарий запускал агента дважды внутри одного задания GitHub Actions. Оба прохода использовали одну рабочую папку.

Первый проход анализировал большой набор заявок. Второй включался, когда первый не находил подходящего результата или возвращал данные, не прошедшие проверку.

Песочница разрешала первому агенту записывать файлы в рабочий каталог. Каталоги .git, .agents и .codex были защищены. Файл AGENTS.md оставался доступным для изменения.

Codex читает AGENTS.md перед началом работы и использует его как инструкцию проекта. Первый проход мог создать такой файл, а затем вернуть ответ с неправильной структурой.

Проверка корректно отклоняла результат и запускала второй проход. Новый процесс открывал ту же папку, находил AGENTS.md и принимал записанные туда команды за собственные рабочие правила.

Проверка JSON не содержала ошибки. Она контролировала ответ первого агента, но не состояние общей файловой системы.

Риск возрастал, если второй проход получал больше полномочий: право менять заявку, записывать данные в репозиторий, обращаться к сети или использовать секретный токен.

OpenAI изменила собственный сценарий. Сейчас два прохода работают в разных заданиях GitHub Actions и получают отдельные временные серверы. Резервный этап прямо запускается в новом задании, поскольку предыдущий процесс лишается административных прав.

Текущие проходы используют режим файловой системы только для чтения и стратегию drop-sudo. Версия codex-action закреплена за точным идентификатором коммита, а не за изменяемой веткой.

Документация OpenAI теперь требует считать AGENTS.md, AGENTS.override.md и другие проектные инструкции частью поверхности недоверенного ввода.

Копии старых сценариев могли остаться в других проектах

Обновление официального репозитория не меняет файлы GitHub Actions, которые другие команды ранее скопировали в свои проекты.

Проверки требуют сценарии, где ИИ-агент:

• автоматически запускается после внешней заявки;

• получает текст от неизвестного автора;

• работает с секретами;

• имеет доступ к сети или оболочке;

• может записывать файлы для следующего этапа.

Самый безопасный вариант — обрабатывать внешний текст в отдельном задании без ключей и права записи. Следующий этап должен запускаться на новом сервере и получать только небольшой набор проверенных значений.

Перенос общей рабочей папки, кэша или проектных инструкций между этапами возвращает риск. Вредоносные данные могут пройти через файл, даже если ответ модели проверяется по строгой схеме.

Разрешения GITHUB_TOKEN лучше задавать отдельно для каждого задания. Этапу анализа обычно достаточно чтения содержимого репозитория. Право записи стоит включать только в той части сценария, где оно действительно необходимо.

Самостоятельно размещённые серверы GitHub Actions требуют дополнительной изоляции. Вредоносный процесс может оставить на такой машине файлы или изменить среду для последующих заданий.