Автономен ИИ агент за сигурност, разработен от Wiz Research, демонстрира колко бързо един пренебрегнат ред shell код може да доведе до цялостно изтичане на идентификационни данни.
Инструментът, известен като Wiz Red Agent, самостоятелно открива, експлоатира и валидира критична уязвимост от тип внедряване на код (injection) в GitHub Actions в публичното хранилище на Snowflake, snowflake-connector-net, като в крайна сметка получава достъп за четене до вътрешната система Jira на Snowflake без никаква човешка намеса.
Уязвимостта се е намирала в конфигурационния файл jira_issue.yml, предназначен автоматично да създава тикети в Jira при всяко отваряне на GitHub issue от потребител.
Проблемът възниква при pull request #1218, слят на 18 юни 2026 г., който заменя предходния безопасен модел, използващ променливи на средата и jq парсване, с директно вграждане на ненадеждното заглавие на съобщението в shell скрипт.
Тъй като разширяването на шаблоните на GitHub се случва преди ескейпването на символи в shell средата, единична кавичка в заглавието на съобщението е била достатъчна за излизане от контекста на скрипта и инжектиране на произволни команди. За капак, условната проверка, която е трябвало да ограничава достъпа, винаги се е оценявала като истина при събития от тип отваряне на съобщение, което означава, че всеки потребител в GitHub е можел да задейства експлоита.
Интересно е, че инструментът GitHub Advanced Security е сканирал точно тази версия, съдържаща уязвимия код, но не е успял да я засече, въпреки че асистирана от Copilot промяна е засегнала подобен файл (jira_close.yml) в същия pull request.
От Wiz по-късно уточниха, че приносът на Copilot се е ограничавал само до този отделен файл и че той е прегледал слетия PR, без да улови критичния дефект.
Red Agent открива уязвимостта само пет дни след като тя става публично достъпна – на 23 юни 2026 г. Той съставя злонамерено заглавие на съобщението, използвайки base64-кодирано външно извикване (callback) за извличане на идентификационните данни за Jira от средата за изпълнение на GitHub Actions.
Когато първият му опит за изпращане на злонамерен код, използващ символ за коментар, нарушава синтаксиса на shell, агентът самостоятелно диагностицира грешката в bash и пренаписва кода, за да затвори правилно скрипта, като успява при втория си опит.
В рамките на секунди сървърът за слушане на Wiz получава отговор от хоствана в Azure среда, съдържащ base64-кодирани Jira API токени, свързани с акаунта за поддръжка qa@snowflake.net.
Този токен се удостоверява успешно пред Atlassian платформата на Snowflake, осигурявайки достъп до проекти за разработка, съответствие със сигурността и проследяване на уязвимости (bug bounty) – сериозен обхват на пораженията за един-единствен грешно конфигуриран CI работен процес.
Snowflake реагира в същия ден, в който е съобщено за уязвимостта чрез HackerOne, като коригира уязвимостта в работния процес, подмени компрометирания токен за Jira и потвърди чрез одитните логове, че тестващият трафик на Wiz е бил единствената активност по време на прозореца на излагане на риск. Всички данни, достъпени по време на тестовете за доказване на концепцията, са били изтрити.
Инцидентът подчертава нарастващо безпокойство в софтуерната сигурност: програмирането с помощта на ИИ може еднакво лесно да въведе отново несигурни практики, както и да ги засече, а съществуващите инструменти за статичен анализ може да не смогват с това темпо.
Това също така сигнализира за промяна в самата среда на заплахите, където автономните ИИ агенти могат да съкратят времето от откриване до експлоатация от седмици на часове.
За екипите по сигурността изводът е ясен: CI/CD тръбопроводите се нуждаят от изрично налагане на сигурни модели за кодиране, краткосрочни идентификационни данни и детайлен преглед на генерирания от ИИ код, съответстващ на скоростта, с която атакуващите и защитниците автоматизират работата си.