ИИ «починил» — и сломал

Автономный AI-агент Wiz Research под названием Red Agent обнаружил критическую уязвимость в публичном GitHub-репозитории Snowflake. Брешь была внесена коммитом GitHub Copilot Autofix и позволяла выполнять произвольные команды через заголовок GitHub-issue. Wiz эксплуатировал её и добрался до внутреннего Jira компании всего за пять дней.

⚠ Парадокс
Инструмент GitHub Copilot Autofix создан для того, чтобы исправлять уязвимости в коде — но именно он и внёс критическую брешь в репозиторий Snowflake.

Как это произошло

Уязвимый коммит

Инъекционный паттерн появился 18 июня 2026 года в коммите 4a1b8ce (PR #1218: «SNOW-2069227: Update jira workflows»), соавтором которого значится Copilot Autofix.

GitHub Copilot Autofix убрал существующий безопасный шаблон обработки входных данных и заменил его прямым раскрытием строки в shell-скрипте. Конкретно — вместо передачи заголовка issue через переменную окружения (env:) код перестал использовать безопасную схему с jq и стал напрямую подставлять ${{ github.event.issue.title }} в блок run:.

# Уязвимый паттерн, внесённый Copilot Autofix
run: |
  TITLE=$(echo '${{ github.event.issue.title }}' | sed 's/"/"/g')

«ИИ-коммит с “автоисправлением” сам создал вектор для инъекции.» — Wiz Research

Обход защитного условия

Workflow содержал if:-условие, которое выглядело как защита, но на issues-событиях github.event.pull_request всегда равен null — условие фактически не работало.

Эксплуатация Red Agent

Red Agent — автономный ИИ-атакующий Wiz для offensive security — нашёл уязвимость в GitHub Actions во время планового сканирования публичных репозиториев 23 июня.

В ходе инцидента Red Agent использовал уязвимость script injection в snowflakedb/snowflake-connector-net: любой неаутентифицированный пользователь мог выполнить произвольные команды в GitHub Actions runner, открыв issue со специально сформированным заголовком.

Исследователи получили out-of-band callback от GitHub Actions runner и завладели Jira API-токеном workflow. Токен принадлежал qa@snowflake.net и давал доступ на чтение к проектам по инженерии, security compliance и bug bounty на snowflakecomputing.atlassian.net.


sequenceDiagram
    participant CA as Copilot Autofix
    participant GH as GitHub (Snowflake repo)
    participant RA as Wiz Red Agent
    participant JI as Snowflake Jira

    CA->>GH: 18 июня: PR #1218 — уязвимый коммит
    Note over GH: jira_issue.yml: ${{ github.event.issue.title }} → run: block
    RA->>GH: 23 июня: открывает issue со специальным заголовком
    GH->>RA: out-of-band callback с Jira API-токеном
    RA->>JI: Чтение инженерных и security-проектов
    RA->>GH: Responsible disclosure через HackerOne
    GH->>GH: Патч в тот же день — PR #1402

Хронология инцидента

ДатаСобытие
18 июня 2026Уязвимость появляется с коммитом PR #1218 (соавтор — Copilot Autofix)
23 июня 2026Wiz Red Agent находит, эксплуатирует и сообщает о проблеме через HackerOne
23 июня 2026Snowflake выпускает патч в тот же день (PR #1402)
24 июня 2026Ротация скомпрометированного Jira API-токена
25 июля 2026Дедлайн публичного раскрытия по политике Snowflake (30 дней)
18 августа 2026Публичная публикация отчёта Wiz

18 июня уязвимость стала активной — PR #1218 был смерджен. 23 июня Wiz идентифицировал, эксплуатировал и сообщил об уязвимости через HackerOne. В тот же день Snowflake выпустил патч, восстановив безопасный паттерн env: + jq --arg.

Спорный момент: кто виноват?

ℹ Нюанс атрибуции
Wiz утверждает, что уязвимость внёс Copilot Autofix. The Hacker News указывает, что история коммитов не подтверждает авторство Copilot именно в уязвимых строках.

Явный коммит Copilot (6d0e2fa) менял jira_close.yml, тогда как уязвимый рефакторинг jira_issue.yml числится за пользователем sfc-gh-hpathak. Оба изменения вошли в squash merge коммит 4a1b8ce от 18 июня, в соавторах которого и фигурирует Copilot Autofix. История коммитов подтверждает участие Copilot в PR #1218, но не авторство уязвимых строк.

Snowflake заявила, что «расследование не выявило признаков несанкционированного доступа».

Как защититься

💡 Рекомендации по безопасности GitHub Actions
  • Не вставляйте ${{ github.event.issue.title }} и другие данные из events напрямую в блок run: — только через env: переменные
  • Используйте инструмент zizmor для статического анализа workflows на template injection
  • Относитесь к AI-сгенерированным коммитам как к внешним pull request: обязательный code review
  • Аудитируйте CI/CD pipelines так же строго, как и основной код приложения

Любой workflow, триггерящийся на issues, issue_comment, pull_request_target или discussion и подставляющий ${{ github.event.* }} в блок run:, эксплуатируется тем же способом.

GitHub документировал этот класс уязвимостей ещё в июле 2025 года, предупреждая о раскрытии данных из issues в блоках run: и рекомендуя промежуточные переменные окружения.

Значение для отрасли

Инцидент подчёркивает растущую способность ИИ находить и эксплуатировать уязвимости без участия человека. Случай наглядно показывает: один ИИ-агент нашёл и эксплуатировал уязвимость в коде, которую пропустил другой ИИ-агент.

Эксперты предупреждают: AI-assisted разработка расширяет поверхность атаки, делая человеческий надзор и проактивное AI-сканирование уязвимостей обязательными — мы вступаем в эпоху «AI vs AI».

📝 Главный урок
Автоматические исправления ИИ — не серебряная пуля. Каждый AI-коммит в CI/CD пайплайн требует такого же критического review, как и код от незнакомого разработчика. Доверяй, но проверяй — особенно когда «проверяет» тоже ИИ.