Cybersecurityonderzoekers van Wiz hebben een nieuwe GitHub Actions flaw ontdekt in een publieke Snowflake-repository: snowflakedb/snowflake-connector-net. Door een speciaal samengestelde GitHub issue (dus: niet via een pull request) zouden aanvallers commando-injectie kunnen uitlokken in een workflow die CI/CD-automatisering gebruikt en daarbij interne JIRA-credentials blootlegt.
Het incident raakt vooral de manier waarop de workflow gegevens uit issues verwerkt en die vervolgens direct in een shell-commando verwerkt. In dit artikel leggen we uit wat er misging, hoe de onderzoekers de fout konden misbruiken, en welke lessen je organisatie hieruit kan trekken voor je eigen software supply chain.
Wat is de GitHub Actions flaw precies?
De kwetsbaarheid zat in een specifieke workflow: .github/workflows/jira_issue.yml. Deze workflow draaide wanneer een gebruiker een publieke issue aanmaakt. In datzelfde workflowpad worden waarden doorgegeven zoals JIRA_BASE_URL, JIRA_USER_EMAIL en JIRA_API_TOKEN aan een volgende stap.
Volgens Wiz was de fout dat de workflow door de aanvaller aangeleverde issue-velden (titel en body) direct gebruikte binnen een shell run-blok. Daardoor konden die waarden terechtkomen in de commando-uitvoering alsof ze vertrouwde input waren.
Daarnaast zag Wiz een logische fout in de conditionering: de workflow controleerde github.event.pull_request.user.login terwijl het event type ging om een issue. GitHub gaf daarbij aan dat het derefereren van een niet-bestaande property resulteert in een lege string. In deze context zorgde die vergelijking er dus niet voor dat een normale issue werd tegengehouden.
Command injection via crafted issues
De kern van de exploit was command injection binnen CI/CD. In plaats van enkel informatie te bekijken of te manipuleren, kon de aanvaller controle uitoefenen over hoe een shell-commando werd opgebouwd binnen de workflow.
Wiz beschrijft dat hun Red Agent-systeem tijdens geautoriseerde security testing eerst een payload probeerde die eindigde in een shell-syntax error. Daarna paste het systeem de aanpak aan en lukte de injectie wél.
Vervolgens ontvingen de onderzoekers een out-of-band callback van de GitHub Actions runner. Dat detail is belangrijk: het wijst erop dat de runner daadwerkelijk acties uitvoerde die buiten het normale workflowpad vielen—precies het soort gedrag dat je wil detecteren bij misbruik van CI/CD.
Waarom waren JIRA-credentials een extra risico?
De workflow exposeerde JIRA-gegevens aan een stap die de geïnjecteerde input zou verwerken. Wiz stelt dat het uiteindelijk de Jira API-token kon verkrijgen die door de workflow werd gebruikt.
Het token dat werd aangetroffen, was volgens Wiz gekoppeld aan qa@snowflake.net. Met dat token waren read-toegang en inzage mogelijk voor Jira-projecten met onder meer engineering, security compliance en bug bounty tracking op snowflakecomputing.atlassian.net.
Belangrijk nuance: Wiz en Snowflake geven geen volledig publieke lijst van welke permissies precies golden op workflow-niveau, maar beide partijen geven wel aan dat audit- en run-details niet publiek zijn. Daarmee blijft de exacte impact niet volledig transparant, al is het risico van token-blootstelling in CI/CD wel duidelijk.
Geen bevestigde compromise, wel fix en tokenrotatie
Snowflake reageerde op het rapport en voerde een fix door. In hun verklaring—zoals gereproduceerd door Wiz—zei Snowflake dat er geen bewijs was voor ongeautoriseerde toegang.
Tegelijkertijd meldt Wiz dat Snowflake het betreffende Jira-token heeft geroteerd op 24 juni 2026. Dat is een standaardreactie bij dit soort credential-gerelateerde vondsten: ook als je niet kan bewijzen dat een misbruiker het echt heeft gedaan, wil je de dreiging elimineren.
Snowflake stelde ook dat hun review geen ander ongewenst extern gebruik vond gedurende het tijdvak van blootstelling. Wiz merkt op dat de onderliggende audit logs niet openbaar zijn, dus buiten de betrokken teams blijft het bij deze verklaringen.
Timeline: wanneer zat de fout erin en wanneer is hij opgelost?
Wiz koppelde de kwetsbare workflow aan het moment waarop hij op de default branch terechtkwam. Volgens het onderzoek was dat op 18 juni, toen een pull request (nummer #1218) werd samengevoegd via een squash merge.
De fix kwam kort daarna. Wiz zegt dat Snowflake het issue-rapport via HackerOne ontving en dat de oplossing is gemerged op 23 juni 2026 in pull request #1402.
Op 23 juni werd dus een wijziging doorgevoerd die de oorspronkelijke interpolatie van issue-data verving door een veiliger datpad: Snowflake haalde de directe expansie van GitHub expressies uit de kwetsbare stap en gebruikt in plaats daarvan environment variables die als argumenten naar jq worden doorgegeven. Daardoor komt de input minder direct in het kritieke shell-pad terecht.
Wiz stelt bovendien dat de gecorrigeerde afhandeling beschikbaar blijft in de repository-master branch.
Waarom “werkt het niet altijd” als je PR-velden checkt?
Een leerzaam element uit het verhaal is de conditionele check in de workflow. Wiz zag dat er werd gekeken naar velden die horen bij een pull request (zoals github.event.pull_request.user.login), terwijl de workflow feitelijk startte op basis van het issue-event.
GitHub gaf daarbij aan dat het derefereren van een property die niet bestaat, in zo’n case neerkomt op een lege string. Het gevolg: de vergelijking werkte niet als verwachte beveiligingspoort. Voor security teams betekent dit dat een logic bug in voorwaarden net zo’n groot probleem kan zijn als de inputverwerking zelf.
Relatie met eerdere GitHub waarschuwingen
Wiz verwijst naar een GitHub documentatiepunt uit juli 2025, waarin een class van workflow-injectie wordt beschreven. GitHub waarschuwde toen expliciet tegen het direct uitbreiden van onbetrouwbare issue- of inputdata in run: blocks en adviseerde om te werken met tussenliggende environment variables.
Dat advies sluit nauw aan op wat Snowflake in pull request #1402 deed: de aanpak wijzigde van directe interpolatie naar gecontroleerde doorvoer via environment variables en verwerking met een tool zoals jq.
Heeft dit een CVE gekregen?
Per 17 augustus 2026 had Wiz volgens de beschikbare informatie geen CVE of CVSS-score gevonden, en ook geen vermelding in het CISA Known Exploited Vulnerabilities (KEV) catalogus. Evenmin was er een connector release update gelinkt aan de bevinding.
Wel stelt Wiz dat de kwetsbare interpolatie inmiddels niet meer voorkomt op master. Daarnaast geeft Wiz aan dat de primaire bronmaterialen niet aantonen dat er sprake was van een bewezen exploit in het wild of een bekende klantcompromise.
Praktische lessen voor je eigen CI/CD
Ook als je niet direct met Snowflake-connectoren werkt, is dit een case die je kunt vertalen naar je eigen pipelines. Als je CI/CD workflows issue- of user-generated content verwerken, let dan extra op de volgende punten:
- Vermijd directe shell-interpolatie: stop onbetrouwbare input niet “1-op-1” in een shell run-commando.
- Werk met gecontroleerde variabelen: gebruik environment variables en een duidelijke datastructuur-verwerking (zoals jq met argumenten) zodat je input niet als code kan worden geïnterpreteerd.
- Controleer je event logic: zorg dat je workflowvoorwaarden kloppen bij het event type (issue vs. pull request). Een onjuiste property-check kan beveiliging onderuit halen.
- Minimeer credential exposure in workflows: geef tokens alleen door aan stappen waar ze strikt nodig zijn.
- Monitor en roteer bij twijfel: zelfs als er geen bewijs van misbruik is, is tokenrotatie een effectieve schadebeperking.
Wil je meer context over dit soort supply-chain risico’s en hoe aanvallen via ontwikkel- en automatiseringsketens verlopen? Lees dan ook ons stuk over een supply chain aanval via LiteLLM en bekijk welke patronen daarin terugkomen rond afhankelijkheden en pipeline-gedrag.
Conclusie: een CI/CD-injectie die je niet moet onderschatten
De GitHub Actions flaw in de Snowflake-repository laat zien hoe snel een pipeline-automatisering kan veranderen in een aanvalsvector. Door crafted issue data direct te gebruiken in een shell run-blok konden onderzoekers command injection uitproberen, met als extra complicatie dat JIRA-credentials onderdeel waren van het workflowpad.
Snowflake heeft de kern van de fout verholpen door de inputverwerking te herstructureren en het getroffen token te roteren. Hoewel er volgens de beschikbare informatie geen bewijs is van een succesvolle ongeautoriseerde toegang buiten het testkader, blijft het belangrijkste signaal staan: CI/CD is code, en input van buitenaf moet je behandelen als potentiële vijandige data.
Door je workflows te toetsen op directe interpolatie, event-voorwaarden en credential-hygiëne, verlaag je de kans dat een vergelijkbaar patroon ooit opnieuw tot command injection leidt.
Bron: https://thehackernews.com/2026/08/snowflake-github-actions-flaw-lets_0330881554.html
