WHAT IS ESTABLISHED, AND WHAT IS NOT
● Established: a script injection in jira_issue.yml let an unauthenticated user run commands in a GitHub Actions runner via a crafted issue title.
● Established: Wiz Red Agent found it, exploited it and mapped the blast radius autonomously, five days after it went live.
● Not established: that Copilot Autofix wrote the vulnerable lines. Commit history points elsewhere.
● Genuinely disputed: whether GitHub's AI reviewed the change and cleared it. Wiz says yes. GitHub says no.
The mechanism
The repository, snowflakedb/snowflake-connector-net, ran a GitHub Actions workflow that opened a Jira ticket whenever someone filed an issue.
The safe version of that workflow did what GitHub's own guidance recommends: it stored the issue title in an environment variable first, then passed it to jq as an argument. Untrusted input never touched the shell directly.
WHAT THE UNSAFE VERSION DID
The refactor interpolated the issue title directly into a shell echo command, adding sed-based escaping to sanitise it. The sanitisation ran after GitHub's template expansion.
By then the attacker-controlled text is already part of the script. A single quote character in the issue title breaks out of the quoted string before any escaping applies, and everything after it is executed as shell.
A second failure let anyone through the door. A conditional gate checked pull_request.user.login. On an issue event, pull_request is null, so the check evaluated true — the gate designed to restrict who could trigger the workflow admitted unauthenticated users instead.
Combined: open an issue, choose your title carefully, and arbitrary Bash runs in the Actions runner. Wiz used this to exfiltrate a Jira token with read access to engineering, security compliance and bug bounty projects.
The agent did the whole chain by itself
Wiz Red Agent is an autonomous AI security research tool. During authorised testing through Snowflake's HackerOne programme, it:
- Scanned Snowflake's GitHub organisation and flagged the workflow as vulnerable to script injection via untrusted input in a run block
- Built and fired an exploit — the first payload produced a shell syntax error, and the system changed approach on its own
- Received an out-of-band callback confirming execution
- Exfiltrated the token, validated the internal access it granted, and assessed the blast radius
No human intervened at any step. That is the part of this story with a longer shelf life than the attribution argument. The window between a flaw shipping and an autonomous system finding, weaponising and scoping it was five days.
How "AI wrote a vulnerability" happened
The merge commit for PR #1218 lists Copilot Autofix powered by AI among its co-authors. Wiz's original post read that as the AI having introduced the injection. Most coverage repeated it.
Reading the commits underneath tells a different story:
| Commit |
What it changed |
Attributed to |
| Copilot co-authored commit |
jira_close.yml — a different file |
Copilot Autofix |
| August 2025 commit |
The unsafe jira_issue.yml refactor |
A named Snowflake engineer |
| June 18, 2026 squash merge |
Both, folded into one |
Lists Copilot among co-authors |
Squashing collapses every commit in a pull request into a single one and carries all co-author trailers forward. The line records participation in the pull request. It says nothing about which author touched which lines.
Wiz updated its post on August 17 at 19:57 UTC to clarify that Copilot was a co-author which checked the merged change and marked it all-clear, and that whether the code change itself was AI-assisted is unclear.
Worth noting for anyone tempted to file this as an AI failure: GitHub published guidance in July 2025 warning against exactly this pattern — expanding untrusted issue data directly inside run blocks, with intermediate environment variables as the recommended fix. That guidance predates the commit that introduced the problem by about a month.
The claim that is actually in dispute
TWO INCOMPATIBLE STATEMENTS
Wiz: the GitHub Advanced Security scan, which uses Copilot Autofix, analysed the final PR revision including the vulnerable workflow and did not flag the injection.
GitHub: Copilot Autofix never reviewed the code at all.
These cannot both be correct, and only one party holds the scan logs that would settle it. Neither has published them.
The distinction is not academic. "An AI security scanner examined this and passed it" is a product defect claim. "The scanner never ran on this path" is a coverage gap. Teams buying AI code review need to know which one they are getting, and right now the two companies involved are describing different products.
What is and is not confirmed about impact
- No CVE. No CVSS score, and no entry in the US catalogue of known exploited vulnerabilities.
- No shipped release affected. The weakness sat in repository automation, so no connector build carried it.
- Snowflake's position: disclosure received June 23, 2026, investigated and remediated immediately, no evidence of unauthorised access found.
- Everything about blast radius rests on the two companies' accounts. Snowflake's audit logs, the Jira permission set and the workflow run are not public.
Go check this in your own repos
The pattern is common and the fix is small. Regardless of who wrote what here, this is the transferable part.
| Check |
What you are looking for |
| Untrusted input in run blocks |
Issue titles, PR titles, branch names, comment bodies expanded directly into shell. Move them to env vars |
| Sanitisation order |
Escaping applied after template expansion is escaping applied too late |
| Null-context conditionals |
Gates referencing pull_request fields on workflows that also fire on issue events |
| Token scope in workflows |
Integration tokens with read access far beyond what the workflow needs |
| Squash merge attribution |
If you use co-author trailers for audit, squashing destroys per-line attribution |
The lesson that survives whoever is right
Two AI systems were involved on opposite sides. The offensive one found, exploited and scoped a live vulnerability in five days with no human in the loop. The defensive one either missed it or never ran.
That asymmetry is the story. Autonomous offensive tooling is now demonstrably faster than the review layer meant to catch what it targets, and the review layer's own vendor and a third-party researcher cannot agree on whether it even executed. If your security posture assumes an AI scanner is a backstop, this incident is an argument for treating it as one signal among several rather than a gate.
FAQ
Did Copilot Autofix write the vulnerable code?
Not established. The co-author trailer on the squash merge records participation in the pull request. Commit history attributes the unsafe jira_issue.yml refactor to a named engineer in an August 2025 commit, while Copilot's explicit commit changed a different file.
So is Wiz wrong?
On authorship, the commit history does not support the original framing, and Wiz has since updated its post. On the separate claim that GitHub's scan analysed the final revision and missed the injection, Wiz maintains its position and GitHub contradicts it. That one is open.
How did an issue title become a shell command?
The workflow interpolated the title directly into a shell command, and applied escaping only after GitHub had already expanded the template. A quote character in the title terminated the string early, so the remainder ran as shell. The safe pattern passes the title through an environment variable instead.
Why did the permission check not stop it?
The gate inspected a pull_request field, which is null on issue events, so the condition evaluated true and let unauthenticated users through. Conditionals that reference one event context on a workflow triggered by another are a recurring source of this failure.
Should I stop using AI code review tools?
No, but stop treating them as a gate. Use them as one signal alongside pinned actions, least-privilege tokens, and manual review of anything touching workflow files. The specific pattern here was documented by GitHub in July 2025 and still shipped.
Is my Snowflake connector affected?
No. The flaw was in repository CI automation, not in the connector library, so no released version carried it.