Copilot Autofix відкрив уразливість ін’єкції команд у CI/CD‑конвеєрі Snowflake

Виправлення безпеки, написане Copilot Autofix від GitHub і злитте в репозиторій Snowflake 18 червня 2026 року, видалило шаблон санітизованого вводу та залишило CI/CD‑конвеєр компанії відкритим для ін’єкції команд, а через п’ять днів автономний AI‑дослідницький агент виявив уразливість, використав її та отримав діючі облікові дані Jira з GitHub Actions runner, Wiz Research повідомив 17 серпня 2026.

Уразливість знаходилась у jira_issue.yml, робочому процесі GitHub Actions у snowflakedb/snowflake-connector-net, публічному репозиторії .NET‑конектора даних Snowflake. Робочий процес запускався щоразу, коли хтось відкривав issue у GitHub, і підставляв назву issue (текст, повністю контрольований автором) безпосередньо у shell‑скрипт. Оскільки тригером був issues: opened, будь‑який GitHub‑акаунт в інтернеті міг активувати його без автентифікації.

Red Agent від Wiz, автономний інструмент безпекових досліджень, що працює через програму баг‑баунті HackerOne Snowflake, позначив цей робочий процес, створив працюючий експлойт і ексфільтрував токен Jira API із середовища runner‑а. Snowflake виправив робочий процес того ж дня, коли отримав звіт, 23 червня 2026 року, через день змінив облікові дані і повідомив Wiz, що їхні аудиторські журнали не показали жодних інших акторів, які торкалися відкритих систем протягом п’яти днів.

«Autofix» видалив санітайзер

Коміт, який впровадив ін’єкційний шаблон, потрапив через PR #1218, “SNOW-2069227: Update jira workflows”, злитий 18 червня 2026 року. Історія pull‑request показує, що людський автор працював над автоматизацією Jira з серпня 2025 року — і, на півшляху, був доданий коміт, співавтором якого був Copilot Autofix powered by AI, бот GitHub Advanced Security, який генерує пропозиції виправлень для сповіщень сканування коду.

Пропозиція ШІ змінила спосіб обробки назви issue у робочому процесі. Існуючий код передавав назву через змінну env: і формував JSON‑payload за допомогою jq --arg, що утримувало ненадійний текст поза shell‑ом. Запропонована заміна замінила це прямим розширенням рядка:

“ run: | TITLE=$(echo '${{ github.event.issue.title }}' | sed 's/"/\"/g' | sed "s/'/\'/g") “

Екранування sed виконується після того, як шаблонний движок GitHub вже підставив назву у скрипт. Одинарна лапка в назві виходить за межі обгортки echo '...', і все, що йде після неї, виконується як shell‑команда. Документація Copilot Autofix описує функцію як генерацію «однієї запропонованої виправки для сповіщення, яку ви переглядаєте та застосовуєте самостійно» — саме на етапі перегляду ця виправка пройшла.

У робочому процесі також була умова‑захист, яка виглядала так, ніби обмежує, хто може його запустити:

“ if: (github.event_name == 'issues' && github.event.pull_request.user.login != 'whitesource-for-github-com[bot]') “

Для подій issue github.event.pull_request завжди дорівнює null, тому порівняння завжди повертає true. Таким чином, кожен користувач GitHub проходив цей захист.

Агент з обох боків експлойту

Перший спроба ексфільтрації Red Agent завершилась невдачею. Його payload використав символ коментаря #, щоб «з’їсти» решту ін’єкційного рядка, але коментар також поглинув закриваючу дужку TITLE=$(...), і runner повернув помилку синтаксису bash замість виконання. За даними Wiz, агент проаналізував помилку, переписав payload, закривши блок shell‑у за допомогою ; echo ', і спробував ще раз.

Працюючий payload, переданий у вигляді назви issue, кодував у base64 змінні середовища runner‑а JIRA_API_TOKEN, JIRA_USER_EMAIL та JIRA_BASE_URL і надсилав їх зовнішньому слухачу за допомогою curl. Відповідь прийшла від Azure‑хостованого GitHub Actions runner‑а за кілька секунд.

Отриманий токен автентифікувався як qa@snowflake.net проти snowflakecomputing.atlassian.net, маючи права читання у всіх проектах Snowflake, пов’язаних з інженерією, безпековою відповідністю та програмою баг‑баунті.

Виправлення Snowflake, злитий у PR #1402 23 червня 2026 року, відновив безпечну змінну env: і шаблон парсингу jq --arg. Токен Jira був анульований і змінений 24 червня 2026 року. Wiz заявив, що безпечно видалив усі дані, до яких отримав доступ під час тестування proof‑of‑concept.

«Snowflake цінує відповідальне повідомлення Wiz та співпрацю щодо цих знахідок у рамках нашої програми розкриття вразливостей і баг‑баунті HackerOne», — заявила компанія у заяві, опублікованій разом зі звітом Wiz. «Повідомлення було отримано 23 червня 2026 року, одразу розпочато розслідування та виправлення, і наше розслідування не виявило жодних ознак несанкціонованого доступу».

Що показує п’ятиденне вікно

Розкриття потрапляє в центр задокументованого патерну: зміни, підсилені ШІ, проходять рев’ю швидше, ніж безпекові припущення щодо них. Аудиторські журнали Snowflake саме роблять цей інцидент зрозумілим: вони дозволяють компанії стверджувати, а Wiz підтверджує, що вікно експозиції не призвело до доступу третіх сторін. Аналіз журналів підтвердив, що жодні зовнішні треті сторони не отримали доступ до кінцевої точки протягом п’яти днів.

Таймлайн також стискає послідовність, яку індустрія вважає гіпотетичною. Асистент кодування видалив захисний шаблон, створений спеціально для запобігання ін’єкції команд, бо у нього не було запису, чому цей шаблон існує. Потім атакуючий агент знайшов і озброїв результат за кілька днів, самокорегуючи свій експлойт на основі живих помилок. Сторона експлойту працювала без людини за клавіатурою; у кодувальній стороні ШІ згенерував зміну, але людина застосувала пропозицію і злила її — саме цей етап рев’ю і провалився.

Звіт Wiz рекомендує, щоб AI‑згенеровані pull‑request проходили таку ж статичну аналізу, як і людський код, щоб команди скорочували термін дії облікових даних відповідно до швидкості автоматизованого виявлення, і щоб захисні механізми блокували агентів від заміни структурованих парсерів прямим підставлянням рядків. Check Point перемістив перевірку підказок для AI‑трафіку у корпоративні файрволи на початку літа, а Unite.AI розкрив ексцеди агентських пісочниць та агентські системи, що досягають реальних виробничих цілей у міру зрілості атакуючої сторони. Інцидент Snowflake — це та сама історія, розказана зсередини CI‑конвеєра: уразливість була активною п’ять днів, і єдина причина, чому це сприймається як кейс‑стаді, а не як повідомлення про порушення, — який агент дістався перш за все.