En vanlig GitHub-issue kjørte kommandoer i Snowflakes workflow og hentet ut Jira-token

«Undersøkelsen vår fant ingen tegn til uautorisert tilgang» — Snowflake, i en uttalelse gjengitt av Wiz

Sikkerhetsselskapet Wiz fant hullet i det offentlige repoet snowflakedb/snowflake-connector-net. Ifølge The Hacker News lå feilen i .github/workflows/jira_issue.yml, en workflow som kjørte hver gang noen åpnet en offentlig issue, og som eksponerte JIRA_BASE_URL, JIRA_USER_EMAIL og JIRA_API_TOKEN i samme steg. Ingen utgivelse av selve .NET-konnektoren var berørt.

Mekanismen er den klassiske: workflowen limte tittelen og brødteksten fra issuen rett inn i en run-blokk, altså verdier en hvilken som helst utenforstående kontrollerer. Vakten som skulle stoppe dette sjekket github.event.pull_request.user.login, men hendelsen var en issue, ikke en pull request. GitHubs egen dokumentasjon sier at et oppslag mot en egenskap som ikke finnes, blir til en tom streng. Sammenligningen mot bot-kontoen stoppet dermed ingenting.

Wiz opplyser at deres Red Agent-system gjennomførte utnyttelsen under autorisert testing, endret fremgangsmåte da første forsøk ga en syntaksfeil i skallet, og deretter fikk et tilbakekall fra GitHub Actions-kjøreren. Tokenet de hentet ut tilhørte qa@snowflake.net og ga lesetilgang til Jira-prosjekter for utvikling, sikkerhetsetterlevelse og bug bounty.

Tidslinjen er kort og lærerik. Den sårbare workflowen nådde standardgrenen 18. juni. Wiz meldte fra via HackerOne 23. juni, og Snowflake merget en fiks samme dag som byttet direkte uttrykksekspansjon med miljøvariabler sendt til jq som argumenter. Tokenet ble rotert 24. juni. Per 17. august fantes verken CVE-nummer, CVSS-score eller KEV-oppføring for saken.

Ett forbehold er verdt å ta med: Wiz beskriver feilen som resultat av en endring fra GitHub Copilot Autofix, men commit-historikken viser bare at Copilot deltok i pull requesten, ikke at den skrev de sårbare linjene. Den usikre refaktoreringen av jira_issue.yml stammer fra en egen commit fra august 2025, tilskrevet en Snowflake-utvikler.

Hva bør du gjøre?

Gå gjennom workflowene dine som trigges av issues, issue-kommentarer eller pull requests fra forks, og se etter GitHub-uttrykk limt rett inn i en run-blokk. Fikser du det på Snowflakes måte, sender du verdien inn som miljøvariabel og lar skallet behandle den som data, ikke som kode. GitHub advarte mot nettopp dette mønsteret allerede i juli 2025.

Sjekk deretter hva som ligger i miljøet til det samme steget. Skaden her kom ikke av injeksjonen alene, men av at et Jira-token med lesetilgang til sikkerhetsprosjekter lå i rekkevidde for koden som ble kjørt. Hemmeligheter hører hjemme i det steget som faktisk trenger dem, ikke i det som behandler tekst fra fremmede.