Wiz's AI agent exploited a Snowflake CI flaw, and who wrote it is disputed

Security firm Wiz says its autonomous "Red Agent" found and exploited a command-injection flaw in a Snowflake GitHub Actions workflow, then used it to pull an internal Jira API token, according to its writeup. That part is not contested. What is contested is the headline everyone ran with: that GitHub Copilot Autofix wrote the vulnerable code. GitHub says a human did. Wiz has since revised its own post.

The dispute

Wiz's original framing was a closed AI loop: one AI introduced the weakness, another AI walked through it. GitHub disputes the first half. After an internal review, GitHub's position, reported by The Next Web, is that the contributions that produced the vulnerability were authored by a human, and were not reviewed by or contributed to by Copilot.

The commit history is the reason this is arguable rather than simply wrong. Copilot did participate in pull request #1218. But the commit explicitly carrying a Copilot co-author trailer changed a different file, jira_close.yml. The unsafe refactor of jira_issue.yml, the file that actually carried the injection, sits in a separate commit attributed to a Snowflake engineer account. Copilot was in the pull request. The evidence that it typed the vulnerable lines is not there.

Wiz softened the claim rather than withdrawing it. Its revised position is that Copilot acted as a co-author that reviewed the merged pull request and called it clear without noticing the vulnerability, and it added the concession that it is unclear whether the code change was AI-assisted at all. That is a materially different and much weaker claim than "Copilot Autofix wrote this bug," and it is the one now on the page. The Register ran the original AI-broke-it-then-AI-exploited-it version before the revision.

The operator facts

Strip out the authorship fight and a straightforward CI/CD failure remains, with a clean timeline.

• The bug. A workflow named jira_issue.yml in Snowflake's public snowflake-connector-net repository ran whenever someone opened an issue, and interpolated the issue title and body directly into a shell command. Attacker-controlled text became attacker-controlled code. This is the oldest GitHub Actions mistake there is.
• Merged 18 June 2026, in PR #1218.
• Reported 23 June 2026, via HackerOne. That is a five-day exposure window on a public repository where anyone with a GitHub account could open an issue.
• Patched the same day, 23 June, by replacing the unsafe expression with environment variables.
• Token rotated 24 June 2026, the following day.
• GitHub Advanced Security scanned the merged workflow and did not flag the injection. This is the finding with the longest shelf life, and it has nothing to do with who wrote the code.
• No CVE was assigned. This was a flaw in one organization's repository configuration, not in shipped software, so there is no identifier to track and nothing to match against in your scanner.

What the Red Agent reached: the same workflow step loaded Snowflake's internal Jira credentials. The crafted issue triggered the injection, the runner made an out-of-band callback, and the token came back. It granted read access to internal Jira projects covering engineering, security compliance and bug-bounty tracking. Snowflake says no customer data was involved, and that its audit logs showed no unauthorized third-party access beyond the authorized test.

The takeaway

Three things to do, none of which depend on how the GitHub and Wiz argument resolves.

Treat AI-suggested fixes as drafts that need a human reviewer, and do not let "Copilot reviewed it" stand in for that review, because in this case something signed off on a merged pull request and called it clear. Audit your Actions workflows for any place raw issue, pull-request or branch text is expanded into a run: block, and move it to an environment variable, which is the exact fix Snowflake shipped. And if you had a CI token in a workflow like this, go check the rotation date rather than assuming it happened. Snowflake's rotation was a day after the patch. A rotation you cannot point to on a calendar did not happen.