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 offentliga GitHub-repositorier hittade den en skriptinjektionsbrist i en GitHub Actions-workflow-fil kallad jira_issue.yml inuti snowflakedb/snowflake-connector-net, Snowflakes öppna källkods-.NET-kopplare. Bristen gjorde det möjligt för vem som helst att öppna ett GitHub-issue med en specialtillverkad titel och få Snowflakes egen automatisering att köra en del av den titeln som ett skalkommando, utan inloggning.

Red Agents första försök misslyckades. Körningen gav tillbaka ett syntaxfel i stället för att köra nyttolasten. I stället för att stanna där läste agenten felet, skrev själv om den preparerade issue-titeln 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, varvid en base64-kodad Jira-API-token exfiltrerades. Upptäckt, justering, utnyttjande och verifiering av den uppnådda åtkomsten skedde alla i en enda session, utan att någon människa bestämde 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 täckte projekt inom ingenjörskonst, säkerhetsefterlevnad och bug bounty-spårning. Den sårbara koden hade varit aktiv sedan sammanslagningen av PR #1218 den 18 juni 2026, som ersatte ett säkert parsningsmönster med direkt variabelinterpolation i ett skalkommando. Snowflake rättade det den 23 juni 2026, återställde det säkra mönstret och återkallade och förnyade den exponerade token; en granskning av loggarna hittade inga bevis för att en extern part hade använt den under det femdagars 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 förekom som medförfattare på den. Berättelsen skrev sig själv: en AI-kodningsassistent tycktes ha hjälpt till att skriva precis den bugg som en AI-säkerhetsagent sedan hittade och utnyttjade autonomt, i båda ändarna.

Medförfattarraden var äkta, och squash-sammanslagningar får den typen av 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 samlar dem alla i en enda commit på huvudgrenen, och varje medförfattarrad från var och en av de commiterna följer med över i det sammanslagna resultatet. Ett namn på den raden registrerar deltagande 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 mjuknat till en 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 skrev en mänsklig Snowflake-ingenjör 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 de specifika raderna.

Copilots faktiska medförfattar-commit inuti pull-request #1218 ändrade en annan fil, jira_close.yml, som inte hade något samband med de sårbara jira_issue.yml-raderna som Red Agent utnyttjade. När pull-requesten pressades samman till en enda merge-commit följde Copilots medförfattarrad ändå med, fäst vid en ändring den aldrig hade rört.

Tvisten står nu offentligt med två oförenliga skildringar 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 läsning som är korrekt.

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 standarduppsättningen, inte undantaget. När något går fel under den uppsättningen kan både den part som hittar buggen och verktyget som anklagas för att ha skrivit den båda vara AI-system, och det enda bevis någon av parterna kan peka på är commit-historiken för ett repositorium. Den historiken är bara så tillförlitlig som de metoder som frambringade den, och en rutinmässig squash-sammanslagning har just bevisat att den kan fästa en bidragsgivares namn vid någon annans misstag utan att någon avsåg det.

Buggen själv förblev exponerad i fem dagar och krävde fem dagar till för att rättas. Diskussionen om vem som skrev den varade längre än själva sårbarheten, och den utspelade sig mellan två leverantörer med resurserna och repositorieåtkomsten för att undersöka den ordentligt. Ett företag med mindre disciplin kring att bevara commit-historiken för sina egna workflow-filer, och utan ett fastställt svar på vem inom företaget som är bemyndigad att publicera ett tillskrivningspåstående innan det blir en offentlig tvist, kommer inte att lösa sin version lika prydligt.

Läs vidare: En enda post var värd mer än alla tre fonderna  |  En indragen frontier-modell är online igen