Security firm Wiz published findings on August 17, 2026 about a GitHub Actions vulnerability in a public Snowflake repository. Crafting the title of a GitHub issue — something any user can open — was enough to run arbitrary commands on a CI runner, and from there to exfiltrate credentials for the company’s internal Jira1.
The incident itself happened in June and was patched the same day it was reported. What drew attention to the write-up is the sequence around it. The pull request that introduced the vulnerable pattern lists “Copilot Autofix powered by AI” as a co-author that checked it. And the thing that found and actually exploited the flaw five days later was Wiz’s autonomous AI tool, “Red Agent”1. Wiz frames this as a new reality in which “critical vulnerabilities can still be introduced and approved within workflows involving AI coding agents, while autonomous AI security agents can rapidly discover and exploit them in the wild”1.
An issue title that reaches the shell
The problem sat in a workflow called jira_issue.yml in the snowflakedb/snowflake-connector-net repository. It handles Jira credentials and triggers on issues: opened — meaning any GitHub user could fire it simply by opening an issue1.
That workflow interpolated the attacker-controlled issue title directly into a shell script1. There was code to handle quotes in the title with sed, but that escaping runs after GitHub’s template expansion. Because the order is backwards, a single quote in the title is enough to break out of the string and execute arbitrary commands1.
The repository’s earlier code had passed the issue title through an env: variable and built the JSON with jq — the standard move of treating external input as structured data rather than concatenating it as a string. The merged PR removed that safe pattern and replaced it with direct string expansion1.
There was also something that looked like a defense. The workflow carried an if: condition excluding a particular bot, but on issues events, github.event.pull_request is always null. The condition therefore collapses to “null is not equal to that bot name,” which is always true. Every GitHub user passed the gate1. That is a check that exists but does not work, and this part reads independently of any AI involvement.
Discovered in five days, reaching read access to Jira
By Wiz’s account, Red Agent’s CI/CD capability scanned Snowflake’s GitHub organization and flagged this workflow as vulnerable because it handled untrusted input inside a run: block1.
The behavior after the first attempt failed is the part being noticed. Red Agent’s initial payload returned a shell syntax error; rather than stopping or failing, the agent analyzed the error on its own, reworked the payload, and got the out-of-band callback to land — that is Wiz’s description of it1. Within seconds, base64-encoded credentials arrived from a GitHub Actions runner1.
The exfiltrated token authenticated to snowflakecomputing.atlassian.net as [email protected], granting read access across Snowflake’s engineering, security compliance, and bug bounty tracking projects1.
The actual impact needs reading precisely here. Wiz confirmed that all data accessed during proof-of-concept testing was securely deleted, and audit log analysis found no evidence that any external third party accessed the endpoint during the five-day exposure window; all anomalous queries matched Wiz’s testing IPs1. Snowflake likewise stated that its investigation “found no evidence of unauthorized access”1.
The response was fast. Wiz reported through HackerOne on June 23, and Snowflake patched the workflow the same day, restoring the safe env: and jq --arg pattern1. The Jira token was rotated the next day, June 241.
Earlier coverage of OpenAI’s evaluation models escaping their sandbox and the UK AI Security Institute’s report on agents acting beyond their evaluation scope both described agents exceeding expectations inside an evaluation environment. What differs here is that the agent on the offensive side operated against a real external repository without a human in the loop.
Can you say “AI created the vulnerability”?
The hardest thing to characterize in this case is how far Copilot’s involvement went.
The body of Wiz’s post states that the vulnerable pattern went live with PR #1218, merged on June 18, and that its final squash commit credits “Copilot Autofix powered by AI” as a co-author1. The body also contains the line that “an AI ‘autofix’ commit created the very injection vector”1.
But Wiz added a correction to the top of the post the same day it published, at 19:57 UTC on August 17. It reads: Copilot was a co-author that checked the merged PR and code change, and identified it as all-clear without noticing the critical vulnerabilities. It is unclear whether the code change itself was AI-assisted1.
So what stands as Wiz’s own current account is not “AI wrote the dangerous code” but “AI reviewed that code and passed it.” Wiz also writes that GitHub’s AI-assisted security review did not flag the resulting critical vulnerability1. Because the stronger pre-update phrasing remains in the body, these two need to be taken apart when reading.
The distinction matters because it changes where a fix should point. An approach that only suspects the generation side and thickens human review does not fully cover the shape of this case, where an AI review was the thing issuing the all-clear.
Bringing it back to your own setup
Wiz lists three takeaways. AI-generated PRs must go through the same static analysis and security scrutiny as human code. Security operations should assume automated discovery happens in hours, which calls for rapid patch cycles and short-lived credentials. And security teams should implement guardrails that block AI agents from replacing structured data parsers with direct string interpolation1.
The reasoning Wiz attaches to the third is concrete. Automated AI assistants often lack the historical context for why a particular code pattern was chosen — and the env: + jq pattern removed here had been put in place explicitly to prevent shell injection1.
Applied to your own environment, the first place to look is clear: workflows that run on events anyone outside can trigger (opening an issue, commenting on a PR), and the list of secrets those workflows reference. In this incident, those two things lived in the same workflow. CI/CD is among the areas covered when Microsoft added a DevSecOps pillar to its Zero Trust Workshop on August 4.
The second is deciding in advance how PRs involving AI get handled. Shared packaging formats like Agent Plugins 1.0 are making the groundwork for putting agents into development workflows more solid. Neither “an AI fixed it, so it’s safe” nor “an AI fixed it, so it’s dangerous” — drawing the operational line at running the same checks regardless of who is credited as co-author is likely the more practical stance.
Snowflake says it is working with Wiz to share these learnings with the broader industry1.
Sources
- Wiz Red Agent Finds Its Way Into Snowflake’s Internal Jira Through a Flaw in a GitHub Copilot–Assisted PR - Wiz blog, Gal Nagli (August 17, 2026; top of post updated 19:57 UTC the same day)