Дослідники компанії Wiz виявили вразливість типу workflow injection у публічному репозиторії snowflakedb/snowflake-connector-net на GitHub, яка дозволяла зловмиснику виконати довільні команди в середовищі GitHub Actions runner, лише створивши спеціально сформований Issue. У ході авторизованого тестування дослідники витягли Jira API-токен, який, за їхніми даними, надавав доступ на читання до внутрішніх проєктів Snowflake, зокрема до інженерних задач, відстеження відповідності вимогам безпеки та bug bounty. Вразливість існувала в CI/CD-автоматизації репозиторію п’ять днів — з 18 по 23 червня 2026 року — і була усунута в день отримання звіту. Не було виявлено релізів конектора для .NET, які б були зачеплені цією проблемою.
Механізм вразливості
Проблема містилася у файлі .github/workflows/jira_issue.yml, який запускалася під час відкриття публічного Issue в репозиторії. Workflow містив дві критичні помилки:
- Пряма інтерполяція користувацького вводу в shell-блок: заголовок і тіло Issue підставлялися безпосередньо в блок
run:, що створювало класичний вектор ін’єкції команд. Зловмисник міг впровадити довільні shell-команди через текст Issue. - Непрацююча перевірка авторизації: workflow перевіряв значення
github.event.pull_request.user.login, хоча тригером події був Issue, а не Pull Request. Згідно з документацією GitHub, звернення до неіснуючої властивості контексту повертає порожній рядок. У результаті порівняння зwhitesource-for-github-com[bot]ніколи не спрацьовувало як фільтр, і будь-який користувач міг запустити виконання workflow.
У тому ж кроці workflow були доступні секрети JIRA_BASE_URL, JIRA_USER_EMAIL і JIRA_API_TOKEN, що означало: успішна ін’єкція команд автоматично надавала доступ до цих облікових даних.
Експлуатація та масштаб впливу
За даними Wiz, їхня автоматизована система Red Agent виявила та експлуатувала вразливість у ході авторизованого тестування безпеки. Початкова корисна нагрузка спричинила синтаксичну помилку shell, після чого система адаптувала підхід. Дослідники повідомляють, що отримали out-of-band callback від GitHub Actions runner і витягли Jira API-токен.
Згідно зі звітом Wiz, токен належав обліковому запису [email protected] і надавав доступ на читання до проєктів Jira на домені snowflakecomputing.atlassian.net, що охоплювали інженерні задачі, відстеження відповідності вимогам безпеки та bug bounty. Слід зазначити, що деталі експлуатації та обсяг отриманих прав ґрунтуються виключно на заявах Wiz — публічні журнали аудиту Snowflake не були оприлюднені.
Хронологія та усунення
- 18 червня 2026 р. — уразливий workflow потрапив до основної гілки через pull request #1218 (squash merge, коміт
4a1b8ce). - 23 червня 2026 р. — Wiz надіслала звіт через HackerOne (report #3819931). Того ж дня Snowflake застосувала виправлення в pull request #1402, замінивши пряму підстановку виразів GitHub на передавання значень через змінні середовища в
jq. - 24 червня 2026 р. — за даними Wiz, токен Jira було ротовано.
Snowflake у заяві, процитованій Wiz, зазначила, що розслідування «не виявило свідчень несанкціонованого доступу». За інформацією Wiz, перевірка Snowflake не виявила стороннього використання токена за п’ятиденне вікно експозиції. Водночас аудиторські журнали Snowflake не були опубліковані, тож незалежна верифікація цих тверджень неможлива.
Питання атрибуції: роль GitHub Copilot
Wiz описала вразливість як результат зміни, внесеної GitHub Copilot Autofix. Проте аналіз історії комітів у репозиторії демонструє складнішу картину. Коміт 6d0e2fa, явно позначений як співавторський із Copilot Autofix, змінював файл jira_close.yml, а не уразливий jira_issue.yml. Небезпечний рефакторинг jira_issue.yml міститься в окремому коміті 094038e, атрибутованому в GitHub розробнику sfc-gh-hpathak. Обидві зміни увійшли до підсумкового squash merge 4a1b8ce, де Copilot Autofix вказаний серед співавторів. Таким чином, участь Copilot у pull request підтверджується, але авторство саме уразливих рядків коду — ні.
Системна проблема та рекомендації
Цей інцидент — типовий приклад класу вразливостей, задокументованого GitHub ще в липні 2025 року: пряма підстановка ненадійних даних із подій (Issue title, body, коментарі) у блоки run: GitHub Actions. Рекомендований підхід — використання проміжних змінних середовища, що й було реалізовано у виправленні Snowflake.
Організаціям, які використовують GitHub Actions у публічних репозиторіях, варто:
- Провести аудит усіх workflow-файлів на предмет прямої інтерполяції виразів
${{ github.event.* }}всередині блоківrun:. Будь-які дані з Issue, Pull Request або коментарів мають передаватися через змінні середовища. - Перевірити умови фільтрації у workflow: переконатися, що перевірки авторизації посилаються на властивості, які існують у контексті фактичної події-тригера. Невідповідність типу події та перевірюваної властивості призводить до обходу фільтра.
- Мінімізувати область видимості секретів: не передавати облікові дані до кроків, що обробляють користувацький ввід. Розділяти кроки валідації вхідних даних і кроки, які використовують секрети.
- Запровадити автоматизоване сканування workflow-файлів — наприклад, за допомогою інструментів на кшталт
actionlint— для виявлення небезпечних патернів інтерполяції на етапі code review.
Цей випадок демонструє, що навіть за відсутності вразливості в самому програмному продукті компрометація CI/CD-інфраструктури публічного репозиторію може призвести до витоку внутрішніх облікових даних із доступом до корпоративних систем. П’ятиденне вікно експозиції та оперативне виправлення в день отримання звіту — позитивний приклад реагування, але сам факт потрапляння небезпечного коду до основної гілки вказує на необхідність посилення перевірок безпеки workflow на етапі merge. Організаціям із публічними репозиторіями на GitHub варто негайно перевірити свої Actions-конфігурації на наявність подібних патернів прямої підстановки даних із подій.
