Исследователи из Noma Security 7 июля описали уязвимость GitLost: достаточно завести Issue в публичном репозитории GitHub, чтобы AI-агент внутри корпоративного workflow сам полез в приватные репозитории и вынес оттуда данные. Для команд, которые уже подключили agentic-автоматизацию к GitHub Actions, это плохая новость без привычной прелюдии в виде украденного аккаунта или RCE.
Речь идет о GitHub Agentic Workflows, где GitHub Actions работают в связке с AI-агентом на базе Claude или GitHub Copilot. Такой агент читает issue, вызывает инструменты, пишет комментарии и, если ему это разрешили, ходит по другим репозиториям внутри организации. Как пишет Dark Reading, именно эта комбинация естественного языка, широких прав и доверия к пользовательскому тексту открыла дорогу prompt injection-атаке, которую исследователи и назвали уязвимостью GitLost.
Сценарий атаки выглядит неприятно простым. Уязвимый workflow срабатывал на событие issues.assigned, читал заголовок и тело issue, затем публиковал ответ через инструмент добавления комментария и имел права на чтение других репозиториев организации, в том числе приватных. Этого оказалось достаточно: злоумышленник без аутентификации, без токенов и без навыков программирования создает issue в публичном репозитории и прячет в тексте обычные англоязычные инструкции. Дальше агент воспринимает их не как недоверенный ввод, а как команду к действию. В proof-of-concept исследователи таким способом добились утечки приватной информации о внутренней встрече сотрудников.
С технической точки зрения история почти учебная, но от этого не менее токсичная. Классическая автоматизация обычно живет в жестких границах: код, правила, API, проверяемые условия. В agentic-подходе эти границы размываются, потому что системные инструкции и пользовательский текст оказываются в одном контекстном окне. Руководитель исследований безопасности Noma Саси Леви формулирует проблему предельно точно: контекстное окно агента одновременно становится и его рабочей памятью, и поверхностью атаки. Если агент читает issues, pull request, комментарии или файлы, то любой такой контент можно превратить в вредоносную инструкцию, если система не удерживает четкую границу доверия.
Это и есть самый важный вывод из истории с GitLost: проблема не сводится к одной неудачной конфигурации GitHub. Джейсон Сороко из Sectigo в комментарии Dark Reading прямо говорит о смене архитектуры доверия. Когда разработчики начинают использовать естественный язык как интерфейс для инфраструктурных действий, они невольно смешивают в одном потоке внутренние указания и внешний шум. Для атакующего это почти подарок: не нужно ломать систему в привычном смысле, достаточно убедить ее самой обойти собственные ограждения. И если у такого агента уже есть standing credentials и доступ к нескольким репозиториям, цена ошибки резко растет. Особенно для компаний, где в приватных репах лежат не только код, но и спецификации, внутренние заметки, инженерные документы, данные по клиентским интеграциям и следы продуктовых решений.
GitHub, по данным публикации, получил уведомление от исследователей в рамках responsible disclosure. На момент выхода материала компания не ответила изданию, устранена ли проблема окончательно. Noma при этом отмечает, что GitHub обновил документацию, на основе которой создавался уязвимый сценарий, и при последней проверке опасной инструкции там уже не было. Формально это выглядит как правка примера, а не как фундаментальное исправление класса уязвимостей. И в этом, пожалуй, весь нерв истории: даже если конкретный шаблон починили, сам подход с агентом, который читает атакуемый текст и одновременно обладает широкими правами, никуда не делся.
Для русскоязычных команд выводы максимально прикладные. Если в компании GitHub Actions уже обросли AI-агентами, первым делом стоит проверить, какие события запускают workflow и какой пользовательский контент агент читает без фильтрации. Второй вопрос еще важнее: зачем агенту доступ к другим репозиториям организации и действительно ли ему нужен публичный вывод результатов. Принцип наименьших привилегий здесь перестает быть скучной мантрой аудиторов и превращается в прямую защиту от утечки интеллектуальной собственности. Если агенту не нужен кросс-репозиторный доступ, его надо убрать. Если нужен, значит, пользовательский текст нельзя воспринимать как инструкцию ни в каком виде. И да, публикация комментариев наружу из workflow с доступом к приватным данным теперь выглядит уже не как удобная автоматизация, а как потенциальный канал эксфильтрации.
Для бизнеса это тоже не нишевая история про безопасность разработчиков. Agentic-инструменты все чаще внедряют не только инженерные команды, но и продуктовые, support и внутренние платформенные группы. Чем шире использование AI-агентов, тем чаще они получают доступ к нескольким системам сразу: код, тикеты, документы, CI/CD, внутренние knowledge base. На таком фоне уязвимость GitLost выглядит не как частный баг, а как ранний маркер новой категории рисков. Раньше компания боялась, что сотрудник случайно откроет лишний доступ в репозитории. Теперь достаточно, чтобы агент с уже выданными правами прочитал чужой текст и решил, что это приказ.
Следующий этап этой гонки, похоже, будет не про еще более разговорчивых агентов, а про более жесткие модели изоляции: разделение системных промптов и пользовательского ввода, ограничение прав по каждому workflow и отказ от идеи, что естественный язык сам по себе безопасен как слой оркестрации. Иначе публичный issue постепенно превращается в новый интерфейс для доступа к внутренним данным компании. Подробности инцидента приводит .