Исследователи Pillar Security обнаружили две связанные проблемы в автоматизации открытого репозитория google/adk-python. Через внедрение инструкций в текст задачи или запроса на включение изменений внешний пользователь мог повлиять на публичного ИИ-агента, а тот — инициировать запуск другого агента с более широкими полномочиями. Во второй цепочке специалисты продемонстрировали выполнение произвольных команд в среде GitHub Actions и вывод персонального токена бота на подконтрольный сервер.
Важно: речь идет не об уязвимости устанавливаемого через pip пакета Google Agent Development Kit. Проблемы находились в GitHub Actions и ИИ-автоматизации, которую Google использовала для сопровождения собственного репозитория adk-python. Публичный отчет не показывает компрометацию опубликованных выпусков ADK.
Google в итоге удалила три связанных сценария GitHub Actions — issue-analyze.yml, issue-fix.yml и pr-analyze.yml. В описании исправления указано, что они запускали автоматического агента на недоверенном содержимом задач и запросов на включение изменений, используя широкие учетные данные репозитория. Компания решила убрать этот путь полностью, пока готовится более безопасная схема.
Agent Development Kit, или ADK, Google представила 9 апреля 2025 года на Cloud Next. Это открытый набор инструментов для разработки ИИ-агентов и систем, где несколько агентов взаимодействуют между собой. Фреймворк позволяет задавать поведение агентов, подключать инструменты, строить цепочки взаимодействия, проводить оценку работы и разворачивать готовые системы.
История с adk-python интересна именно устройством такой автоматизации. В репозитории существовали ИИ-агенты с разными уровнями доступа. Одни обрабатывали данные, которые мог отправить практически любой пользователь GitHub. Другие сценарии предназначались для сопровождающих проекта и обладали более серьезными возможностями. Проблема появилась в месте, где эти два уровня доверия встретились.
При изучении репозитория исследователь Дэн Лисичкин обратил внимание на агента, занимавшегося первичной обработкой запросов на включение изменений.
Агент мог читать сведения о запросе, добавлять метки и оставлять комментарии. Комментарии при этом публиковались через adk-bot. Это была не изолированная учетная запись GitHub App с минимальными правами: GitHub показывал пользователя как collaborator репозитория. Для работы использовался персональный токен доступа.
Это создало необычную границу доверия. Пользователь извне не мог напрямую запускать некоторые привилегированные сценарии. adk-bot — мог. Оставалось заставить публичного ИИ-агента написать нужную команду.
Исследователь подготовил запрос на включение изменений с текстом, который выглядел как обычное описание процесса проверки.
Внутри находилась инструкция для ИИ-агента: после первичного разбора оставить комментарий, первая строка которого начиналась с @gemini-cli.
Это пример внедрения инструкций — prompt injection. Недоверенный пользовательский текст попадает в контекст модели и заставляет ее выполнить действие, которого разработчики автоматизации не планировали.
За упоминаниями @gemini-cli в репозитории следил отдельный сценарий gemini-dispatch.yml. Команда от участника с подходящими правами передавалась дальше в gemini-invoke.yml или сценарий автоматической проверки изменений. Публичный пользователь такой командой считаться не должен. Однако команда появилась от adk-bot, который имел статус collaborator.
Получилась цепочка: посторонний пользователь → недоверенный текст → публичный ИИ-агент → комментарий от доверенной учетной записи → более привилегированный ИИ-агент.
Проверка прав видела доверенного автора комментария. Источник решения этого автора система уже не проверяла.
После запуска gemini-invoke исследователь обнаружил еще одну проблему: ограничения на набор инструментов Gemini были настроены недостаточно жестко. В конфигурации отсутствовало ограничение tools.core, поэтому агент получил возможность выполнять команды в среде задания.
В окружение также передавался GITHUB_TOKEN. Этот токен не давал исследователю произвольную запись в исходный код репозитория. Его права были ограничены работой с задачами и запросами на включение изменений: issues: write и pull-requests: write.
Этого, однако, оказалось достаточно для неприятного сценария. Исследователь показал возможность редактировать данные в обсуждениях, создавать сообщения от имени автоматизации, работать с запросами на рецензирование и формировать события проверки изменений. В репозитории уже существовал пример, где github-actions[bot] оставлял одобрение после запуска автоматической проверки Gemini. Из этих возможностей Лисичкин собрал доказательство концепции атаки на процесс рецензирования.
Сценарий предполагал два запроса на включение изменений. В первом находилось изменение, которое атакующий хотел провести через проверку. После начала обычного процесса рецензирования создавался второй запрос — уже с внедренными инструкциями для агента.
Агент, обрабатывающий второй запрос, можно было попытаться заставить изменить информацию вокруг первого: переписать комментарий проверяющего, вызвать Gemini, создать положительный результат автоматической проверки, убрать запрос на дополнительное рецензирование и изменить метки.
В интерфейсе GitHub могла появиться убедительная последовательность событий, создающая впечатление, что изменение действительно прошло необходимую проверку. Полностью автоматической компрометации основной ветки исследователь при этом не показал.
Финальное объединение изменений должен был выполнить сопровождающий проекта. Google при рассмотрении первого отчета отдельно указала на это обстоятельство: для доведения атаки до компрометации кода требовалось убедить человека принять вредоносный запрос. Из-за зависимости от социальной инженерии отчет не получил денежного вознаграждения, хотя Google признала исследование и усилила защиту репозитория.
После первого отчета в adk-python появилась автоматизация на базе Google Antigravity. Один сценарий анализировал пользовательские задачи. Второй — issue-fix.yml — предназначался для автоматического исправления проблемы в коде. Его должен был запускать доверенный участник специальным комментарием: /adk-issue-fix
После команды агент мог подготовить изменения и создать запрос на их включение. Доступ проверялся по автору комментария. Запустить сценарий мог владелец репозитория, участник организации или collaborator.
У adk-bot такой статус был. Публичному агенту при этом передавался текст пользовательской задачи.
Исследователи снова использовали внедрение инструкций: специально составленный текст должен был заставить первого агента самостоятельно оставить /adk-issue-fix. GitHub после этого видел команду от collaborator и запускал второй, более привилегированный сценарий. Ручное действие сопровождающего для перехода между этими двумя этапами уже не требовалось.
Разработчики пытались ограничить выполнение системных команд. Функция _is_safe_command блокировала ряд специальных символов оболочки и пропускала только команды, первым элементом которых был git или gh — официальный консольный клиент GitHub. На первый взгляд список довольно жесткий. Проблема в возможностях самого Git.
Git поддерживает исполняемые хуки. Каталог с ними можно заменить параметром core.hooksPath, после чего Git способен запустить программу из указанного каталога. Это штатная возможность системы контроля версий, описанная в ее официальной документации. У агента одновременно оставалась возможность записывать файлы.
Исследователь мог заставить его создать файл с командами, а затем воспользоваться разрешенным вызовом git, чтобы запустить этот файл как хук. Еще один вариант строился на псевдонимах Git: значение псевдонима, начинающееся с !, Git обрабатывает как команду оболочки. Такая возможность также предусмотрена самой системой.
Фильтр фактически проверял название разрешенной программы, но не все действия, которые эта программа способна инициировать. Так исследователи получили выполнение произвольных команд в исполнителе GitHub Actions.
Сценарий issue-fix.yml работал с несколькими чувствительными учетными данными.
Агент использовал персональный токен adk-bot, передававшийся как ADK_TRIAGE_AGENT, ключ Google API и ключ сервисной учетной записи Google Cloud. Исследователи показали цепочку от вредоносной инструкции в задаче GitHub до выполнения кода и вывода PAT на подконтрольный сервер.
И здесь есть важное ограничение. В файле GitHub Actions присутствовало объявление contents: write, но этот параметр определяет полномочия стандартного GITHUB_TOKEN, который создает GitHub для задания. В атакуемом процессе для операций git и gh применялся отдельный секрет ADK_TRIAGE_AGENT — персональный токен adk-bot.
Права этого PAT нельзя определить из публичных данных. Исследователь предупреждает: из одного наличия contents: write нельзя делать вывод, что украденный PAT позволял напрямую отправить код в main. Даже если это был классический PAT, его разрешения могли ограничиваться публичными репозиториями.
Полномочия сервисной учетной записи Google Cloud тоже изначально нельзя было определить извне. Позднее Google сообщила исследователям, что связанная с ключом учетная запись имела доступ, включая Vertex AI, в отдельном проекте, который использовался для управления GitHub. Публичных данных о более широких полномочиях этой учетной записи нет.
Google также указала на еще один защитный рубеж: перед попаданием изменений в основную кодовую базу применялся внутренний процесс импорта через Copybara и дополнительная проверка.
Это снижало реальную возможность превратить продемонстрированное выполнение кода в CI в прямую компрометацию распространяемого ADK.
Первый отчет Pillar Security отправила в программу Google Open Source VRP 2 июня 2026 года. Полное доказательство концепции исследователи передали 3 июня. Вторую проблему сообщили 5 июня, а 8 июня предоставили демонстрацию цепочки, заканчивающейся выводом PAT на внешний сервер.
К 2 июля исследователь подтвердил исчезновение затронутых сценариев из репозитория. 21 июля Google сообщила ему, что проблема исправлена.
Исправление можно проверить непосредственно в истории google/adk-python.
Коммит 66730e9 удаляет:
issue-analyze.yml,issue-fix.yml,pr-analyze.yml.
Всего удалено 334 строки конфигурации GitHub Actions. Описание коммита связывает решение с обработкой недоверенного содержимого задач и запросов на включение изменений автоматическим агентом, имевшим доступ к широким учетным данным репозитория.
Удаление этих сценариев относится к инфраструктуре разработки репозитория. Это не исправление кода Python-библиотеки google-adk и не основание утверждать, что пользователи получили зараженный выпуск пакета.
Есть новость? Станьте автором.
Мы сотрудничаем с независимыми исследователями и специалистами по кибербезопасности. Отправьте нам новость или предложите статью на рассмотрение редакции.
