Исследователи компании Wiz выявили уязвимость типа workflow injection в публичном репозитории snowflakedb/snowflake-connector-net на GitHub, которая позволяла злоумышленнику выполнить произвольные команды в среде GitHub Actions runner, просто создав специально сформированный Issue. В ходе авторизованного тестирования исследователи извлекли API-токен Jira, дававший, по их данным, доступ на чтение к внутренним проектам Snowflake, включая инженерные задачи, отслеживание соответствия требованиям безопасности и баг-баунти. Уязвимость существовала в 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, охватывающим инженерные задачи, отслеживание соответствия требованиям безопасности и баг-баунти. Следует отметить, что детали эксплуатации и объём полученных прав основаны исключительно на заявлениях 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-конфигурации на наличие аналогичных паттернов прямой подстановки данных из событий.
