Google удалила из GitHub-репозитория проекта Agent Development Kit (ADK) Python три агентных процесса: issue-analyze.yml, issue-fix.yml и pr-analyze.yml. Специалисты Pillar Security выяснили, что вредоносный текст в общедоступном issue мог заставить агента сортировки запустить более привилегированную автоматику исправления кода. Проблема находилась в инфраструктуре репозитория, а не в распространяемом пакете ADK Python.
Цепочка начиналась с issue-analyze.yml, автоматически запускавшегося при создании любого GitHub issue. Процесс получал пользовательский текст, а значит, заведомо недоверенные данные. Для работы он применял учетные данные сервисного аккаунта ADK_GCP_SA_KEY, передавал персональный токен ADK_TRIAGE_AGENT и ключ GOOGLE_API_KEY агенту программирования Antigravity. Подготовленный разбор публиковался в issue от имени adk-bot.
В описание issue можно было вставить инструкции для prompt injection и убедить агента написать комментарий /adk-issue-fix. Внешний пользователь при этом оставался автором исходного текста, но команда появлялась уже от имени adk-bot. Второй процесс, issue-fix.yml, реагировал на такую команду лишь в том случае, если ее автор имел статус владельца, участника или соавтора репозитория. По данным Pillar Security, adk-bot числился collaborator, поэтому успешно проходил проверку. Система проверяла автора комментария, но не источник указаний, заставивших этого автора написать команду.
Получив разрешение, issue-fix.yml мог редактировать код, создавать форк от имени adk-bot, отправлять ветку и открывать pull request. Сгенерированный ботом pull request от 4 июня подтвердил, что эта автоматика действительно работала в репозитории. Тем самым учетная запись бота стала своеобразным пропуском между публичным issue и операциями, предназначенными для доверенных участников проекта.
Для привилегированной задачи были заявлены права на запись в issues, содержимое репозитория и pull requests. Эти настройки ограничивали автоматически создаваемый GitHub токен GITHUB_TOKEN, но необязательно распространялись на отдельный персональный токен ADK_TRIAGE_AGENT, который применялся при операциях с репозиторием. Его точные scopes публично не раскрывались. Задача извлекала код с этим PAT, проходила аутентификацию в Google Cloud и запускала AI-агента в окружении, где одновременно находились PAT, ключ Google API и учетные данные сервисного аккаунта.
Командный фильтр раннера на первый взгляд выглядел жестким: метасимволы оболочки отклонялись, а первой частью команды разрешалось ставить только gh либо git. Но Antigravity SDK запускался с CapabilitiesConfig(). Документация Google указывает, что такая конфигурация включает все инструменты, в том числе запись файлов. Агент мог сохранить вредоносную программу в файл, изменить параметр Git core.hooksPath, направив поиск хуков в выбранный каталог, а затем выполнить разрешенную команду git. Git рассматривает хуки как исполняемые программы, поэтому синтаксический белый список команд не мешал запуску произвольного кода.
В контролируемом доказательстве концепции Pillar Security добилась произвольного выполнения кода на CI-раннере и извлекла персональный токен adk-bot. В том же привилегированном окружении находились ключ Google API и credential сервисного аккаунта Google Cloud. Google сообщила исследователям, что этот аккаунт имел доступ к Vertex AI в отдельном проекте управления GitHub; другие его полномочия не раскрывались.
Публичные данные не доказывают реальную эксплуатацию атаки, заражение выпуска ADK или компрометацию пользователей пакета. Неизвестно и то, позволял ли похищенный PAT напрямую отправлять изменения в основную ветку, какой полный доступ к репозиториям он давал и насколько далеко распространялись права сервисного аккаунта в Google Cloud. Все показанные атаки оставались исследовательскими proof of concept, поэтому утверждать о более широкой цепочке заражения оснований пока нет.
В отчете Pillar Security описывалась и более ранняя схема с привилегированными процессами Gemini. С ее помощью, по оценке исследователей, можно было создать ложный след проверки pull request. Полностью убрать человека из цепочки она не позволяла: сопровождающий проекта все равно должен был вручную слить изменения. В новой схеме опаснее оказался сам переход от недоверенного текста к CI-среде с секретами и возможностью записи.
Google удалила issue-analyze.yml, issue-fix.yml и pr-analyze.yml. В коммите компания указала, что процессы обрабатывали недоверенное содержимое issues и pull requests, используя широкие учетные данные репозитория. В метаданных исправления стоит дата авторства 9 июня 2026 года. Pillar Security 2 июля проверила отсутствие всех трех файлов, а 21 июля сообщила, что Google подтвердила устранение проблемы. 4 августа 2026 года The Hacker News также не обнаружила эти имена в каталоге workflows основной ветки.
The Hacker News запросила у Google сведения о scopes персонального токена бота, правах сервисного аккаунта Google Cloud и признаках фактической эксплуатации. Pillar Security получила вопросы о среде, где проводилось доказательство концепции, и о доступе к обнаруженным credential. На момент публикации ответы обеих организаций еще ожидались. Для похожей автоматики исследователи советуют разделять учетные записи публичного агента сортировки и агента, меняющего код, урезать права PAT и набор инструментов Antigravity, а привилегированные действия подтверждать сигналом, который невозможно породить через текст issue или pull request.
Изображение носит иллюстративный характер
Цепочка начиналась с issue-analyze.yml, автоматически запускавшегося при создании любого GitHub issue. Процесс получал пользовательский текст, а значит, заведомо недоверенные данные. Для работы он применял учетные данные сервисного аккаунта ADK_GCP_SA_KEY, передавал персональный токен ADK_TRIAGE_AGENT и ключ GOOGLE_API_KEY агенту программирования Antigravity. Подготовленный разбор публиковался в issue от имени adk-bot.
В описание issue можно было вставить инструкции для prompt injection и убедить агента написать комментарий /adk-issue-fix. Внешний пользователь при этом оставался автором исходного текста, но команда появлялась уже от имени adk-bot. Второй процесс, issue-fix.yml, реагировал на такую команду лишь в том случае, если ее автор имел статус владельца, участника или соавтора репозитория. По данным Pillar Security, adk-bot числился collaborator, поэтому успешно проходил проверку. Система проверяла автора комментария, но не источник указаний, заставивших этого автора написать команду.
Получив разрешение, issue-fix.yml мог редактировать код, создавать форк от имени adk-bot, отправлять ветку и открывать pull request. Сгенерированный ботом pull request от 4 июня подтвердил, что эта автоматика действительно работала в репозитории. Тем самым учетная запись бота стала своеобразным пропуском между публичным issue и операциями, предназначенными для доверенных участников проекта.
Для привилегированной задачи были заявлены права на запись в issues, содержимое репозитория и pull requests. Эти настройки ограничивали автоматически создаваемый GitHub токен GITHUB_TOKEN, но необязательно распространялись на отдельный персональный токен ADK_TRIAGE_AGENT, который применялся при операциях с репозиторием. Его точные scopes публично не раскрывались. Задача извлекала код с этим PAT, проходила аутентификацию в Google Cloud и запускала AI-агента в окружении, где одновременно находились PAT, ключ Google API и учетные данные сервисного аккаунта.
Командный фильтр раннера на первый взгляд выглядел жестким: метасимволы оболочки отклонялись, а первой частью команды разрешалось ставить только gh либо git. Но Antigravity SDK запускался с CapabilitiesConfig(). Документация Google указывает, что такая конфигурация включает все инструменты, в том числе запись файлов. Агент мог сохранить вредоносную программу в файл, изменить параметр Git core.hooksPath, направив поиск хуков в выбранный каталог, а затем выполнить разрешенную команду git. Git рассматривает хуки как исполняемые программы, поэтому синтаксический белый список команд не мешал запуску произвольного кода.
В контролируемом доказательстве концепции Pillar Security добилась произвольного выполнения кода на CI-раннере и извлекла персональный токен adk-bot. В том же привилегированном окружении находились ключ Google API и credential сервисного аккаунта Google Cloud. Google сообщила исследователям, что этот аккаунт имел доступ к Vertex AI в отдельном проекте управления GitHub; другие его полномочия не раскрывались.
Публичные данные не доказывают реальную эксплуатацию атаки, заражение выпуска ADK или компрометацию пользователей пакета. Неизвестно и то, позволял ли похищенный PAT напрямую отправлять изменения в основную ветку, какой полный доступ к репозиториям он давал и насколько далеко распространялись права сервисного аккаунта в Google Cloud. Все показанные атаки оставались исследовательскими proof of concept, поэтому утверждать о более широкой цепочке заражения оснований пока нет.
В отчете Pillar Security описывалась и более ранняя схема с привилегированными процессами Gemini. С ее помощью, по оценке исследователей, можно было создать ложный след проверки pull request. Полностью убрать человека из цепочки она не позволяла: сопровождающий проекта все равно должен был вручную слить изменения. В новой схеме опаснее оказался сам переход от недоверенного текста к CI-среде с секретами и возможностью записи.
Google удалила issue-analyze.yml, issue-fix.yml и pr-analyze.yml. В коммите компания указала, что процессы обрабатывали недоверенное содержимое issues и pull requests, используя широкие учетные данные репозитория. В метаданных исправления стоит дата авторства 9 июня 2026 года. Pillar Security 2 июля проверила отсутствие всех трех файлов, а 21 июля сообщила, что Google подтвердила устранение проблемы. 4 августа 2026 года The Hacker News также не обнаружила эти имена в каталоге workflows основной ветки.
The Hacker News запросила у Google сведения о scopes персонального токена бота, правах сервисного аккаунта Google Cloud и признаках фактической эксплуатации. Pillar Security получила вопросы о среде, где проводилось доказательство концепции, и о доступе к обнаруженным credential. На момент публикации ответы обеих организаций еще ожидались. Для похожей автоматики исследователи советуют разделять учетные записи публичного агента сортировки и агента, меняющего код, урезать права PAT и набор инструментов Antigravity, а привилегированные действия подтверждать сигналом, который невозможно породить через текст issue или pull request.
