A security fix written by GitHub’s Copilot Autofix stripped a sanitised input pattern from a Snowflake repository, leaving the company’s CI/CD pipeline open to command injection. Five days later, an autonomous AI security agent discovered the flaw, built a working exploit, and exfiltrated Jira credentials from a GitHub Actions runner. The entire vulnerability lifecycle — introduction, detection, exploitation — was AI on both sides.
Wiz Research disclosed the incident on August 17, 2026, calling it evidence that “critical vulnerabilities can still be introduced and approved within workflows involving AI coding agents and can still pass established automated security checks, while autonomous AI security agents can rapidly discover and exploit them in the wild.”
🔍 THE BOTTOM LINE
The story here isn’t that AI coding tools produce bugs — humans do that too, at higher volume. It’s that the gap between introducing a vulnerability and exploiting it has collapsed from months to days, because both sides of the equation now run on AI. Copilot Autofix removed a sanitizer on June 18. Wiz’s Red Agent found and exploited it by June 23. No human touched either end of that chain until the responsible disclosure landed.
How Copilot Autofix Broke What Was Working
The vulnerability lived in jira_issue.yml, a GitHub Actions workflow in snowflakedb/snowflake-connector-net, the public repository for Snowflake’s .NET data connector. The workflow fired whenever someone opened a GitHub issue and needed to create a corresponding Jira ticket.
The existing code was safe. It passed the issue title through an env: variable and built its JSON payload with jq --arg — a pattern that keeps untrusted text out of the shell interpreter. According to Unite.AI’s analysis, Copilot Autofix, GitHub’s AI-powered code scanning fixer, suggested replacing that safe pattern with direct string expansion:
run: |
TITLE=$(echo '${{ github.event.issue.title }}' | sed 's/"/\\\"/g' | sed "s/'/\\\'/g")
The sed escaping runs after GitHub’s template engine has already substituted the issue title into the script. A single quote in the title breaks out of the echo '...' wrapper, and everything after it executes as shell. Because the trigger was issues: opened, any GitHub account on the internet could reach it without authentication.
The PR also carried a guard condition that looked like it restricted who could trigger the workflow. But on issue events, github.event.pull_request is always null, so the comparison always evaluated true. Every GitHub user passed the gate.
GitHub’s own Advanced Security scan analysed the final PR revision, including the vulnerable workflow, and did not flag the critical injection. A human merged the PR on June 18, 2026.
Red Agent: The AI That Found the Hole
Wiz’s “Red Agent” is an autonomous, AI-powered security research tool that operates through Snowflake’s HackerOne bug bounty program. It scanned Snowflake’s GitHub organisation, flagged the jira_issue.yml workflow as vulnerable to script injection via untrusted input, and then — without human intervention — built a working exploit.
The first attempt failed. The agent’s payload used a # comment character to swallow the rest of the injected line, but the comment also consumed the closing parenthesis of TITLE=$(...), producing a bash syntax error. According to Wiz’s write-up, the agent analysed the error, rewrote its payload to close the shell block with ; echo ', and tried again. The working payload, delivered as an issue title, base64-encoded the runner’s JIRA_API_TOKEN, JIRA_USER_EMAIL, and JIRA_BASE_URL environment variables and sent them to an out-of-band listener via curl.
The callback arrived from an Azure-hosted GitHub Actions runner within seconds. The recovered token authenticated as qa@snowflake.net against Snowflake’s Atlassian instance, with read access across engineering, security compliance, and bug bounty tracking projects.
Snowflake remediated the vulnerability on June 23 — the same day Wiz reported it — rotated the credential, and confirmed via audit logs that Wiz was the sole actor during the five-day exposure window. Forbes reported that Wiz confirmed all data accessed during proof-of-concept testing was securely deleted.
Wiz updated their blog post on August 17 to clarify that Copilot was a co-author that checked the merged PR and identified it as all-clear without noticing the critical vulnerabilities. It’s unclear whether the original code change was AI-assisted or human-written — but the autofix that reviewed it and passed it was AI.
What This Means for AI-Assisted Development
This incident exposes a structural tension in the AI coding tool ecosystem. The same class of tool that introduces vulnerabilities is also being sold as the tool that catches them. Copilot Autofix is GitHub’s AI feature for generating suggested fixes for code scanning alerts — it’s designed to improve security. In this case, it removed a sanitizer that was already doing its job.
The pattern isn’t unique to Copilot. We’ve covered this before — Microsoft’s Copilot Cowork was demonstrated exfiltrating SharePoint files via a single poisoned skill file. The broader AI agent credential crisis shows the same structural risk across the industry. Any AI coding assistant that modifies security-relevant code carries this risk. Claude, Cursor, Cody — they all generate code that gets merged into production pipelines.
What’s new here is the speed of the other side. An autonomous AI security agent found and exploited the vulnerability in five days, operating independently. The traditional security model — where a human researcher discovers a bug weeks or months after it ships — is being compressed. That’s good for defence if you have your own AI agent scanning your repos. It’s bad if you don’t and your adversary does.
NZ Angle
New Zealand’s software development sector leans heavily on GitHub-based CI/CD pipelines, and AI coding assistants are now standard tooling across most Wellington and Auckland dev teams. A flaw like this doesn’t require a targeted attack — it requires a public repo with an AI-suggested workflow change and anyone on the internet willing to open a GitHub issue. NZ companies running open-source connectors or public SDK repos should audit their GitHub Actions workflows for template injection patterns, regardless of whether they use Copilot Autofix.
❓ FAQ
Was Snowflake’s data actually compromised? Snowflake’s audit logs showed Wiz was the only actor during the five-day exposure window. The token was rotated, and Wiz confirmed all accessed data was deleted. No customer data was exposed.
Is GitHub Copilot Autofix still safe to use? GitHub’s documentation describes the feature as generating “a single suggested fix for an alert, which you review and apply yourself.” The review step is where this one got through. The tool is still in use, but this incident makes clear that AI-suggested security fixes need the same scrutiny as AI-suggested code changes.
How common are GitHub Actions injection vulnerabilities?
Script injection via untrusted input in run: blocks is a well-known class of vulnerability in GitHub Actions workflows. The risk isn’t new — but having an AI tool remove an existing sanitizer is a novel failure mode.
What’s the takeaway for development teams? AI coding assistants can both introduce and miss security vulnerabilities. The review step — whether human or automated — needs to check what the AI changed, not just whether the AI signed off on it. A diff that removes a sanitizer is a red flag regardless of who wrote the diff.
