Vad Wiz' Agent Faktiskt Tog Sig In I

Wiz byggde en autonom AI-agent kallad Red Agent för att leta efter utnyttjningsbara brister på samma sätt som en mänsklig penetrationstestare skulle göra, och sedan agera på det den hittar. Riktad mot Snowflakes publika GitHub-repositorier hittade den en skriptinjektionsbrist i en workflow-fil för GitHub Actions kallad jira_issue.yml inuti snowflakedb/snowflake-connector-net, Snowflakes öppen källkod-kopplare för .NET. Bristen gjorde det möjligt för vem som helst att öppna ett GitHub-ärende med en särskilt utformad titel och få Snowflakes egen automatisering att köra en del av den titeln som ett skalkommando, helt utan inloggning.

Red Agents första försök misslyckades. Körningen gav ett syntaxfel tillbaka i stället för att köra nyttolasten. I stället för att ge upp läste agenten felmeddelandet, skrev själv om den preparerade ärendetiteln och försökte igen. Det andra försöket bröt sig ut ur skalsträngen och nådde en domän som kontrollerades av angriparen, och exfiltrerade samtidigt en base64-kodad API-token till Jira. Upptäckt, justering, utnyttjande och verifiering av den vunna åtkomsten skedde allt inom en enda session, utan att någon människa valde nästa steg.

Den stulna token var giltig och autentiserad som ett Snowflake-tjänstekonto, vilket gav läsåtkomst till en intern Jira-instans som omfattade projekt för utveckling, säkerhetsefterlevnad och spårning av bug bounty. Den sårbara koden hade legat aktiv sedan PR #1218 slogs samman den 18 juni 2026, vilket ersatte ett säkert parsningsmönster med direkt variabelinterpolation i ett skalkommando. Snowflake rättade felet den 23 juni 2026, återställde det säkra mönstret samt återkallade och förnyade den exponerade token; en granskning av loggarna visade att ingen extern part hade använt den under det femdagarslånga exponeringsfönstret.

Wiz Namngav Copilot Som Medförfattare till Buggen

Wiz' ursprungliga rapport pekade på den commit som introducerade bristen och noterade att GitHub Copilot Autofix stod med som medförfattare på den. Berättelsen skrev nästan sig själv: en AI-kodningsassistent tycktes ha hjälpt till att skriva exakt den bugg som en AI-säkerhetsagent sedan hittade och utnyttjade autonomt - på båda sidor.

Medförfattarraden var äkta, och squash-sammanslagningar får den sortens bevis att framstå som mer solitt än det är. En pull-request kan innehålla många enskilda commits från många bidragsgivare, men en squash-sammanslagning slår ihop dem alla till en enda commit på huvudgrenen, och varje medförfattarrad från var och en av dessa commits följer med in i det sammanslagna resultatet. Ett namn på den raden registrerar bara medverkan någonstans i pull-requesten, inte författarskap till en specifik rad. När Wiz uppdaterade sitt inlägg den 17 augusti 2026 hade det egna språkbruket redan mildrats till ett erkännande av att det var oklart om Copilot över huvud taget hade bidragit till de sårbara raderna.

GitHubs Commit-Historik Säger Att En Människa Skrev Den

GitHub genomförde en egen intern granskning av samma repositorium och kom fram till en annan slutsats. Enligt GitHub var det en mänsklig Snowflake-ingenjör som skrev den osäkra omskrivningen, i en separat commit daterad den 25 augusti 2025, ungefär tio månader innan den sårbara pull-requesten slogs samman, och Copilot Autofix varken granskade eller bidrog till just de raderna.

Copilots faktiska medförfattade commit inuti pull-request #1218 ändrade en annan fil, jira_close.yml, som saknade koppling till de sårbara raderna i jira_issue.yml som Red Agent utnyttjade. När pull-requesten pressades ihop till en enda merge-commit följde Copilots medförfattarrad ändå med, fastklistrad på en ändring den aldrig hade rört.

Tvisten står nu offentlig med två oförenliga versioner och ingen oberoende domare. Wiz pekar på en medförfattarrad i den levande commit-historiken; GitHub pekar på en intern granskning av samma repositorium som läser författarskapet annorlunda. Ingen utanför de två företagen har den åtkomst som krävs för att avgöra vilken tolkning som stämmer.

Styrningsglappet Varje AI-Understött Team Bör Lägga Märke Till

Att köra en AI-kodningsassistent och en AI-säkerhetsskanner i samma pipeline håller snabbt på att bli standardupplägget snarare än undantaget. När något går fel i det upplägget kan både den part som hittar buggen och verktyget som anklagas för att ha skrivit den vara AI-system, och det enda underlag någon av sidorna kan peka på är ett repositoriums egen commit-historik. Den historiken är bara så pålitlig som de rutiner som skapade den, och en helt vanlig squash-sammanslagning har just visat att den kan fästa en bidragsgivares namn vid en annan bidragsgivares misstag utan att någon avsett det.

Själva buggen låg exponerad i fem dagar och tog fem dagar till att rätta. Tvisten om vem som skrev den pågick längre än sårbarheten själv gjorde, och den utspelade sig mellan två leverantörer med både resurserna och repositorieåtkomsten för att utreda saken ordentligt. Ett företag med mindre disciplin kring att bevara commit-historiken för sina egna workflow-filer, och utan ett fastslaget svar på vem inom företaget som får publicera ett tillskrivningspåstående innan det blir en offentlig tvist, kommer inte att reda ut sin egen version lika städat.

Läs vidare: En anställds AI-inloggning nådde OpenAIs källkod  |  McKesson föll för ett telefonsamtal, inte ett lösenordsangrepp