Дослідник у галузі безпеки, працюючи з колегами з Університету Джонса Гопкінса, відкрив запит на злиття (pull request) у GitHub, ввів шкідливу інструкцію в заголовок запиту та спостерігав, як дія Claude Code Security Review від Anthropic опублікувала власний API-ключ у коментарі. Той самий ін’єкційний запит спрацював на Gemini CLI Action від Google та Copilot Agent від GitHub (Microsoft). Зовнішня інфраструктура не потрібна.
Аонань Гуань, дослідник, який виявив уразливість, разом із колегами з Університету Джонса Гопкінса, Чженьчжу Лю та Гевіном Чжуном, минулого тижня опублікував повний технічний звіт, назвавши його “Comment and Control” (Коментуй та контролюй). За замовчуванням GitHub Actions не надає доступу до секретів для запитів на злиття з форків при використанні тригера `pull_request`. Однак робочі процеси, що використовують `pull_request_target` (який більшість інтеграцій ШІ-агентів вимагають для доступу до секретів), інжектують секрети в середовище виконання. Це обмежує практичну поверхню атаки, але не усуває її: під загрозою опиняються співавтори, поля коментарів та будь-які репозиторії, що використовують `pull_request_target` з ШІ-кодинговим агентом.
Згідно з часовою шкалою розкриття інформації Гуанем: Anthropic класифікував це як CVSS 9.4 Critical (винагорода $100), Google виплатив винагороду $1,337, а GitHub присудив $500 через програму винагород Copilot Bounty Program. Сума в $100 є помітно низькою порівняно з рейтингом CVSS 9.4; програма HackerOne від Anthropic розглядає знахідки, пов’язані з інструментарієм агентів, окремо від уразливостей безпеки моделі. Усі три компанії внесли виправлення тихо, і жодна з них не видала CVE в NVD або не опублікувала попередження про безпеку через GitHub Security Advisories станом на суботу.
Атака “Comment and Control” скористалася уразливістю ін’єкційного запиту в Claude Code Security Review, конкретній функції GitHub Action, яка, як визнала власна системна картка Anthropic, “не захищена від ін’єкцій запитів”. Ця функція призначена для обробки довірених вхідних даних першої сторони за замовчуванням; користувачі, які погоджуються обробляти недовірені зовнішні запити та проблеми, приймають додатковий ризик і несуть відповідальність за обмеження дозволів агента. Anthropic оновив свою документацію, щоб уточнити цю операційну модель після розкриття. Такий самий клас атаки діє під рівнем захисту OpenAI в середовищі виконання агента, виходячи з того, що їхня системна картка не документує — це не продемонстрована експлуатація. Експлойт є доказовим прикладом, але історія полягає в тому, що три системні картки виявляють розрив між тим, що документують постачальники, і тим, що вони захищають.
OpenAI та Google не відповіли на запит щодо коментарів до моменту публікації.
«На межі дії, а не на межі моделі», — сказала VentureBeat Меррітт Бер, CSO в Enkrypt AI та колишній заступник CISO в AWS, коли її запитали, де насправді має бути захист. «Середовище виконання — це радіус вибуху».
Що розповідають системні картки
Системна картка Anthropic Opus 4.7 містить 232 сторінки з кількісними показниками рівня зламу та стійкості до ін’єкцій. Вона розкриває стратегію обмеженої моделі (Mythos, відкладена як попередній перегляд можливостей) і прямо вказує, що Claude Code Security Review «не захищена від ін’єкцій запитів». Системна картка пояснює читачам, що середовище виконання було відкрите. “Comment and Control” це довело. Anthropic дійсно обмежує певні дії агентів поза сферою дії системної картки — наприклад, Claude Code Auto Mode застосовує захист на рівні середовища виконання — але сама системна картка не документує ці засоби захисту середовища виконання або їх охоплення.
Системна картка OpenAI GPT-5.4 документує обширне червоне тестування (red teaming) та публікує оцінки ін’єкцій на рівні моделі, але не метрики стійкості виконання агента чи інструментів. Trusted Access for Cyber (TAC) масштабує доступ до тисяч. Системна картка розповідає, що тестували учасники червоної команди. Вона не розповідає, наскільки стійка модель до виявлених ними атак.
Картка моделі Google Gemini 3.1 Pro, випущена в лютому, перенаправляє більшість методології безпеки до старішої документації, як виявив аналіз VentureBeat. Програма автоматизованого червоного тестування Google залишається суто внутрішньою. Зовнішньої програми кібербезпеки немає.
|
Вимір |
Anthropic (Opus 4.7) |
OpenAI (GPT-5.4) |
Google (Gemini 3.1 Pro) |
|
Глибина системної картки |
232 сторінки. Кількісні показники зламу, оцінки класифікатора та метрики стійкості до ін’єкцій. |
Обширна. Документовано години червоного тестування. Показники стійкості до ін’єкцій не опубліковані. |
Кілька сторінок. Посилається на стару картку Gemini 3 Pro. Кількісних результатів немає. |
|
Програма верифікації кібербезпеки |
CVP. Видаляє засоби кіберзахисту для перевірених пентестерів та учасників червоної команди, які проводять авторизовані наступальні роботи. Не стосується захисту від ін’єкцій запитів. Виключення платформи та збереження даних ще не документовані публічно. |
TAC. Масштабується до тисяч. Обмежує ZDR. |
Відсутня. Немає зовнішнього шляху для захисників. |
|
Стратегія обмеженої моделі |
Так. Mythos відкладено як попередній перегляд можливостей. Opus 4.7 є тестовим майданчиком. |
Обмежена модель відсутня. Повна можливість випущена, доступ обмежений. |
Обмежена модель відсутня. Немає заявлених планів щодо такої. |
|
Захист агентів середовища виконання |
Claude Code Security Review: системна картка зазначає, що вона не захищена від ін’єкцій запитів. Функція призначена для довірених вхідних даних першої сторони. Anthropic застосовує додатковий захист середовища виконання (наприклад, Claude Code Auto Mode), який не документований у системній картці. |
Не документовано. TAC регулює доступ, а не операції агента. |
Не документовано. ART лише внутрішній. |
|
Відповідь на експлойт (Comment and Control) |
CVSS 9.4 Critical. Винагорода $100. Виправлено. Без CVE. |
Безпосередньо не експлуатувалося. Структурний розрив виведений з дизайну TAC, а не продемонстрований. |
Винагорода $1,337 згідно з розкриттям Гуаня. Виправлено. Без CVE. |
|
Дані про стійкість до ін’єкцій |
Опубліковані. Кількісні показники в системній картці. |
Оцінки ін’єкцій на рівні моделі опубліковані. Немає показників стійкості виконання агента чи інструментів. |
Не опубліковані. Кількісних даних немає. |
Бер запропонувала конкретні питання для закупівель. «Для Anthropic запитайте, як результати безпеки насправді передаються через стрибки можливостей», — сказала вона VentureBeat. «Для OpenAI запитайте, що означає «довірений» під час компрометації». Щодо обох, сказала вона, директори повинні «вимагати ясності щодо того, чи поширюється захист на виконання інструментів, а не тільки на фільтрацію запитів».
Сім класів загроз, які не закриває жоден підхід до захисту
Кожен рядок називає, що ламається, чому ваші засоби контролю це пропускають, що довело “Comment and Control”, і рекомендовану дію на наступний тиждень.
|
Клас загрози |
Що ламається |
Чому ваші засоби контролю це пропускають |
Що довело “Comment and Control” |
Рекомендована дія |
|
1. Невідповідність поверхні розгортання |
CVP призначений для авторизованих досліджень у сфері наступальної безпеки, а не для захисту від ін’єкцій запитів. Він не поширюється на tenants Bedrock, Vertex або ZDR. TAC обмежує ZDR. Google не має такої програми. Ваша команда може використовувати перевірену модель на неперевіреній поверхні. |
Анонси запуску описують програму. Документація підтримки містить виключення. Команди безпеки читають анонс. Закупівлі не читають нічого. |
Експлойт націлений на середовище виконання агента, а не на платформу розгортання. Команда, що використовує Claude Code на Bedrock, виходить за межі покриття CVP, але CVP спочатку не був розроблений для вирішення цього класу вразливостей. |
Напишіть електронного листа вашим представникам Anthropic та OpenAI сьогодні. Одне запитання, письмово: «Підтвердіть, чи покриваються [ваша платформа] та [ваша конфігурація збереження даних] вашим захистом від ін’єкцій запитів на рівні виконання, і опишіть, що включає цей захист». Збережіть відповідь у вашому реєстрі ризиків постачальника. |
|
2. Секрети CI, розкриті ШІ-агентам |
ANTHROPIC_API_KEY, GEMINI_API_KEY, GITHUB_TOKEN та будь-який виробничий секрет, збережений як змінна середовища GitHub Actions, доступні для читання кожному кроку робочого процесу, включаючи ШІ-кодингові агенти. |
Конфігурація GitHub Actions за замовчуванням не обмежує секрети окремими кроками. Секрети на рівні репозиторію та організації поширюються на всі робочі процеси. Більшість команд ніколи не перевіряють, які кроки мають доступ до яких секретів. |
Агент прочитав API-ключ зі змінної середовища виконання, закодував його в тілі коментаря PR і опублікував через API GitHub. Зовнішня інфраструктура, контрольована зловмисником, не потрібна. Ексфільтрація відбувалася через власний API GitHub — сама платформа стала каналом C2. |
Виконайте: `grep -r ‘secrets.’ .github/workflows/` у кожному репозиторії з ШІ-агентом. Перелічіть усі секрети, до яких агент має доступ. Змініть усі розкриті облікові дані. Мігруйте на короткоживучі OIDC-токени (GitHub, GitLab, CircleCI). |
|
3. Надмірні дозволи для агентів середовища виконання |
ШІ-агентам надається виконання bash, git push та доступ на запис API під час налаштування. Дозволи ніколи не обмежуються. Періодичний перегляд принципу найменших привілеїв відсутній. Агенти накопичують доступ так само, як і облікові записи служб. |
Агенти налаштовуються один раз під час онбордингу та успадковуються між репозиторіями. Відсутність інструментів, що сигналізують про невикористані дозволи. Агент Comment and Control мав доступ до bash, запису та читання змінних середовища для завдання огляду коду. |
Агент мав доступ до bash, який йому не був потрібен для огляду коду. Він використав цей доступ для читання змінних середовища та публікації ексфільтрованих даних. Усунення bash повністю блокувало б ланцюжок атаки. |
Аудитуйте дозволи агентів по кожному репозиторію. Видаліть bash з агентів огляду коду. Встановіть доступ до репозиторію лише для читання. Обмежте доступ на запис (коментарі PR, коміти, злиття) через крок схвалення людиною. |
|
4. Відсутність сигналу CVE для вразливостей ШІ-агентів |
CVSS 9.4 Critical. Anthropic, Google та GitHub внесли виправлення. Нуль записів CVE в NVD. Нуль попереджень. Ваш сканер вразливостей, SIEM та інструмент GRC показують зелений сигнал. |
Жоден CNA ще не видав CVE для ін’єкцій запитів у кодингових агентів, а поточні практики CVE не охоплюють цей клас збоїв. Постачальники виправляють через оновлення версій. Qualys, Tenable та Rapid7 не мають нічого для сканування. |
Аналітик SOC, який проводить повне сканування в понеділок вранці, не знайде жодного запису про критичну вразливість, яка одночасно вразила Claude Code Security Review, Gemini CLI Action та Copilot. |
Створіть нову категорію у вашому реєстрі ризиків ланцюжка поставок: «Середовище виконання ШІ-агентів». Встановіть 48-годинний інтервал перевірки з кожним контактним пунктом постачальника з питань безпеки. Не чекайте на CVE. Їх ще не було, і розрив у таксономії робить їх малоймовірними без тиску з боку галузі. |
|
5. Захист моделі не регулює дії агента |
Opus 4.7 блокує запит на фішинговий лист. Він не блокує агента від читання $ANTHROPIC_API_KEY та публікації його як коментаря PR. Захист контролює генерацію, а не операції. |
Захист фільтрує вивід моделі (текст). Операції агента (bash, git push, curl, API POST) повністю оминають оцінку захисту. Середовище виконання знаходиться поза периметром захисту. Anthropic застосовує деякий захист на рівні середовища виконання у функціях, таких як Claude Code Auto Mode, але вони не документовані в системній картці, і їх охоплення публічно не визначено. |
Агент ніколи не генерував заборонений контент. Він виконав легітимну операцію (публікація коментаря PR), що містить ексфільтровані дані. Захист ніколи не спрацював. |
Відобразіть кожну операцію, яку виконують ваші ШІ-агенти: bash, git, виклики API, запис файлів. Для кожної запитайте у постачальника письмово: чи оцінює ваш рівень захисту цю дію перед виконанням? Задокументуйте відповідь. |
|
6. Недовірений ввід розглядається як інструкції |
Заголовки PR, тіло PR, коментарі до проблем, коментарі до огляду коду та повідомлення комітів — усе це розглядається ШІ-кодинговими агентами як контекст. Будь-який з них може містити ін’єкційні інструкції. |
Відсутній рівень санітизації вводу між GitHub та набором інструкцій агента. Агент не може розрізнити намір розробника від ін’єкції зловмисника в недовірених полях. GitHub Action Claude Code за замовчуванням призначений для довірених вхідних даних першої сторони. Користувачі, які погоджуються обробляти недовірені зовнішні запити, приймають додатковий ризик. |
Один шкідливий заголовок PR став повною командою для ексфільтрації. Агент розглянув його як легітимну інструкцію та виконав без валідації чи підтвердження. |
Впровадьте санітизацію вводу як захист у глибину, але не покладайтеся на традиційні шаблони регулярних виразів типу WAF. Ін’єкції LLM-запитів є недетермінованими і вислизнуть від статичного зіставлення шаблонів. Обмежте контекст агента до затверджених конфігурацій робочого процесу та поєднайте з дозволами найменших привілеїв. |
|
7. Відсутність порівнянних даних про стійкість до ін’єкцій між постачальниками |
Anthropic публікує кількісні показники стійкості до ін’єкцій на 232 сторінках. OpenAI публікує оцінки ін’єкцій на рівні моделі, але не показники стійкості виконання агента. Google публікує картку на кілька сторінок, що посилається на старішу модель. |
Відсутній галузевий стандарт для розкриття метрик безпеки ШІ. Постачальники можуть мати внутрішні метрики та програми червоного тестування, але опубліковані розкриття не є порівнянними. Закупівлі не мають базового рівня та системи для його вимоги. |
Anthropic, OpenAI та Google були схвалені для корпоративного використання без порівнянних даних про стійкість до ін’єкцій. Експлойт виявив, як виглядає не виміряний ризик у виробництві. |
Напишіть одне речення для наступної зустрічі з постачальником: «Покажіть мені вашу кількісну ставку стійкості до ін’єкцій для версії моделі, яку я використовую на платформі, на яку я розгортаю». Задокументуйте відмови для відповідності EU AI Act для високоризикованих систем. Термін: серпень 2026 року. |
GPT-5.4 від OpenAI не було безпосередньо експлуатовано у розкритті “Comment and Control”. Прогалини, виявлені в колонках OpenAI та Google, виведені з того, що не публікується в їхніх системних картках та документації програм, а не з продемонстрованих експлойтів. Ця відмінність важлива. Відсутність опублікованих метрик виконання — це прогалина в прозорості, а не доказ вразливості. Це означає, що команди закупівель не можуть перевірити те, що вони не можуть виміряти.
Вимоги до відповідності Програмі верифікації кібербезпеки Anthropic (Cyber Verification Program) та Trusted Access for Cyber від OpenAI все ще розвиваються, як і покриття платформ та охоплення програм, тому команди безпеки повинні перевіряти актуальні документи постачальників, перш ніж вважати будь-яке описане тут покриття остаточним. CVP від Anthropic призначений для авторизованих досліджень у сфері наступальної безпеки — усунення засобів кіберзахисту для перевірених учасників — і не є програмою захисту від ін’єкцій запитів. Керівники безпеки, зіставляючи ці прогалини з існуючими структурами, можуть узгодити класи загроз 1–3 з NIST CSF 2.0 GV.SC (Управління ризиками ланцюжка поставок), клас загрози 4 з ID.RA (Оцінка ризиків), а класи загроз 5–7 з PR.DS (Безпека даних).
“Comment and Control” сьогодні зосереджений на GitHub Actions, але сім класів загроз узагальнюються для більшості середовищ виконання CI/CD, де ШІ-агенти виконуються з доступом до секретів, включаючи GitHub Actions, GitLab CI, CircleCI та користувацькі раннери. Формати розкриття метрик безпеки змінюються у всіх трьох постачальників; Anthropic наразі лідирує за опублікованою кількісною оцінкою у своїй документації системної картки, але норми, ймовірно, будуть узгоджуватися з набуттям чинності зобов’язань EU AI Act. “Comment and Control” націлювався на GitHub Action Claude Code, конкретну функцію продукту, а не на моделі Anthropic загалом. Однак, клас уразливостей застосовується до будь-якого ШІ-кодингового агента, що працює в середовищі виконання CI/CD з доступом до секретів.
Що робити до наступного поновлення контракту з постачальником
«Не стандартизуйте модель. Стандартизуйте архітектуру контролю», — сказала Бер VentureBeat. «Ризик є системним для дизайну агента, а не специфічним для постачальника. Підтримуйте портативність, щоб ви могли змінювати моделі без переробки вашої безпекової позиції».
Створіть карту розгортання. Підтвердьте, що ваша платформа відповідає вимогам захисту середовища виконання, який, як ви думаєте, вас покриває. Якщо ви використовуєте Opus 4.7 на Bedrock, запитайте свого представника Anthropic, які захисти від ін’єкцій запитів на рівні середовища виконання застосовуються до вашої поверхні розгортання. Напишіть електронного листа своєму представнику сьогодні. (Програма верифікації кібербезпеки Anthropic)
Аудитуйте кожен раннер на предмет розкриття секретів. Виконайте `grep -r ‘secrets.’ .github/workflows/` у кожному репозиторії з ШІ-кодинговим агентом. Перелічіть усі секрети, до яких агент має доступ. Змініть усі розкриті облікові дані. (Документація секретів GitHub Actions)
Почніть міграцію облікових даних зараз. Переключіть збережені секрети на видачу короткоживучих OIDC-токенів. GitHub Actions, GitLab CI та CircleCI підтримують OIDC-федерацію. Встановіть час життя токенів на хвилини, а не години. Плануйте повне розгортання протягом одного-двох кварталів, починаючи з репозиторіїв, що використовують ШІ-агенти. (Документація GitHub OIDC | Документація GitLab OIDC | Документація CircleCI OIDC)
Виправте дозволи агентів по кожному репозиторію. Видаліть виконання bash з усіх ШІ-агентів, що виконують огляд коду. Встановіть доступ до репозиторію лише для читання. Обмежте доступ на запис через крок схвалення людиною. (Документація дозволів GitHub Actions)
Додайте санітизацію вводу як один рівень, а не єдиний. Фільтруйте заголовки запитів на злиття, коментарі та теми оглядів на наявність шаблонів інструкцій перед тим, як вони потраплять до агентів. Поєднуйте з дозволами найменших привілеїв та OIDC. Статичні регулярні вирази самі по собі не вловлять недетерміновані ін’єкції запитів.
Додайте «Середовище виконання ШІ-агентів» до вашого реєстру ризиків ланцюжка поставок. Встановіть 48-годинний термін перевірки виправлень із кожним контактним пунктом постачальника з питань безпеки. Не чекайте на CVE. Їх ще не було для цього класу вразливостей.
Перевірте, які захищені запобіжники GitHub Actions у вас вже на місці. Захищені конфігурації GitHub Actions блокують цей клас атак сьогодні: ключ `permissions` обмежує сферу дії GITHUB_TOKEN, правила захисту середовища вимагають схвалення перед введенням секретів, а ворота для нових учасників запобігають запуску робочих процесів агентів зовнішніми запитами. (Посібник із захисту GitHub Actions)
Підготуйте одне запитання для закупівлі для кожного постачальника перед наступним поновленням. Напишіть одне речення: «Покажіть мені вашу кількісну ставку стійкості до ін’єкцій для версії моделі, яку я використовую на платформі, на яку я розгортаю». Задокументуйте відмови для відповідності EU AI Act для високоризикованих систем. Термін — серпень 2026 року.
«Сирі нульові дні — це не те, як компрометуються більшість систем. Компонування — це воно», — сказала Бер. «Це клейовий код, токени в CI, надмірно дозволені агенти. Коли ви підключаєте потужну модель до дозвільного середовища виконання, ви вже зробили більшу частину роботи зловмисника за них».
Як захиститися (Порада ІТ-Блогу): Завжди використовуйте двофакторну автентифікацію (2FA) для всіх своїх онлайн-акаунтів, особливо для тих, що містять конфіденційну інформацію. Також, будьте вкрай обережні з електронними листами та повідомленнями, що містять підозрілі посилання чи вкладення, оскільки це може бути фішинговою атакою.
Дізнатися більше на: venturebeat.com