Wiz’ Red Agent vond Snowflake-fout vijf dagen na livegang

Dat verschil was cruciaal. GitHub vult de expressie in voordat de shell de opdracht uitvoert. Een speciaal gemaakte issue-titel met bijvoorbeeld een enkel aanhalingsteken kon daardoor de bedoelde tekenreeks afsluiten en vervolgens eigen shell-opdrachten toevoegen. Een daaropvolgende bewerking met sed kon dat niet meer ongedaan maken: de shell had de invoer dan al geïnterpreteerd.

Ook de trigger

issues: opened

De commit vermeldde “Copilot Autofix powered by AI” als mede-auteur, en de AI-ondersteunde beoordeling signaleerde het probleem niet. De beschikbare informatie bewijst echter niet of Copilot de onveilige wijziging zelf heeft gegenereerd of een door een mens geschreven wijziging alleen heeft mee beoordeeld. De zorgvuldigste conclusie is daarom dat Copilot aan de wijziging was verbonden en de injectiefout niet heeft ontdekt — niet dat het auteurschap van het model definitief vaststaat.

Hoe Red Agent de fout vond

Wiz’ Red Agent scande de openbare GitHub-organisatie van Snowflake op risicovolle CI/CD-patronen. Het systeem zag dat de Jira-workflow onbetrouwbare issuegegevens gebruikte binnen een shell-run:-blok en concludeerde dat een speciaal gemaakte openbare issue-titel willekeurige opdrachten kon uitvoeren op de GitHub-hosted Actions-runner.

Op 23 juni — vijf dagen nadat de kwetsbare wijziging was samengevoegd — opende de agent een speciaal gemaakt issue als onderdeel van Snowflakes programma voor kwetsbaarheidsmeldingen op HackerOne. De titel brak uit de shell-tekenreeks, waarna de workflow Jira-inloggegevens verstuurde naar een out-of-band callback die voor deze geautoriseerde proof of concept werd beheerd.

Dit was geen ongecontroleerde inbraak, maar een goedgekeurde veiligheidstest. De technische bevinding was desondanks reëel: een openbaar issue kon een workflowstap bereiken die met interne inloggegevens werkte en zo gewone issue-aanmaak veranderen in het uitvoeren van shell-opdrachten.

Welke toegang zichtbaar werd

De gecompromitteerde workflow had toegang tot de interne Jira-configuratie van Snowflake, waaronder de Jira-URL, het gebruikersadres en een API-token. Het teruggevonden token was gekoppeld aan qa@snowflake.net. Wiz gebruikte het om zich aan te melden bij het interne Jira-portaal en de mogelijke reikwijdte van de blootstelling te beoordelen.

Volgens de berichtgeving was er lees toegang tot Jira-projecten rond engineering, beveiligingscompliance en bugbounty-activiteiten. De aangeleverde informatie geeft geen volledige lijst van de rechten van het token en ook geen definitieve inventaris van alle records die bereikbaar waren. De sterkst onderbouwde conclusie is daarom dat het token toegang gaf tot gevoelige interne Jira-inhoud, niet dat het onbeperkte toegang tot Snowflake-systemen bood.

Het getroffen onderdeel was de CI/CD-automatisering van de repository. Er is geen getroffen, uitgebrachte versie van de Snowflake Connector voor .NET gemeld, omdat de fout in de GitHub Actions-workflow zat en niet in de runtimecode van de connector.

Reactie van Snowflake

Wiz meldde de kwetsbaarheid op 23 juni. Snowflake herstelde de workflow nog diezelfde dag en roteerde de blootgestelde Jira-inloggegevens de dag erna.

Daarna onderzocht Snowflake de auditlogs. Het bedrijf concludeerde dat Wiz in de blootstellingsperiode de enige actor was. Wiz verklaarde bovendien dat het de gegevens uit de proof of concept veilig had verwijderd.

Er is geen ongeautoriseerde toegang door derden gemeld. Ook is geen CVE-nummer toegekend en is geen getroffen connectorrelease geïdentificeerd. Die beperkingen beschrijven de bevestigde impact, maar maken het oorspronkelijke workflowontwerp niet veilig. Een openbare issue-titel had nooit onderdeel mogen worden van een shell-opdracht in een workflow die interne inloggegevens verwerkte.

De les voor CI/CD

De praktische les reikt verder dan Snowflake en Copilot. GitHub-expressies zoals issue- en pull-requesttitels, branchnamen en reacties moeten als vijandige invoer worden behandeld zodra ze in een shell-opdracht terecht kunnen komen.

Veiliger workflowontwerp betekent onder meer:

• Geef onbetrouwbare waarden door via omgevingsvariabelen in plaats van ze rechtstreeks in run:-scripts te interpoleren.
• Gebruik gestructureerde hulpmiddelen zoals jq om JSON op te bouwen, in plaats van shelltekenreeksen handmatig samen te stellen.
• Quote en valideer gegevens op de grens met de shell.
• Houd inloggegevens zo veel mogelijk weg bij stappen die aanvallergestuurde inhoud verwerken.
• Beoordeel door AI gegenereerde beveiligingswijzigingen net zo kritisch als code die door mensen is geschreven.

Deze gebeurtenis laat een nieuw spanningsveld rond AI in beveiliging zien: het ene AI-systeem kan een gevaarlijke CI/CD-wijziging missen, terwijl een autonoom offensief systeem die binnen enkele dagen vindt en valideert. Automatisering kan zowel herstel als misbruik versnellen — maar vervangt geen onafhankelijke controle.