Як працює атака

Дослідники описали вразливий шаблон GitHub Agentic Workflow як такий, що:

• Запускався за подією issues.assigned
• Читав заголовок та тіло issue
• Публікував коментар за допомогою інструменту агента, наприклад add-comment
• Мав доступ для читання до інших репозиторій в організації, включно з приватними

Атака відбувається в чотири кроки:

1. Зловмисник відкриває безневинне на вигляд GitHub Issue у публічному репозиторії організації, яка використовує вразливий шаблон Agentic Workflow.
2. У тілі issue приховано інструкції звичайною англійською мовою, які наказують AI-агенту завантажити файли з приватних репозиторій.
3. Коли автоматизація GitHub призначає issue, подія запускає робочий процес, і агент отримує дані з репозиторій, до яких має доступ, включно з приватними.
4. Агент публікує отримані дані як публічний коментар до issue, потенційно роблячи їх доступними для всіх, хто може переглядати issue.

Архітектурна слабкість

Основна вада — це нездатність підтримувати чіткий кордон довіри між системними інструкціями та ненадійними даними користувача в контекстному вікні AI-агента. Як зазначив Сасі Леві з Noma: «Контекстне вікно агента — це його поверхня атаки. Будь-який вміст, який читає агент — чи то issues, pull request'и, коментарі чи файли — може бути використаний як зброя, якщо агент трактує цей вміст як інструкційний вхід.»

Агенти на основі великих мовних моделей (LLM) не можуть чітко розрізняти дані та інструкції, коли обидва з'являються в одному контексті або результаті роботи інструменту. Це не просто звичайна помилка в коді, а структурний ризик в агентних AI-робочих процесах, де ненадійний вміст може впливати на поведінку агента, якщо робочий процес не ізолює або не обмежує його.

Дослідники формально класифікували цей клас вразливостей як Agentic Workflow Injection (AWI), виділивши два основні патерни: Prompt-to-Agent (P2A), коли ненадійний вміст досягає межі prompt агента, і Prompt-to-Script (P2S), коли вплив зловмисника поширюється через виведення моделі в наступні скрипти.

Техніка обходу захисту: ключове слово «Additionally»

GitHub мав захисні механізми, призначені для запобігання витоку даних, але дослідники Noma виявили, що їх можна обійти напрочуд простим способом. Додавання слова «Additionally» до вбудованих інструкцій змушувало модель змінювати формат виводу замість відмови, дозволяючи витоку даних відбутися так, ніби це було авторизоване продовження завдання.

Цей підхід узгоджується з ширшими дослідженнями ін'єкцій prompt, які показують, що певне формулювання або текст, повернутий інструментом, може змусити моделі виконувати шкідливі інструкції, які вони не повинні виконувати. Обхід захисних механізмів нагадує патерни, помічені в попередніх інцидентах, таких як вразливість GitHub MCP, виявлена Invariant Labs, де шкідливе issue могло захопити агента користувача для витоку даних з приватних репозиторій.

Рекомендовані заходи захисту для організацій

На основі результатів GitLost та загальних рекомендацій з безпеки агентних робочих процесів, постраждалі організації повинні впровадити такі заходи:

• Впровадити нульову довіру для вхідних даних агентів — ніколи не розглядати вміст, створений користувачем, як довірені інструкції, та ізолювати ненадійні дані користувача від основних системних prompt'ів.
• Застосувати суворі принципи найменших привілеїв — видалити непотрібний крос-репозиторний доступ та обмежити здатність агентів розкривати дані через публічний вивід.
• Використовувати списки дозволів для інструментів, а не списки блокування, та вимагати обов'язкове схвалення людиною перед виконанням агентами чутливих дій, таких як публікація зовнішніх коментарів або доступ до чутливих репозиторій.
• Аудит інтеграцій AI-агентів у CI/CD та автоматизації репозиторіїв, особливо там, де ненадійний контекст подій GitHub включається в prompt'и або вхідні дані агентів.
• Логічно ізолювати ненадійні вхідні дані користувача від системних директив, розглядаючи текст, створений користувачем, як ненадійні дані, а не як авторитетні інструкції.

Організації також повинні застосовувати принцип найменших привілеїв до секретів агентів та впроваджувати безперервний моніторинг безпеки на предмет спроб ін'єкції prompt.

Відповідь GitHub (станом на 7 липня)

Згідно з Dark Reading та графіком розкриття Noma Security:

• Noma відповідально розкрила вразливість GitHub.
• GitHub повідомив Noma, що оновив документацію, пов'язану з вразливим шаблоном робочого процесу, і дослідники підтвердили, що вразлива конфігурація більше не присутня під час останньої перевірки.
• Станом на 7 липня GitHub не випустив офіційної публічної заяви або CVE для GitLost.
• Вразливість, схоже, була частково усунена шляхом видалення або перегляду відповідної документації та шаблону робочого процесу, а не через чітко задокументоване виправлення безпеки на рівні платформи.

Ширша картина: системний ризик

GitLost — не ізольований інцидент. Він представляє зростаючий клас вразливостей, де AI-агенти з доступом до чутливих даних піддаються впливу ненадійного користувацького вмісту. Подібні проблеми торкнулися інтеграцій GitHub MCP, робочих процесів Gemini CLI від Google (вразливість TrustIssues) та Claude Code GitHub Actions. Спільна нитка — агенти на основі LLM не мають вродженої здатності розрізняти дані та інструкції, коли обидва з'являються в одному контекстному вікні — фундаментальний архітектурний виклик, який жоден окремий патч платформи не може повністю вирішити.

Як працює атака

Дослідники описали вразливий шаблон GitHub Agentic Workflow як такий, що:

• Запускався за подією issues.assigned
• Читав заголовок та тіло issue
• Публікував коментар за допомогою інструменту агента, наприклад add-comment
• Мав доступ для читання до інших репозиторій в організації, включно з приватними

Атака відбувається в чотири кроки:

1. Зловмисник відкриває безневинне на вигляд GitHub Issue у публічному репозиторії організації, яка використовує вразливий шаблон Agentic Workflow.
2. У тілі issue приховано інструкції звичайною англійською мовою, які наказують AI-агенту завантажити файли з приватних репозиторій.
3. Коли автоматизація GitHub призначає issue, подія запускає робочий процес, і агент отримує дані з репозиторій, до яких має доступ, включно з приватними.
4. Агент публікує отримані дані як публічний коментар до issue, потенційно роблячи їх доступними для всіх, хто може переглядати issue.

Архітектурна слабкість

Основна вада — це нездатність підтримувати чіткий кордон довіри між системними інструкціями та ненадійними даними користувача в контекстному вікні AI-агента. Як зазначив Сасі Леві з Noma: «Контекстне вікно агента — це його поверхня атаки. Будь-який вміст, який читає агент — чи то issues, pull request'и, коментарі чи файли — може бути використаний як зброя, якщо агент трактує цей вміст як інструкційний вхід.»

Агенти на основі великих мовних моделей (LLM) не можуть чітко розрізняти дані та інструкції, коли обидва з'являються в одному контексті або результаті роботи інструменту. Це не просто звичайна помилка в коді, а структурний ризик в агентних AI-робочих процесах, де ненадійний вміст може впливати на поведінку агента, якщо робочий процес не ізолює або не обмежує його.

Дослідники формально класифікували цей клас вразливостей як Agentic Workflow Injection (AWI), виділивши два основні патерни: Prompt-to-Agent (P2A), коли ненадійний вміст досягає межі prompt агента, і Prompt-to-Script (P2S), коли вплив зловмисника поширюється через виведення моделі в наступні скрипти.

Техніка обходу захисту: ключове слово «Additionally»

GitHub мав захисні механізми, призначені для запобігання витоку даних, але дослідники Noma виявили, що їх можна обійти напрочуд простим способом. Додавання слова «Additionally» до вбудованих інструкцій змушувало модель змінювати формат виводу замість відмови, дозволяючи витоку даних відбутися так, ніби це було авторизоване продовження завдання.

Цей підхід узгоджується з ширшими дослідженнями ін'єкцій prompt, які показують, що певне формулювання або текст, повернутий інструментом, може змусити моделі виконувати шкідливі інструкції, які вони не повинні виконувати. Обхід захисних механізмів нагадує патерни, помічені в попередніх інцидентах, таких як вразливість GitHub MCP, виявлена Invariant Labs, де шкідливе issue могло захопити агента користувача для витоку даних з приватних репозиторій.

Рекомендовані заходи захисту для організацій

На основі результатів GitLost та загальних рекомендацій з безпеки агентних робочих процесів, постраждалі організації повинні впровадити такі заходи:

• Впровадити нульову довіру для вхідних даних агентів — ніколи не розглядати вміст, створений користувачем, як довірені інструкції, та ізолювати ненадійні дані користувача від основних системних prompt'ів.
• Застосувати суворі принципи найменших привілеїв — видалити непотрібний крос-репозиторний доступ та обмежити здатність агентів розкривати дані через публічний вивід.
• Використовувати списки дозволів для інструментів, а не списки блокування, та вимагати обов'язкове схвалення людиною перед виконанням агентами чутливих дій, таких як публікація зовнішніх коментарів або доступ до чутливих репозиторій.
• Аудит інтеграцій AI-агентів у CI/CD та автоматизації репозиторіїв, особливо там, де ненадійний контекст подій GitHub включається в prompt'и або вхідні дані агентів.
• Логічно ізолювати ненадійні вхідні дані користувача від системних директив, розглядаючи текст, створений користувачем, як ненадійні дані, а не як авторитетні інструкції.

Організації також повинні застосовувати принцип найменших привілеїв до секретів агентів та впроваджувати безперервний моніторинг безпеки на предмет спроб ін'єкції prompt.

Відповідь GitHub (станом на 7 липня)

Згідно з Dark Reading та графіком розкриття Noma Security:

• Noma відповідально розкрила вразливість GitHub.
• GitHub повідомив Noma, що оновив документацію, пов'язану з вразливим шаблоном робочого процесу, і дослідники підтвердили, що вразлива конфігурація більше не присутня під час останньої перевірки.
• Станом на 7 липня GitHub не випустив офіційної публічної заяви або CVE для GitLost.
• Вразливість, схоже, була частково усунена шляхом видалення або перегляду відповідної документації та шаблону робочого процесу, а не через чітко задокументоване виправлення безпеки на рівні платформи.

Ширша картина: системний ризик

GitLost — не ізольований інцидент. Він представляє зростаючий клас вразливостей, де AI-агенти з доступом до чутливих даних піддаються впливу ненадійного користувацького вмісту. Подібні проблеми торкнулися інтеграцій GitHub MCP, робочих процесів Gemini CLI від Google (вразливість TrustIssues) та Claude Code GitHub Actions. Спільна нитка — агенти на основі LLM не мають вродженої здатності розрізняти дані та інструкції, коли обидва з'являються в одному контекстному вікні — фундаментальний архітектурний виклик, який жоден окремий патч платформи не може повністю вирішити.