Дослідники компанії Pillar Security виявили дві вразливості в автоматизації GitHub-репозиторію Google Agent Development Kit (ADK) для Python, які дозволяли зовнішньому зловмиснику через prompt injection змусити низькопривілейованого бота запустити привілейований робочий процес. Перший сценарій давав змогу підробити історію перевірки коду, другий — виконати довільний код у CI-ранері й витягти секрети, включно з токенами доступу та обліковими даними хмарних сервісів. За даними дослідників, проблеми стосувалися не самого Python-пакета ADK, а виключно конфігурації робочих процесів репозиторію. Google вже усунула вразливості, видаливши три проблемні воркфлоу.
Архітектурна проблема: відсутність ізоляції між агентами
Корінь обох вразливостей — в архітектурі автоматизації репозиторію. За даними дослідника Дена Лисічкіна, у репозиторії ADK функціонували два класи ІІ-агентів. Низькопривілейовані боти обробляли публічні issues та pull requests, а привілейовані агенти — доступні лише мейнтейнерам — могли виконувати команди, змінювати код і працювати з секретами. Критична помилка полягала в тому, що ці дві групи не були належним чином ізольовані одна від одної: дія низькопривілейованого бота могла ініціювати запуск привілейованого робочого процесу.
Перший сценарій: підробка ревʼю через prompt injection
У першому описаному сценарії атаки зловмисник міг відкрити pull request, що містив одночасно легітимне виправлення та шкідливий код, а потім створити другий pull request із prompt injection. Агент первинної перевірки обробляв цей запит і публікував в обговоренні службову команду з згадуванням @gemini-cli. Оскільки повідомлення надходило від довіреного облікового запису, воно автоматично запускало привілейований робочий процес.
За даними дослідників, успішна експлуатація цього вектора дозволяла:
- витягти GitHub-токен із розширеними правами
- маніпулювати коментарями, issues та pull requests
- відхиляти чужі ревʼю та схвалювати довільні зміни
- запускати Gemini для будь-якого pull request
- створювати повністю підроблену історію перевірки коду — з імітацією запиту ревʼю людиною та схвалення з боку Gemini
Важливе застереження: навіть у разі успішної експлуатації мейнтейнер мав вручну прийняти й злити шкідливий pull request з основною гілкою. Таким чином, цей сценарій вимагав додаткового елемента соціальної інженерії — підроблена історія ревʼю слугувала саме для підвищення довіри до шкідливого коду.
Другий сценарій: виконання довільного коду через adk-bot
Більш небезпечний вектор атаки стосувався робочого процесу на базі Antigravity SDK. Публічний агент автоматично аналізував нові issues та залишав коментарі від імені adk-bot, який мав роль collaborator. Через prompt injection у тексті issue зловмисник міг змусити бота опублікувати команду /adk-issue-fix. Оскільки команда надходила від облікового запису з роллю collaborator, вона проходила перевірку та запускала привілейованого агента для виправлення коду.
Запущений агент працював у середовищі з доступом до токена бота, API-ключа Google та облікових даних сервісного акаунта Google Cloud. Як повідомляють дослідники, вони продемонстрували виконання довільного коду в CI-ранері та витягнення персонального токена доступу (PAT), яким користувався бот.
Окремої уваги заслуговує метод обходу обмежень. Воркфлоу намагався обмежити набір доступних команд, дозволивши лише gh і git. Однак агент зберігав можливість запису файлів на диск. Дослідники показали, що можна зберегти шкідливе навантаження у файл, вказати нестандартний каталог із Git-хуками й виконати довільний код через дозволену команду git — класичний приклад обходу списку дозволених команд через побічні механізми.
Оцінка впливу
Статус експлуатації — доступний публічний PoC. Дослідники підкреслюють, що не виявили скомпрометованих релізів ADK і ознак експлуатації цих вразливостей у реальних атаках. Втім, потенційні наслідки були значними: компрометація CI/CD-інфраструктури великого опенсорсного проєкту Google могла призвести до впровадження шкідливого коду в кодову базу, яку використовує велика кількість розробників.
Цей випадок показовий для всієї індустрії: у міру поширення ІІ-агентів у процесах розробки межі привілеїв між ними стають новою поверхнею атаки. Prompt injection перетворюється з теоретичної загрози на практичний інструмент ескалації привілеїв у CI/CD-конвеєрах.
Заходи з усунення та рекомендації
Інженери Google вже посилили захист репозиторію та видалили три проблемні робочі процеси: issue-analyze.yml, issue-fix.yml і pr-analyze.yml. Користувачам ADK як Python-пакета додаткових дій не потрібно — вразливості не зачіпали сам код бібліотеки.
Для команд, що використовують ІІ-агентів у власних CI/CD-конвеєрах, дослідник Ден Лисічкін сформулював такі рекомендації:
- Розділяйте облікові записи — кожен бот має мати власний обліковий запис із мінімально необхідними правами
- Обмежуйте токени — урізайте права токенів до мінімуму, необхідного для конкретного завдання
- Не довіряйте командам автоматично — походження команди від бота не робить її довіреною; потрібна незалежна валідація
- Ізолюйте рівні привілеїв — дії низькопривілейованих агентів не повинні мати можливості ініціювати привілейовані робочі процеси
- Аудитуйте побічні можливості — обмеження списку команд марне, якщо агент може записувати файли й використовувати механізми на кшталт Git-хуків для обходу
Виявлені вразливості демонструють фундаментальну проблему: моделі довіри, спроєктовані для взаємодії людей із CI/CD-системами, не враховують специфіку ІІ-агентів, схильних до prompt injection. Командам, які впроваджують ІІ-автоматизацію в процеси розробки, варто провести аудит меж привілеїв між агентами та переконатися, що жоден публічно доступний бот не здатний — прямо або через ланцюжок викликів — ініціювати привілейовані операції.
