A security fix written by GitHub’s Copilot Autofix and merged into a Snowflake repository on June 18, 2026 stripped out a sanitized input pattern and left the company’s CI/CD pipeline open to command injection, and five days later, an autonomous AI research agent found the hole, exploited it, and pulled working Jira credentials out of a GitHub Actions runner, Wiz Research disclosed on August 17, 2026.
The vulnerability sat 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 anyone opened a GitHub issue and interpolated the issue’s title (text fully controlled by the person filing) directly into a shell script. Because the trigger was issues: opened, any GitHub account on the internet could reach it without authentication.
Wiz’s “Red Agent,” an autonomous security research tool operating through Snowflake’s HackerOne bug bounty program, flagged the workflow, built a working exploit, and exfiltrated a Jira API token from the runner’s environment. Snowflake patched the workflow the same day it received the report, June 23, 2026, rotated the credential a day later, and told Wiz its audit logs showed no other actor touched the exposed systems during the five-day window.
The “Autofix” Removed the Sanitizer
The commit that introduced the injectable pattern landed through PR #1218, “SNOW-2069227: Update jira workflows”, merged June 18, 2026. The pull request’s history shows a human author working on the Jira automation since August 2025 — and, partway through, a commit co-authored by Copilot Autofix powered by AI, the GitHub Advanced Security bot that generates suggested fixes for code scanning alerts.
The AI suggestion changed how the workflow handled the issue title. The existing code passed the title through an env: variable and built its JSON payload with jq --arg, a pattern that keeps untrusted text out of the shell. The suggested replacement dropped that in favor of 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 title into the script. A single quote in the title breaks out of the echo '...' wrapper, and everything after it executes as shell. GitHub’s own documentation for Copilot Autofix 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 workflow also carried a guard condition that looked like it restricted who could trigger it:
“ if: (github.event_name == 'issues' && github.event.pull_request.user.login != 'whitesource-for-github-com[bot]') “
On issue events, github.event.pull_request is always null, so the comparison always evaluates true. Every GitHub user passed the gate.
An Agent on Each Side of the Exploit
Red Agent’s first exfiltration attempt failed. Its payload used a # comment character to swallow the rest of the injected line, but the comment also consumed the closing parenthesis of TITLE=$(...), and the runner returned a bash syntax error instead of executing. According to Wiz’s write-up, the agent analyzed 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 [email protected] against snowflakecomputing.atlassian.net, with read access across Snowflake’s engineering, security compliance, and bug bounty tracking projects.
Snowflake’s remediation, merged in PR #1402 on June 23, 2026, restored the safe env: variable and jq --arg parsing pattern. The Jira token was revoked and rotated on June 24, 2026. Wiz said it securely deleted all data accessed during its proof-of-concept testing.
“Snowflake appreciates Wiz’s responsible reporting of and collaboration around these findings through our vulnerability disclosure and bug bounty program, HackerOne,” the company said in a statement published with the Wiz report. “The disclosure was received on June 23, 2026, and it was immediately investigated and remediated, and our investigation found no evidence of unauthorized access.”
What the Five-Day Window Shows
The disclosure lands in the middle of a documented pattern: AI-assisted changes moving through review faster than the security assumptions around them. Snowflake’s own audit logs are what make this incident legible: they let the company state, and Wiz confirm, that the exposure window produced no third-party access. Snowflake’s audit log analysis confirmed no external third parties accessed the endpoint during the five-day window.
The timeline also compresses a sequence the industry has treated as hypothetical. A coding assistant removed a defensive pattern that had been put in place specifically to prevent shell injection, because the assistant had no record of why that pattern existed. An offensive agent then found and weaponized the result in days, self-correcting its exploit against live error output. The exploit side ran without a human at the keyboard; on the coding side, the AI generated the change but a human applied the suggestion and merged it — which is exactly the review step that failed.
Wiz’s report recommends that AI-generated pull requests pass through the same static analysis as human code, that teams shorten credential lifetimes to match automated discovery speeds, and that guardrails block agents from replacing structured parsers with direct string interpolation. Check Point moved prompt inspection for AI traffic into enterprise firewalls earlier this summer, and Unite.AI has covered agent sandbox escapes and agentic systems reaching real production targets as the offensive side matures. The Snowflake incident is the same story told from inside a CI pipeline: the vulnerability was live for five days, and the only reason it reads as a case study rather than a breach notification is which agent got there first.
