Wizs Red Agent hittade Snowflake-felet – fem dagar efter att det blev aktivt

Det som hände i Snowflake var en injektionssårbarhet i ett GitHub Actions-arbetsflöde i det publika arkivet snowflakedb/snowflake-connector-net – inte en sårbarhet i själva .NET-anslutningen som levereras till kunder. En ändring som slogs samman den 18 juni 2026 placerade en angriparkontrollerad titel från ett GitHub-ärende i ett skalkommando. Fem dagar senare upptäckte Wizs autonoma Red Agent svagheten och använde den i ett auktoriserat säkerhetstest via HackerOne för att hämta autentiseringsuppgifter till Snowflakes interna Jira.

Ändringen som öppnade dörren

Den sårbara koden fanns i arbetsflödet .github/workflows/jira_issue.yml, som startades när ett GitHub-ärende öppnades. Pull request #1218, med titeln ”SNOW-2069227: Update Jira workflows”, ersatte en säkrare lösning där ärendets titel skickades via en miljövariabel och JSON byggdes med jq. I den nya versionen bäddades

${{ github.event.issue.title }}

Skillnaden var avgörande. GitHub expanderar uttrycket innan skalet kör kommandot. En skadlig ärendetitel med ett enkelt citattecken kunde därför avsluta den avsedda textsträngen och lägga till egna skalkommandon. Att värdet därefter bearbetades med sed kunde inte längre stoppa tolkningen som redan hade skett.

Utlösaren

issues: opened

Ändringen krediterade ”Copilot Autofix powered by AI” som medförfattare, och den AI-assisterade granskningen flaggade inte problemet. Underlaget visar däremot inte om Copilot skapade den osäkra ändringen eller granskade en ändring skriven av en människa. Den försiktiga slutsatsen är att Copilot var kopplat till ändringen och missade injektionen – inte att det är bevisat att modellen skrev koden.

Så hittade Red Agent sårbarheten

Wizs Red Agent sökte igenom Snowflakes publika GitHub-organisation efter riskfyllda CI/CD-mönster. Agenten identifierade Jira-arbetsflödet som ett fall där opålitlig ärendedata användes i ett run:-block och drog slutsatsen att en särskilt utformad publik ärendetitel kunde leda till godtycklig kodkörning på den GitHub-hanterade Actions-körmiljön.

Den 23 juni – fem dagar efter att den sårbara ändringen hade slagits samman – öppnade agenten ett manipulerat ärende inom ramen för Snowflakes program för sårbarhetsrapportering på HackerOne. Titeln bröt sig ur skalsträngen och fick arbetsflödet att skicka Jira-uppgifter till en extern så kallad out-of-band-callback som kontrollerades för det auktoriserade testet.

Det var alltså ett godkänt säkerhetstest, inte ett okontrollerat intrång. Säkerhetsbristen var ändå verklig: ett publikt ärende kunde nå ett arbetsflödessteg som hanterade autentiseringsuppgifter och förvandla en vanlig ärendeskapning till kommandokörning.

Vilken åtkomst som exponerades

Det komprometterade arbetsflödet hade tillgång till Snowflakes interna Jira-konfiguration, däribland Jira-adress, användarens e-postadress och API-token. Den återvunna token var kopplad till qa@snowflake.net. Wiz använde den för att autentisera mot den interna Jira-portalen och bedöma den möjliga exponeringen.

Rapporteringen beskriver läsåtkomst till Jira-projekt för bland annat utveckling, säkerhetsefterlevnad och bug bounty-verksamhet. Det tillgängliga underlaget fastställer inte tokenens fullständiga behörigheter eller exakt vilka poster som kunde nås. Den starkaste belagda slutsatsen är därför att token gav åtkomst till känsligt internt Jira-innehåll – inte obegränsad åtkomst till Snowflakes system.

Den berörda tillgången var arkivets CI/CD-automatisering. Ingen utgiven version av Snowflake Connector för .NET rapporterades som påverkad, eftersom felet låg i GitHub Actions-arbetsflödet och inte i anslutningens körkod.

Snowflakes svar

Wiz rapporterade sårbarheten den 23 juni. Snowflake åtgärdade arbetsflödet samma dag och bytte ut den exponerade Jira-uppgiften dagen därpå.

Snowflake granskade därefter granskningsloggarna och drog slutsatsen att Wiz var den enda aktören under exponeringsperioden. Wiz uppgav samtidigt att all data från proof of concept-testet hade raderats på ett säkert sätt.

Ingen obehörig åtkomst från tredje part rapporterades, ingen CVE-tilldelning rapporterades och ingen påverkad version av anslutningen identifierades. Det beskriver den bekräftade omfattningen – men gör inte den ursprungliga konstruktionen säker. En publik ärendetitel ska aldrig kunna bli en del av ett skalkommando i ett arbetsflöde som hanterar interna autentiseringsuppgifter.

Lärdomen för CI/CD

Lärdomen sträcker sig längre än Snowflake och Copilot. GitHub-uttryck som ärendetitlar, pull request-titlar, grennamn och kommentarer ska behandlas som fientlig indata så snart de förs in i ett skalkommando.

Säkrare arbetsflöden bör bland annat:

• skicka opålitliga värden via miljövariabler i stället för att interpolera dem direkt i run:-skript,
• använda strukturerade verktyg som jq för att bygga JSON i stället för att sätta ihop skalsträngar,
• citera och validera data vid gränsen mot skalet,
• hålla autentiseringsuppgifter borta från steg som behandlar angriparkontrollerat innehåll när det är möjligt, och
• granska AI-genererade säkerhetsändringar lika noggrant som kod skriven av människor.

Händelsen visar tydligt ett växande säkerhetsproblem: ett AI-assisterat kodverktyg kan missa en farlig CI/CD-ändring, medan en autonom offensiv agent hittar och validerar den inom några dagar. Automatisering kan påskynda både åtgärder och angrepp – men den ersätter inte oberoende granskning.