Критическая уязвимость в CI/CD-процессе Snowflake раскрыла внутренние токены Jira

Проблему выявила автономная система Wiz Red Agent, созданная исследовательским подразделением Wiz Research для тестирования безопасности. Она обнаружила уязвимость 23 июня 2026 года и сообщила о ней в компанию Snowflake через платформу HackerOne. Разработчики отреагировали оперативно: в тот же день они выпустили исправление, а на следующий день отозвали скомпрометированный токен. Никаких следов реальной эксплуатации в вредоносных целях компания не нашла, а на середину августа 2026 года уязвимость не получила номер CVE и не попала в перечень активно используемых уязвимостей американского агентства CISA.

Причиной инцидента стала ошибка в конфигурации рабочего процесса, который отвечает за интеграцию с Jira и запускается при открытии нового issue в репозитории. Сценарий напрямую подставлял заголовок issue в команду оболочки. Как установили исследователи Wiz Research, достаточно было вставить в это поле символы с специальным значением, чтобы выйти за пределы предполагаемой команды и выполнить собственные инструкции. Изменение внёс запрос на слияние от 18 июня 2026 года. Он заменил прежний безопасный способ обработки данных через переменные окружения на прямую интерполяцию строк.

Для демонстрации риска исследователи Wiz Red Agent отправили issue с заголовком, содержащим команду, которая отправляет на внешний сервер несколько секретных значений. В итоге рабочий процесс передал на контролируемый исследователями адрес несколько секретных значений. В их число вошли токен API Jira, адрес электронной почты и базовый URL корпоративной инстанции. Токен давал доступ на чтение к проектам Snowflake в области разработки, безопасности и программы по поиску уязвимостей. Фактически злоумышленник, получивший такие данные, мог просматривать внутренние задачи и статусы проектов. Такой доступ позволяет понять, над какими продуктами работает компания, какие уязвимости устраняются в первую очередь и где сосредоточены наиболее критичные процессы. Для сокрытия передаваемых данных исследователи использовали кодирование, превращающее токены в безобидную строку.

Всего с момента внесения уязвимого кода до его закрытия прошло пять дней. За это время никто не обращался к данным, кроме тестового обращения исследователей в рамках ответственного раскрытия. Внутренние журналы Snowflake не выявили несанкционированных действий. Патч, выпущенный 23 июня, восстановил использование переменных окружения и безопасных методов разбора. 24 июня команда Snowflake заменила токен Jira. Компания также провела дополнительный аудит журналов за пять дней, который не выявил ничего подозрительного. По политике раскрытия информации компания планировала предать инцидент огласке 25 июля. Однако отчёт уже был предоставлен заинтересованным сторонам.

Эта ситуация демонстрирует опасность использования инструментов автоматизированной генерации кода, включая подсказки на основе искусственного интеллекта. Такие инструменты могут предлагать небезопасные шаблоны, если не учитывать контекст обработки непроверенных данных. Гитхаб ранее предупреждал о подобном классе проблем и рекомендовал избегать прямой подстановки значений из внешних источников в сценарии оболочки. Тем не менее, даже в крупных компаниях такие предостережения иногда остаются без внимания. Причиной уязвимости, вероятно, стало сочетание автоматических подсказок и недостаточной проверки перед слиянием кода. Показательно, что столь серьёзная ошибка была обнаружена не классическим статическим анализатором, а автономным агентом, который имитирует действия реального злоумышленника.

Для защиты от подобных атак следует соблюдать несколько простых правил. В первую очередь нужно исключить включение любого пользовательского ввода в команды без предварительной проверки. Вместо прямой подстановки следует использовать промежуточные переменные окружения и специализированные инструменты для чтения данных. Также рекомендуется регулярно пересматривать все сценарии CI/CD на предмет потенциальных инъекций, менять учётные данные после любых подозрительных событий и отслеживать попытки несанкционированного доступа. Помимо технических мер, важно внедрить процесс обязательной проверки изменений в конфигурациях CI/CD и применять принцип минимальных привилегий для учётных записей автоматизации. В случае Snowflake реакция была своевременной, а ущерб ограничился тестовой утечкой в рамках ответственного тестирования, однако сама ситуация показывает, что публичные репозитории крупных вендоров остаются привлекательной целью для атакующих.

IPv4

• 20.106.182.197

Domain

• snowflake.net
• snowflakecomputing.atlassian.net

Email

• qa@snowflake.net