Специалисты компании Noma Security обнаружили способ заставить ИИ-агентов GitHub раскрывать содержимое приватных репозиториев через обычный публичный issue. Технику назвали GitLost. Самое неприятное в этой истории — атакующему не нужны ни украденные пароли, ни доступ к организации. Достаточно уметь создать тикет, который выглядит как рутинная просьба.
Речь идёт о GitHub Agentic Workflows — функции, которую GitHub запустил в феврале и до сих пор держит в публичном превью. Идея простая: вместо написания скриптов автоматизации разработчик просто пишет инструкции на обычном английском в Markdown-файле. Дальше агент сам читает issues и pull requests, запускает нужные инструменты и отвечает пользователям. Под капотом может работать GitHub Copilot, Claude от Anthropic, Gemini от Google или Codex от OpenAI — на выбор.
По умолчанию у агента доступ только на чтение. Но здесь и кроется проблема: чтобы агент понимал контекст всей организации, ему часто выдают токен с доступом на чтение сразу ко всем репозиториям, включая приватные. Именно эту настройку и эксплуатирует GitLost.
Механика атаки строится на давно известной уязвимости — непрямой инъекции промптов. ИИ физически не способен надёжно отличить инструкцию от владельца репозитория от инструкции, спрятанной в тексте, который он просто читает. В proof-of-concept от Noma злоумышленник замаскировал вредоносный issue под обращение «вице-президента по продажам после встречи с клиентом». Рабочий процесс срабатывал в момент назначения issue исполнителю — агент читал текст и отвечал комментарием. Проблема в том, что у этого же workflow был доступ на чтение к другим репозиториям организации. В результате после стандартного назначения тикета агент вытащил README из приватного репозитория и вставил его прямо в публичный комментарий.
GitHub, к слову, честно предупреждает в документации: агентов можно манипулировать через инъекции промптов, вредоносное содержимое репозиториев или скомпрометированные инструменты. Компания встроила несколько защитных механизмов — песочницу, токены с доступом только на чтение по умолчанию, очистку входных данных и отдельный шаг проверки на угрозы, который сканирует ответ агента перед публикацией. Но, как сообщили в Noma, всю эту многослойную защиту удалось обойти изменением одного-единственного слова в тексте issue.
Sasi Levi, руководитель направления security research в Noma Security, объяснил разницу между старыми и новыми атаками в комментарии для The Hacker News: «Ранние примеры инъекций промптов были в основном про манипуляцию тем, что агент говорит. GitLost — про манипуляцию тем, что агент делает со своими правами доступа». По его словам, агент — это фактически «доверенный актор с учётными данными, сидящий внутри инфраструктуры, смежной с CI/CD организации», причём с доступом на чтение к репозиториям, которые сам атакующий даже не видит. Для атаки не требуется ни доступ к серверу, ни украденные пароли, ни права на запись в приватные данные — только возможность открыть публичный issue.
Левай использует термин «смертельное трио», придуманный разработчиком Simon Willison: агент, который одновременно может дотянуться до приватных данных, принимает недоверенный внешний контент и имеет канал для отправки данных наружу. Комбинация всех трёх факторов и создаёт путь для утечки. По формулировке Левая, это не баг, который можно залатать патчем, а «структурное следствие того, что ИИ-агентам выдают постоянные учётные данные, заставляя их при этом читать текст, доступный атакующему».
GitLost не единственный случай подобного рода. The Hacker News описывает целую серию похожих исследований. У Anthropic нашли уязвимость в Claude Code GitHub Action, где вредоносный issue заставлял агента раскрывать секреты и захватывать права на запись в репозиторий. Компания Orca Security обнаружила технику под названием RoguePilot: скрытый промпт в issue заставлял GitHub Copilot слить привилегированный токен репозитория. Ещё в мае 2025 года Invariant Labs показали атаку на GitHub MCP-сервер — публичный issue заставлял агента прочитать приватный репозиторий и слить его содержимое через pull request; исследователи тогда назвали проблему архитектурной и заявили, что патч на стороне сервера здесь невозможен в принципе. Наконец, кросс-вендорное исследование «Comment and Control» показало, как через текст issue или pull request можно заставить агентов Claude Code, Gemini CLI и GitHub Copilot слить собственные API-ключи в обход runtime-защиты GitHub.
Noma раскрыла информацию о GitLost компании GitHub и опубликовала результаты исследования с её ведома. Под угрозой находятся организации, которые одновременно включили превью-функцию, подключили агента к чтению недоверенного публичного контента, выдали этому агенту доступ на чтение к приватным репозиториям и разрешили публиковать ответы публично. В зависимости от того, насколько широкий токен выдан агенту, злоумышленник может получить доступ к проприетарному исходному коду, внутренним ключам, документации по дизайну продукта и секретам CI/CD. Левай подчеркнул, что токен, ограниченный одним репозиторием, «значительно менее опасен», чем токен с широким доступом на чтение по всей организации, который часто выдают просто ради удобства.
Из практических рекомендаций Noma выделяет несколько пунктов. Токены нужно ограничивать конкретным репозиторием, для которого настроен workflow, а не выдавать доступ ко всей организации. Публично работающему workflow стоит жёстко ограничить, что именно он может публиковать — комментарий как раз и служит каналом утечки, поэтому запись данных должна проходить только через заранее объявленные «безопасные выходы». Имеет смысл ограничивать круг авторов, чьи тексты агент вообще будет обрабатывать, и добавлять ручную проверку перед публикацией ответов агента. Встроенные фильтры GitHub стоит воспринимать как страховочную сетку, а не как надёжную границу — случай с обходом защиты изменением одного слова это наглядно доказывает.
Корень проблемы, по мнению Левая, в самой природе естественного языка: в отличие от структурированных языков вроде SQL, здесь нет чёткой границы между данными и инструкцией. Это значит, что фильтрация инъекций сама по себе проблему не решит — нужна архитектура: изоляция, узко ограниченные учётные данные, поэтапная и человеческая проверка результатов. Пока такой архитектурной границы не существует, любой агент, который читает приватные данные, принимает недоверенный вход и способен публиковать что-то публично, находится в одном хитро сформулированном issue от утечки.
Речь идёт о GitHub Agentic Workflows — функции, которую GitHub запустил в феврале и до сих пор держит в публичном превью. Идея простая: вместо написания скриптов автоматизации разработчик просто пишет инструкции на обычном английском в Markdown-файле. Дальше агент сам читает issues и pull requests, запускает нужные инструменты и отвечает пользователям. Под капотом может работать GitHub Copilot, Claude от Anthropic, Gemini от Google или Codex от OpenAI — на выбор.
По умолчанию у агента доступ только на чтение. Но здесь и кроется проблема: чтобы агент понимал контекст всей организации, ему часто выдают токен с доступом на чтение сразу ко всем репозиториям, включая приватные. Именно эту настройку и эксплуатирует GitLost.
Механика атаки строится на давно известной уязвимости — непрямой инъекции промптов. ИИ физически не способен надёжно отличить инструкцию от владельца репозитория от инструкции, спрятанной в тексте, который он просто читает. В proof-of-concept от Noma злоумышленник замаскировал вредоносный issue под обращение «вице-президента по продажам после встречи с клиентом». Рабочий процесс срабатывал в момент назначения issue исполнителю — агент читал текст и отвечал комментарием. Проблема в том, что у этого же workflow был доступ на чтение к другим репозиториям организации. В результате после стандартного назначения тикета агент вытащил README из приватного репозитория и вставил его прямо в публичный комментарий.
GitHub, к слову, честно предупреждает в документации: агентов можно манипулировать через инъекции промптов, вредоносное содержимое репозиториев или скомпрометированные инструменты. Компания встроила несколько защитных механизмов — песочницу, токены с доступом только на чтение по умолчанию, очистку входных данных и отдельный шаг проверки на угрозы, который сканирует ответ агента перед публикацией. Но, как сообщили в Noma, всю эту многослойную защиту удалось обойти изменением одного-единственного слова в тексте issue.
Sasi Levi, руководитель направления security research в Noma Security, объяснил разницу между старыми и новыми атаками в комментарии для The Hacker News: «Ранние примеры инъекций промптов были в основном про манипуляцию тем, что агент говорит. GitLost — про манипуляцию тем, что агент делает со своими правами доступа». По его словам, агент — это фактически «доверенный актор с учётными данными, сидящий внутри инфраструктуры, смежной с CI/CD организации», причём с доступом на чтение к репозиториям, которые сам атакующий даже не видит. Для атаки не требуется ни доступ к серверу, ни украденные пароли, ни права на запись в приватные данные — только возможность открыть публичный issue.
Левай использует термин «смертельное трио», придуманный разработчиком Simon Willison: агент, который одновременно может дотянуться до приватных данных, принимает недоверенный внешний контент и имеет канал для отправки данных наружу. Комбинация всех трёх факторов и создаёт путь для утечки. По формулировке Левая, это не баг, который можно залатать патчем, а «структурное следствие того, что ИИ-агентам выдают постоянные учётные данные, заставляя их при этом читать текст, доступный атакующему».
GitLost не единственный случай подобного рода. The Hacker News описывает целую серию похожих исследований. У Anthropic нашли уязвимость в Claude Code GitHub Action, где вредоносный issue заставлял агента раскрывать секреты и захватывать права на запись в репозиторий. Компания Orca Security обнаружила технику под названием RoguePilot: скрытый промпт в issue заставлял GitHub Copilot слить привилегированный токен репозитория. Ещё в мае 2025 года Invariant Labs показали атаку на GitHub MCP-сервер — публичный issue заставлял агента прочитать приватный репозиторий и слить его содержимое через pull request; исследователи тогда назвали проблему архитектурной и заявили, что патч на стороне сервера здесь невозможен в принципе. Наконец, кросс-вендорное исследование «Comment and Control» показало, как через текст issue или pull request можно заставить агентов Claude Code, Gemini CLI и GitHub Copilot слить собственные API-ключи в обход runtime-защиты GitHub.
Noma раскрыла информацию о GitLost компании GitHub и опубликовала результаты исследования с её ведома. Под угрозой находятся организации, которые одновременно включили превью-функцию, подключили агента к чтению недоверенного публичного контента, выдали этому агенту доступ на чтение к приватным репозиториям и разрешили публиковать ответы публично. В зависимости от того, насколько широкий токен выдан агенту, злоумышленник может получить доступ к проприетарному исходному коду, внутренним ключам, документации по дизайну продукта и секретам CI/CD. Левай подчеркнул, что токен, ограниченный одним репозиторием, «значительно менее опасен», чем токен с широким доступом на чтение по всей организации, который часто выдают просто ради удобства.
Из практических рекомендаций Noma выделяет несколько пунктов. Токены нужно ограничивать конкретным репозиторием, для которого настроен workflow, а не выдавать доступ ко всей организации. Публично работающему workflow стоит жёстко ограничить, что именно он может публиковать — комментарий как раз и служит каналом утечки, поэтому запись данных должна проходить только через заранее объявленные «безопасные выходы». Имеет смысл ограничивать круг авторов, чьи тексты агент вообще будет обрабатывать, и добавлять ручную проверку перед публикацией ответов агента. Встроенные фильтры GitHub стоит воспринимать как страховочную сетку, а не как надёжную границу — случай с обходом защиты изменением одного слова это наглядно доказывает.
Корень проблемы, по мнению Левая, в самой природе естественного языка: в отличие от структурированных языков вроде SQL, здесь нет чёткой границы между данными и инструкцией. Это значит, что фильтрация инъекций сама по себе проблему не решит — нужна архитектура: изоляция, узко ограниченные учётные данные, поэтапная и человеческая проверка результатов. Пока такой архитектурной границы не существует, любой агент, который читает приватные данные, принимает недоверенный вход и способен публиковать что-то публично, находится в одном хитро сформулированном issue от утечки.