AI-агент Wiz знайшов у Snowflake вразливість, яку пропустив Copilot Autofix

Wiz Research повідомляє, що її автономний інструмент дослідження безпеки Red Agent виявив і використав критичну вразливість GitHub Actions у публічному репозиторії Snowflake. Звіт подано через програму розкриття HackerOne, результати опубліковано 17 серпня 2026 року.

Уразливий workflow

Проблема була в jira_issue.yml у репозиторії snowflakedb/snowflake-connector-net. Workflow запускався на будь-який новий issue у GitHub і підставляв контрольований атакуючим заголовок issue прямо в shell-скрипт. Оскільки розгортання шаблону GitHub відбувається до escaping у sed, один апостроф у заголовку виводить з лапок рядок echo і дозволяє виконати довільні команди. Помилка стала активною 18 червня 2026 року, коли злили PR #1218 — за п'ять днів до її виявлення.

Як діяв агент

Red Agent відкрив issue, заголовок якого виводив облікові дані Jira через out-of-band callback. Перша спроба не вдалася: символ # став коментарем і «з'їв» закриваючу дужку TITLE=$(...), спричинивши синтаксичну помилку bash. Агент самостійно проаналізував помилку, змінив payload на "; echo '" і за кілька секунд отримав зворотний виклик із GitHub Actions runner на Azure IP 20.106.182.197 із закодованими в base64 даними.

Чому автоматичні перевірки мовчали

Викрадений токен автентифікувався як [email protected] на snowflakecomputing.atlassian.net і давав доступ на читання до проєктів інженерії, комплаєнсу безпеки та bug bounty Snowflake. У workflow була «захисна» умова, що звіряла логін за github.event.pull_request.user.login, але для подій типу issues це поле завжди null, тож умова завжди істинна. GitHub Advanced Security просканував фінальну ревізію і не позначив ін'єкцію, а злитий PR замінив безпечний шаблон env: + jq прямою інтерполяцією.

Реакція та висновки

Snowflake виправила workflow того ж дня (commit 1dc7766, PR #1402) і 24 червня відкликала та замінила токен Jira; аудит-логи показали, що за п'ять днів експозиції сторонні доступу не отримали. Wiz зазначає, що Copilot був співавтором, який переглянув змінений код і визнав його чистим; невідомо, чи сам код писався з допомогою AI. Висновок: AI-згенеровані pull request-и потребують такої ж статичної перевірки, як людський код, а скорочення вікон виявлення вимагає швидких патчів і короткочасних облікових даних.