Copilot Autofix Carries a New Kind of Supply-Chain Risk
One AI tool co-authored a script injection flaw into Snowflake's public repo. Five days later, a different AI tool walked through the door, grabbed Jira credentials, and read engineering, security, and bug-bounty projects. The commit history is public. The question is what you do with that information before it happens to you.

TITLE: Copilot Autofix Carries a New Kind of Supply-Chain Risk BODY:
Snowflake patched the vulnerability the same day Wiz reported it. That is the only reason this is a cautionary tale and not an incident report.
On June 18, 2026, pull request #1218 was merged into Snowflake's snowflake-connector-net repository, with the final squash commit crediting "Copilot Autofix powered by AI" as a co-author. That commit introduced a script injection bug in run: blocks by removing the repository's existing sanitized input pattern and replacing it with direct string expansion in a shell script. Five days later, an autonomous AI system found it, weaponized it, and exfiltrated credentials before any human reviewer noticed.
This is the first documented closed-loop AI vulnerability chain with a public commit trail.
What Actually Happened
The bug sat in the jira_issue.yml workflow, which fired on issues: opened and interpolated the attacker-controlled title straight into a run: block, giving arbitrary command execution on the Actions runner to any unauthenticated GitHub user.
Wiz's Red Agent, an AI-powered autonomous attacker, found the flaw during a routine scan on June 23. "We crafted an issue title that, after template expansion, breaks out of the echo string and exfiltrates the Jira credentials via an out-of-band callback," Wiz's head of threat exposure Gal Nagli said. Those credentials gave Wiz read access to Snowflake's engineering, security compliance, and bug bounty tracking projects.
Red Agent independently discovered and exploited the flaw, validated access to sensitive data, and assessed blast radius, all without human intervention, five days after the vulnerability went live.
One detail complicates the narrative: GitHub disputes clean authorship. The explicit Copilot co-authored commit changed jira_close.yml, while the unsafe jira_issue.yml refactor appears in a separate August 25, 2025, commit by a human engineer. Both were folded into the June 18 squash merge, which lists Copilot Autofix among co-authors. The history confirms Copilot participation in PR #1218, but not authorship of the vulnerable lines.
That distinction matters less than it seems.

The Part That Should Worry You
Whether Copilot wrote the vulnerable line or co-signed the PR containing it, the structural failure is identical: an AI-assisted workflow shipped an injection flaw that a prior safe pattern had explicitly prevented. Automated AI assistants often lack historical context regarding why specific code patterns were chosen. Here, an automated PR removed a safe env: + jq parsing pattern explicitly implemented to prevent shell injection.
Translation: the model does not know what it is undoing.
This is the scaling problem inside Autofix. Fixes can be applied directly within pull requests, enabling developers to resolve issues without leaving their workflow. The faster the loop, the fewer human eyes touch each change. That is the pitch and the exposure.
GitHub documented this injection class in July 2025, warning against expanding untrusted issue data directly inside run: blocks. The documentation and safe pattern both existed. AI reversed the pattern anyway.
If you are running Autofix on public repositories without mandatory human review of every workflow file it touches, you are betting the model's accuracy outpaces attack-tool sophistication. Wiz just showed you the other side.
Any workflow triggered by issues, issue_comment, pull_request_target, or discussion that places ${{ github.event.* }} inside a run: block is exploitable the same way. Copilot Autofix did not invent a novel attack surface. It regenerated a well-understood one in a context where humans had already patched it out.
The Jira token was rotated on June 24, and Snowflake found no unrelated external use during the five-day exposure window. Snowflake got lucky. The next target may not.
What to Watch
First, GitHub's response: do they mandate human review for Autofix changes to workflow files, or absorb this as documentation and move on? That answer signals how seriously they take liability. Second, enterprise adoption: watch whether large Copilot customers quietly block Autofix from .github/workflows/ without human sign-off. That signal appears in GitHub Advanced Security feedback before any announcement. Third, the incident class itself: critical vulnerabilities can now be introduced and approved within AI-agent workflows, while autonomous AI security agents rapidly discover and exploit them. Wiz ran this on public repos. Other Red Teams are running identical tools right now. The question is not whether this happens again. It is whether the next team patches same-day.
- Red Agent Exploits Snowflake Vuln Missed by Github Copilot | Wiz Blog
- An AI broke Snowflake's code. Then another AI agent exploited it | The Register
- Snowflake GitHub Actions Flaw Lets Crafted Issues Trigger Command Injection | The Hacker News
- GitHub Copilot Missed A Vulnerability That Wiz's AI Agent Found | Forbes
- Copilot Autofix Bug Exposed Snowflake's Internal Jira - Cyber Kendra
- The SolarWinds Attack | Wiz Blog
- The Front Page
- Zeli - Daily Hacker News, Summarized
- AI-Generated GitHub Copilot "Autofix" Allowed Compromise of Snowflake's Jira | Hacker News
- GitHub Copilot Security Risks: 5 Issues + Fixes (2026) - Checkmarx