An AI 'Autofix' Created a Critical Security Hole in Snowflake's Code — and an AI Agent Found It 5 Days Later

In a story that reads like a cautionary tale about the age of AI-assisted development, Wiz Research's autonomous "Red Agent" discovered a critical vulnerability in Snowflake's GitHub repository — a vulnerability that was introduced by a GitHub Copilot "Autofix" commit just five days earlier. The AI-assisted code change replaced a safe input sanitization pattern with a direct string interpolation that allowed arbitrary command execution. Another AI then found and exploited it.

Here's what happened, why it matters, and what it tells us about the future of AI-assisted software development.

The Vulnerability

The vulnerability was in Snowflake's snowflake-connector-net repository, specifically in a GitHub Actions workflow file called jira_issue.yml. This workflow triggered whenever a GitHub issue was opened, and it used the issue title in a shell command.

The safe pattern that existed before the vulnerability used environment variables and jq to safely pass the issue title:

env:
  ISSUE_TITLE: ${{ github.event.issue.title }}
run: jq -n --arg title "$ISSUE_TITLE" ...

On June 18, 2026, PR #1218 was merged — co-authored by "Copilot Autofix powered by AI" — which replaced this safe pattern with direct template interpolation:

run: |
  TITLE=$(echo '${{ github.event.issue.title }}' | sed 's/"/\\"/g' | sed "s/'/\\'/g")

This is a classic script injection vulnerability. The sed escaping runs after GitHub's template expansion, so a single quote in the issue title breaks out of the echo '...' wrapper and allows arbitrary command execution. Any GitHub user could trigger this simply by opening an issue with a crafted title.

The "Security Gate" That Wasn't

The workflow had an if condition that appeared protective:

if: (github.event_name == 'issues' && github.event.pull_request.user.login != 'whitesource-for-github-com[bot]')

But on issues events, github.event.pull_request is always null. So the condition reduces to null != 'whitesource-for-github-com[bot]' — which is always true. Every GitHub user passes the gate.

Enter the Red Agent

Wiz Research's "Red Agent" — an autonomous, AI-powered security research tool — scanned Snowflake's GitHub organization as part of ongoing security research through Snowflake's HackerOne program. It flagged the jira_issue.yml workflow as vulnerable to script injection.

What happened next is remarkable. When Red Agent's first exploitation attempt using a # comment character caused a bash syntax error (because it consumed the closing parenthetical of TITLE=$(...)), the agent autonomously analyzed the error, adjusted its payload to use ; echo ' to properly close the shell block, and successfully exfiltrated Jira credentials via an out-of-band callback.

Within seconds, the listener received a callback from a GitHub Actions runner containing base64-encoded credentials. The token authenticated as [e-mail] to Snowflake's internal Jira, granting read access across engineering, security compliance, and bug bounty tracking projects.

The Timeline

• June 18, 2026: The vulnerability became live when PR #1218 (co-authored by Copilot Autofix) was merged
• June 23, 2026: Wiz Red Agent identified, exploited, and reported the vulnerability
• June 23, 2026: Snowflake patched the vulnerability the same day
• June 24, 2026: Jira token rotated
• August 17, 2026: Public disclosure

Five days from introduction to discovery. That's the new reality.

Key Takeaways

AI Code Generation Demands Rigorous Oversight

AI coding tools predict code based on probabilistic patterns. In this case, Copilot Autofix removed a safe env: + jq parsing pattern and replaced it with direct string interpolation — reintroducing a vulnerability that the repository had explicitly guarded against. AI-generated PRs must undergo the same static analysis and security scrutiny as human code.

Collapsing Discovery Windows

The vulnerability was live for only five days before an automated agent discovered it. This cuts both ways: it's good that the bad actor was a security researcher rather than a malicious attacker, but it also means the window between "vulnerability introduced" and "vulnerability exploited" is shrinking dramatically. Security operations must adapt to a landscape where automated discovery occurs in hours.

Preventing AI Security Regressions

The most insidious failure mode here is that the AI didn't introduce a new vulnerability — it removed an existing protection. Automated AI assistants often lack historical context about why specific code patterns were chosen. The safe env: + jq pattern existed for a reason, and the AI had no way to know that.

Security teams should implement guardrails that block AI agents from replacing structured data parsers with direct string interpolation. The pattern of "AI removes a security control because it looks unnecessary" is going to become more common as AI-assisted development becomes the norm.

The Bigger Picture

This incident is a microcosm of the AI security arms race. On one side, AI coding tools are generating code at unprecedented speed — and sometimes introducing vulnerabilities. On the other side, AI security agents are scanning and exploiting those vulnerabilities at unprecedented speed. The humans are increasingly in the middle, trying to keep up.

The good news: in this case, the system worked. The vulnerability was found by a researcher, reported responsibly, and patched quickly. But the next time, the discoverer might not be a friendly security firm. As AI-assisted development becomes standard, we need to assume that every vulnerability will be found quickly — because it will be.