A single unsafe line in a GitHub workflow left one of Snowflake’s public repositories open for five days, and the thing that found it was not a human researcher. Wiz’s Red Agent, an autonomous AI security tool, scanned the snowflake-connector-net project, spotted a command-injection flaw, built a working exploit, and pulled an internal Jira token out of the system, all without a person driving. It managed this in the same short window that GitHub’s own automated scanner looked at the code and waved it through.
The bug lived in a workflow that opened a Jira ticket whenever someone filed a GitHub issue. The problem was how it handled the issue title. Because that attacker-controlled text was dropped straight into a shell command, a carefully crafted title could break out of the string and run commands on the GitHub runner. An earlier, safer version had passed the title through an environment variable and parsed it cleanly, but a later change swapped that protection for direct interpolation. A second guardrail that should have limited who could trigger the workflow was checking the wrong kind of event, so in practice any GitHub user could set it off.
What the agent reached
Once inside the runner, the Red Agent grabbed the workflow’s Jira token, which authenticated as qa@snowflake.net and carried read access to internal projects covering engineering, security compliance, and bug-bounty tracking. That sounds alarming, and it is not nothing, but the blast radius had limits. The flaw sat in repository automation, not in any shipped version of the connector, and no customer data was exposed. When Wiz reported it through Snowflake’s HackerOne program on 23 June, Snowflake patched the workflow the same day, restored the safe parsing pattern, rotated the token, and checked its logs. Every suspicious query traced back to Wiz’s own test systems.
The part everyone argued about
Here is where the story got messy. Wiz’s initial write-up tied the vulnerable code to GitHub Copilot Autofix, the AI tool meant to fix security bugs, since the commit that carried the flaw listed Copilot as a co-author. GitHub pushed back hard, saying a human wrote the offending lines and Copilot neither authored nor reviewed them. A closer read of the commit history by The Hacker News backed that up: Copilot’s co-authored change touched a different file, while the unsafe edit came from a separate, human-attributed commit. Wiz then softened its claim to say Copilot had reviewed the change and missed it, which GitHub also disputes. No CVE was ever assigned, and the argument over who or what caused the bug remains unsettled.
That squabble is more than corporate finger-pointing. As AI tools write, review, and now attack code, working out what a human did and what a model did is becoming part of security itself. When a commit lists an AI as a co-author, what does that really mean?
The clean takeaways survive the noise. Never drop untrusted input straight into a shell command, give automation the narrowest and shortest-lived credentials you can, and treat any code an AI touched with the same suspicion as code from a stranger. An AI found this one in five days. The next one might not be a friendly researcher, and the window to catch it is only getting shorter.
This website uses cookies.