Rozdíl byl zásadní. GitHub výraz rozbalí ještě předtím, než příkaz zpracuje shell. Pokud tedy název issue obsahoval apostrof, mohl ukončit zamýšlený řetězec a přidat vlastní shellové příkazy. Následné „očištění“ hodnoty pomocí sed už nemohlo napravit skutečnost, že shell ji předtím interpretoval jako součást příkazu.

Ani spouštěč issues: opened z názvu issue neudělal důvěryhodný vstup. Název mohl ovládat každý uživatel, který byl schopen otevřít issue ve veřejném repozitáři. Podmínka omezující workflow na události související s issues proto nebránila vložení útočníkem kontrolovaných dat do shellu.

Commit uváděl jako spoluautora „Copilot Autofix powered by AI“ a AI asistovaná kontrola problém neodhalila. Dostupné důkazy však nepotvrzují, zda Copilot nebezpečnou změnu sám vytvořil, nebo pouze kontroloval či spoluautorsky označil změnu napsanou člověkem. Přesnější závěr tedy zní, že Copilot byl se změnou spojen a injektáž nezachytil — nikoli že je prokazatelně jejím autorem.

Jak Red Agent chybu našel

Red Agent při rutinním skenování veřejné organizace Snowflake hledal rizikové vzory v CI/CD automatizaci. U workflow Jira rozpoznal, že nedůvěryhodná data z issue vstupují přímo do shellového bloku run:. Z toho odvodil, že speciálně vytvořený název veřejného issue může vést ke spuštění libovolných příkazů na runneru GitHub Actions.

Dne 23. června — tedy pět dní po sloučení chybné změny — agent v rámci programu Snowflake pro zveřejňování zranitelností na HackerOne otevřel upravené issue. Název ukončil původní shellový řetězec a přiměl workflow odeslat přístupové údaje k Jira na out-of-band callback, který byl připravený pro autorizovaný proof of concept.

Nešlo o nekontrolovaný útok, ale o schválený bezpečnostní test. Samotný technický nález byl přesto skutečný: kdokoli mohl prostřednictvím veřejného issue dostat data až do kroku workflow, který pracoval s interními přístupovými údaji, a změnit tak běžné otevření issue ve spuštění příkazů.

K jakým datům se test dostal

Napadený workflow měl k dispozici údaje pro interní Jira Snowflake — adresu Jira, e-mail uživatele a API token. Získaný token byl spojen s účtem qa@snowflake.net; Wiz jej použil k přihlášení do interního portálu Jira a k posouzení možného rozsahu expozice.

Podle zveřejněných informací token umožňoval čtení v projektech týkajících se vývoje, bezpečnostní compliance a bug bounty programu. Dostupné podklady ale neuvádějí úplný soubor oprávnění tokenu ani definitivní seznam všech záznamů, které s ním bylo možné zobrazit. Nejbezpečnější závěr proto je, že umožnil přístup k citlivému internímu obsahu Jira, nikoli že poskytoval neomezený přístup k systémům Snowflake.

Zranitelným aktivem byla automatizace CI/CD v repozitáři. Nebyla oznámena žádná dotčená vydaná verze Snowflake Connector for .NET, protože chyba se nacházela ve workflow GitHub Actions, nikoli v běhovém kódu konektoru.

Jak Snowflake reagoval

Wiz problém nahlásil 23. června. Snowflake workflow opravil ještě tentýž den a následující den změnil dotčené přihlašovací údaje k Jira.

Firma následně prověřila auditní záznamy a dospěla k závěru, že během období expozice byl jediným aktérem Wiz. Wiz zároveň uvedl, že data získaná při proof of concept bezpečně odstranil.

Nebyl oznámen neoprávněný přístup třetí strany, přiděleno CVE ani identifikováno dotčené vydání konektoru. Tyto skutečnosti vymezují potvrzený dopad incidentu, neznamenají však, že původní návrh workflow byl bezpečný. Veřejný název issue se nikdy neměl stát součástí shellového příkazu ve workflow, které zpracovávalo interní přístupové údaje.

Poučení pro GitHub Actions a AI nástroje

Případ přesahuje otázku Snowflake i konkrétního produktu Copilot. Hodnoty z GitHubu — například názvy issues a pull requestů, názvy větví nebo komentáře — je třeba považovat za potenciálně škodlivý vstup pokaždé, když se dostanou do shellového příkazu.

Bezpečnější návrh workflow zahrnuje zejména:

• předávání nedůvěryhodných hodnot prostřednictvím proměnných prostředí místo přímého vkládání do skriptů run:;
• používání strukturovaných nástrojů, například jq, pro tvorbu JSON namísto skládání shellových řetězců;
• správné escapování a validaci dat na hranici mezi aplikací a shellem;
• oddělení přístupových údajů od kroků, které zpracovávají obsah ovládaný uživatelem;
• stejně důkladnou kontrolu změn vytvořených AI jako kódu napsaného člověkem.

Incident názorně ukazuje novou stránku automatizace: jeden AI nástroj může nebezpečnou změnu v CI/CD přehlédnout, zatímco autonomní ofenzivní agent ji během několika dní najde a ověří. Automatizace může urychlit obranu i útok — nezastoupí však nezávislou bezpečnostní kontrolu.

Rozdíl byl zásadní. GitHub výraz rozbalí ještě předtím, než příkaz zpracuje shell. Pokud tedy název issue obsahoval apostrof, mohl ukončit zamýšlený řetězec a přidat vlastní shellové příkazy. Následné „očištění“ hodnoty pomocí sed už nemohlo napravit skutečnost, že shell ji předtím interpretoval jako součást příkazu.

Ani spouštěč issues: opened z názvu issue neudělal důvěryhodný vstup. Název mohl ovládat každý uživatel, který byl schopen otevřít issue ve veřejném repozitáři. Podmínka omezující workflow na události související s issues proto nebránila vložení útočníkem kontrolovaných dat do shellu.

Commit uváděl jako spoluautora „Copilot Autofix powered by AI“ a AI asistovaná kontrola problém neodhalila. Dostupné důkazy však nepotvrzují, zda Copilot nebezpečnou změnu sám vytvořil, nebo pouze kontroloval či spoluautorsky označil změnu napsanou člověkem. Přesnější závěr tedy zní, že Copilot byl se změnou spojen a injektáž nezachytil — nikoli že je prokazatelně jejím autorem.

Jak Red Agent chybu našel

Red Agent při rutinním skenování veřejné organizace Snowflake hledal rizikové vzory v CI/CD automatizaci. U workflow Jira rozpoznal, že nedůvěryhodná data z issue vstupují přímo do shellového bloku run:. Z toho odvodil, že speciálně vytvořený název veřejného issue může vést ke spuštění libovolných příkazů na runneru GitHub Actions.

Dne 23. června — tedy pět dní po sloučení chybné změny — agent v rámci programu Snowflake pro zveřejňování zranitelností na HackerOne otevřel upravené issue. Název ukončil původní shellový řetězec a přiměl workflow odeslat přístupové údaje k Jira na out-of-band callback, který byl připravený pro autorizovaný proof of concept.

Nešlo o nekontrolovaný útok, ale o schválený bezpečnostní test. Samotný technický nález byl přesto skutečný: kdokoli mohl prostřednictvím veřejného issue dostat data až do kroku workflow, který pracoval s interními přístupovými údaji, a změnit tak běžné otevření issue ve spuštění příkazů.

K jakým datům se test dostal

Napadený workflow měl k dispozici údaje pro interní Jira Snowflake — adresu Jira, e-mail uživatele a API token. Získaný token byl spojen s účtem qa@snowflake.net; Wiz jej použil k přihlášení do interního portálu Jira a k posouzení možného rozsahu expozice.

Podle zveřejněných informací token umožňoval čtení v projektech týkajících se vývoje, bezpečnostní compliance a bug bounty programu. Dostupné podklady ale neuvádějí úplný soubor oprávnění tokenu ani definitivní seznam všech záznamů, které s ním bylo možné zobrazit. Nejbezpečnější závěr proto je, že umožnil přístup k citlivému internímu obsahu Jira, nikoli že poskytoval neomezený přístup k systémům Snowflake.

Zranitelným aktivem byla automatizace CI/CD v repozitáři. Nebyla oznámena žádná dotčená vydaná verze Snowflake Connector for .NET, protože chyba se nacházela ve workflow GitHub Actions, nikoli v běhovém kódu konektoru.

Jak Snowflake reagoval

Wiz problém nahlásil 23. června. Snowflake workflow opravil ještě tentýž den a následující den změnil dotčené přihlašovací údaje k Jira.

Firma následně prověřila auditní záznamy a dospěla k závěru, že během období expozice byl jediným aktérem Wiz. Wiz zároveň uvedl, že data získaná při proof of concept bezpečně odstranil.

Nebyl oznámen neoprávněný přístup třetí strany, přiděleno CVE ani identifikováno dotčené vydání konektoru. Tyto skutečnosti vymezují potvrzený dopad incidentu, neznamenají však, že původní návrh workflow byl bezpečný. Veřejný název issue se nikdy neměl stát součástí shellového příkazu ve workflow, které zpracovávalo interní přístupové údaje.

Poučení pro GitHub Actions a AI nástroje

Případ přesahuje otázku Snowflake i konkrétního produktu Copilot. Hodnoty z GitHubu — například názvy issues a pull requestů, názvy větví nebo komentáře — je třeba považovat za potenciálně škodlivý vstup pokaždé, když se dostanou do shellového příkazu.

Bezpečnější návrh workflow zahrnuje zejména:

• předávání nedůvěryhodných hodnot prostřednictvím proměnných prostředí místo přímého vkládání do skriptů run:;
• používání strukturovaných nástrojů, například jq, pro tvorbu JSON namísto skládání shellových řetězců;
• správné escapování a validaci dat na hranici mezi aplikací a shellem;
• oddělení přístupových údajů od kroků, které zpracovávají obsah ovládaný uživatelem;
• stejně důkladnou kontrolu změn vytvořených AI jako kódu napsaného člověkem.

Incident názorně ukazuje novou stránku automatizace: jeden AI nástroj může nebezpečnou změnu v CI/CD přehlédnout, zatímco autonomní ofenzivní agent ji během několika dní najde a ověří. Automatizace může urychlit obranu i útok — nezastoupí však nezávislou bezpečnostní kontrolu.