Snowflakes Jira-token: en brist som Copilot var med och signerade – och människan som GitHub säger skrev den

Den 23 juni 2026 öppnade Red Agent, en autonom säkerhetsagent byggd av Wiz, ett ärende i ett offentligt GitHub-förvar som ägs av Snowflake och återvände med en autentiseringsuppgift. Förvaret var snowflakedb/snowflake-connector-net, och arbetsflödet som var orsak till felet, .github/workflows/jira_issue.yml, används för att skapa ett Jira-ärende varje gång någon öppnar ett ärende – det byggde in ärendets titel i ett shell-kommando i stället för att skicka den via en miljövariabel, så att en manipulerad titel kördes som kod på GitHub Actions-köraren. Tokenet som Red Agent återvann autentiserade som qa@snowflake.net mot snowflakecomputing.atlassian.net och hade läsbehörighet till Snowflakes Jira-projekt för teknik, säkerhetsefterlevnad och bug bounty. Sårbarheten hade varit aktiv i fem dagar. Wiz publicerade sin fullständiga analys den 17 augusti 2026. Incidenten är katalogiserad som post 2026-08-17-snowflake-jira-zhao-dao-can i Orca AI Incident Archive, som innehåller hela postsamlingen med dess konfidensgrader och citerade källor.

Interpolationen, och vakten som aldrig kördes

Arbetsflödet utlöstes av GitHub-händelsen "issues: opened". Vem som helst med ett GitHub-konto kunde utlösa det genom att öppna en issue i ett publikt repository – ingen inbjudan, ingen maintainer-roll, ingen fork. Det sårbara steget läste in issuetiteln i en shellvariabel: TITLE=$(echo '${{ github.event.issue.title }}' | sed ...), med två filter som var tänkta att escap:a dubbla citattecken och enkla citattecken innan strängen sattes ihop.

Felet ligger i ordningsföljden för operationerna, inte i escapingen. GitHub infogar uttryckets innehåll i skripttexten innan bash ens tolkar den, så ett enkelt citattecken i ärendetiteln avslutar den citerade strängen som echo håller öppen. De två sed-filtren körs i samma skript, efter infogningen, och kan inte reparera citeringen som redan har ändrat hur raden tolkas. Wiz rapport säger uttryckligen att escapingen kommer för sent för att förhindra genombrottet, och att en titel konstruerad med ett avslutande citattecken och ett semikolon tillfogar kommandon som angriparen själv väljer till körsteget.

En andra kontroll skulle ha begränsat målgruppen, men gjorde det inte. Jobbet innehöll ett if-villkor som jämförde github.event.pull_request.user.login med inloggningen för boten whitesource-for-github-com, uppenbarligen för att hindra automatiska beroende-pullförfrågningar från att skapa ärenden. Vid en issues-händelse finns det överhuvudtaget inget pull request-objekt, så jämförelsen sker mot en null-egenskap. GitHubs egen dokumentation, citerad av The Hacker News, anger att avreferering av en icke-existerande egenskap utvärderas till en tom sträng; Wiz analys når samma resultat via null-värdet. Hur som helst utvärderades villkoret till sant för varje användare, och undantaget för boten blev ett genomsläpp för internet.

Det som gjorde att injektionen var värd att rapportera i stället för att betraktas som rutin var det sällskap den hade. Samma steg innehöll JIRA_BASE_URL, JIRA_USER_EMAIL och JIRA_API_TOKEN som miljövariabler, så godtycklig kommandokörning på runnern hade en autentiseringsuppgift inom räckhåll i stället för ett tomt underlag. Ingen version av Snowflake Connector for .NET identifierades som påverkad: svagheten fanns i repots CI/CD-automatisering, inte i den levererade connector-koden.

Vad Red Agent tog, och vad den säger sig ha kastat bort

Wiz redogörelse för exploateringen är den del som skiljer detta från ett skannerfynd. Den första nyttolasten använde ett hash-tecken, som kommenterade bort den avslutande parentesen i TITLE=$(...)-tilldelningen och gav ett bash-syntaxfel i stället för en callback. Agenten läste felet och skrev om nyttolasten för att avsluta skalblocket med ett semikolon och ett nytt echo-citat, och mottog sedan ett out-of-band-anrop. Nyttolasten använde curl för att nå en underdomän till oast.me med base64-kodade värden för de tre autentiseringsvariablerna, och callbacken kom från Azure-IP 20.106.182.197, en adress som Wiz kopplar till en GitHub Actions-runner.

Den token som returnerades var en Jira API-token för qa@snowflake.net, och Wiz beskriver dess räckvidd som läsåtkomst som omfattar projekt för ingenjörsarbete, säkerhetsefterlevnad och bug bounty-spårning på Snowflakes Atlassian-molninstans. Det är den skada som arkivet dokumenterar: inte kodkörning på en byggmaskin under fem dagar, utan en autentiseringsuppgift som kunde läsa ärendeköerna där oåtgärdade tekniska och säkerhetsbuggar registreras – inklusive, enligt Wiz beskrivning, bug bounty-spårningen.

Wiz uppger att företaget på ett säkert sätt har raderat allt som det fick åtkomst till under proof of concept-fasen. Snowflake sade i ett uttalande till CSO Online att rapporten ”omedelbart undersöktes och åtgärdades” och att ”vår undersökning inte fann några tecken på obehörig åtkomst”; Wiz blogg tillägger att Snowflake granskade revisionsloggar för femdagarsfönstret och inte hittade någon tredjepartsanvändning utöver Wiz egna testadresser. Snowflake har inte publicerat dessa loggar, så slutsatsen att ingen annan aktör var inblandad vilar på företagets redogörelse och på Wiz sammanfattning av den, snarare än på dokument som någon utanför de två organisationerna kan läsa.

Vem skrev den sårbara raden?

Den frågan gav den andra, större historien. PR #1218, med titeln "SNOW-2069227: Uppdatera Jira-arbetsflöden", squash-mergades den 18 juni 2026 som commit 4a1b8ce, och squash-commitens medförfattarlista anger Copilot Autofix powered by AI som en av medförfattarna. Wiz ursprungliga rubrik byggde precis på detta och beskrev felet som beläget i en GitHub Copilot-assisterad pull request, och tidig branschbevakning följde samma linje – SC Medias rubrik löd "Wiz-agenten hittar fel i Snowflake-repo i kod samskriven av GitHub Copilot Autofix".

GitHubs ståndpunkt, som rapporterades av The Next Web och sammanfattades i en forskningsnot från Cloud Security Alliance, är att dess interna granskning fann att "en människa skrev de bidrag som ledde till sårbarheten" och att Copilot Autofix "varken granskade eller bidrog till dem". Den tekniska grunden för den repliken finns i git-historiken. Squash-merging komprimerar en pull request till en enda commit och för vidare varje co-author-trailer oavsett vilka rader den författaren rörde, så en co-author-rad registrerar deltagande i pull requesten, inte författarskap till en specifik hunk. Copilots medförfattade commit i samma pull request, 6d0e2fa, ändrade jira_close.yml — ett annat arbetsflöde än det sårbara jira_issue.yml. Den osäkra interpoleringen tillskrivs commit 094038e, daterad 25 augusti 2025 och av GitHub tillskriven en Snowflake-ingenjör, sfc-gh-hpathak; PR #1218 förde in det mönstret på standardgrenen i juni 2026.

Wiz drog inte tillbaka fyndet och ändrade framställningen på publiceringsdagen. Wiz blogg innehåller en uppdatering publicerad kl. 19:57 UTC den 17 augusti som beskriver Copilot som ”en medförfattare som kontrollerade den sammanslagna pull requesten och kodändringen” och som ”bedömde den som helt säker” utan att upptäcka sårbarheterna, samt erkänner att ”det är oklart om kodändringen var AI-assisterad.” I den redogörelsen ligger AI:ns misslyckande i granskningen, inte i författarskapet: den sammanslagna pull requesten bar en Copilot-medsignatur och injektionen överlevde den. CSO Online citerar Wiz CTO Ami Luttwak som säger att tydlig attribuering mellan människor och AI ”blir lite svårare att fastställa”, och att ”det inte räcker att bara se på medförfattarna till PR:en.”

Det som de två redogörelserna har gemensamt är värt att skilja från det de bestrider. Båda är eniga om att squash-committen bär Copilot Autofix medförfattartrailer och att arbetsflödet gick att exploatera. Ingen av dem bestrider att GitHub Advanced Security skannade den slutliga revideringen av pull requesten, extraherade jira_issue.yml och inte flaggade injektionen – Wiz rapporterar det som en miss, och GitHubs motargument handlar om författarskap snarare än om skanningen. Det som fortfarande är ovisst är huruvida Copilot överhuvudtaget granskade de sårbara raderna: Wiz säger att en granskning kördes och att den passerade dem, GitHub säger att verktyget inte hade någon roll i dem, och loggarna som skulle avgöra saken ligger hos ett av de två företagen. Protokollet återger båda redogörelserna i stället för att välja.

Fem dagar, och vad som förändrades efteråt

Åtgärden gick snabbt när rapporten först hade kommit in. Wiz skickade in via Snowflakes HackerOne-program som rapport #3819931 den 23 juni och meddelade Snowflakes säkerhetsteam via Slack samma dag; Snowflake mergade PR #1402, commit 1dc7766, som ersatte direkt uttrycksexpansion med miljövariabler som skickades till jq som argument. Wizs tidslinje anger att Jira-tokenen roterades den 24 juni, och The Hacker News rapporterar samma uppdelning. Wizs egen introduktion säger däremot att Snowflake åtgärdade sårbarheten och roterade autentiseringsuppgiften "samma dag" – en avvikelse inom primärkällan som dokumentationen inte bör släta över. Åtgärden landade den 23 juni; rotationen dateras till den 24 juni i Wizs tabell.

Offentliggörandet följde Snowflakes tidslinje: Wiz daterar tidsfristen för offentliggörande till 25 juli 2026, trettio dagar efter ett beslut den 25 juni enligt programmets policy, och publicerade analysen den 17 augusti. Snowflakes uttalande till CSO Online sade att företaget "värdesätter Wizs ansvarsfulla rapportering" och att det arbetade med Wiz för att dela lärdomarna med branschen. Varken Wizs analys eller rapporten från The Hacker News innehåller en CVE-identifierare, en CVSS-poäng eller en post i CISA:s katalog över kända exploaterade sårbarheter; felet var en arbetsflödeskonfiguration i ett offentligt kodarkiv, inte ett distribuerat bibliotek, och det kom därför aldrig in i en sårbarhetsdatabas på vanligt sätt.

Vad handlingarna fastställer, och vad de inte fastställer

Arkivet klassificerar detta som en forskningsupptäckt snarare än en driftsättningshändelse, med hög allvarlighetsgrad, konfidensgrad A, bekräftad AI-inblandning och registrerad verklig skada; dess datum, 17 augusti 2026, är dagen då Wiz publicerade, och incidenten sträcker sig från 18 till 23 juni. Den fastställda kärnan är smal och kontrollerbar: ett offentligt arbetsflöde interpolerade angriparkontrollerad text i ett shell-kommando, dess skyddsvillkor jämfördes mot en egenskap som är null vid den händelsen, en Jira-token låg i samma steg, en autonom agent utnyttjade det, och Snowflake sammanfogade en fix och roterade autentiseringsuppgiften inom ett dygn.

De delar som är slutledningar snarare än dokumenterade uppgifter är just de som vardagliga återgivningar tenderar att utjämna. Copilot Autofix är dokumenterad som medförfattare till pull requesten och är inte dokumenterad som författare till de sårbara raderna; den AI-mot-AI-inramning som präglade den första nyhetscykeln drogs delvis tillbaka av den rapporterande organisationen inom några timmar och tillbakavisades av GitHub. Huruvida den mergade pull requestens AI-granskning såg på jira_issue.yml är fortfarande en öppen faktafråga, inte en avgjord sådan. Och omfattningen av åtkomsten, även om den beskrivs i detalj av Wiz, har inte granskats oberoende: inga Jira-behörigheter, arbetsflödeskörningar eller granskningsposter har offentliggjorts.

Korrigeringsmönstret är det som GitHubs egen vägledning har rekommenderat sedan juli 2025 – att skicka opålitlig ärendedata till en miljövariabel och överlämna den till jq som ett argument, i stället för att expandera den i ett run-block. Snowflakes sammanfogade commit gör exakt det, och den korrigerade hanteringen finns kvar på standardgrenen. För den som läser protokollet som ett prejudikat handlar den bestående slutsatsen om attribution snarare än om injektion: när en pull request omfattar flera människor och flera agenter kan co-author-trailern inte säga vem som skrev en rad, och både Wiz och GitHub sade det till slut med olika ord.