Wiz Red Agent exploited a GitHub Actions injection at Snowflake

Wiz Research’s autonomous offensive tool, Red Agent, found and used a script-injection bug in a public Snowflake GitHub Actions workflow five days after the change went live. Anyone with a GitHub account could run commands on a runner by opening an issue with a crafted title. The proof of concept reached a token for Snowflake’s internal Jira.

Wiz disclosed the finding through Snowflake’s HackerOne program on June 23, 2026. Snowflake patched the workflow the same day, rotated the affected credential, and said its investigation found no evidence of unauthorized access. Wiz says detailed audit logs showed it was the only actor in the exposure window, and that it securely deleted the data from its tests.

The Hacker News and Forbes both reported the case on August 17, 2026, the day Wiz published its research.

The change that went live on June 18

The vulnerable workflow was jira_issue.yml in snowflakedb/snowflake-connector-net, Snowflake’s public .NET connector. It became live when pull request #1218, “SNOW-2069227: Update jira workflows,” was squash-merged on June 18, 2026.

That merge removed a safer pattern that passed the issue title through an env: variable and parsed it with jq --arg. The replacement interpolated ${{ github.event.issue.title }} straight into a run: shell block. The workflow triggered on issues: opened, so any GitHub user could fire it.

A condition on the job looked like a filter against a known bot account. Wiz says the check used github.event.pull_request, which is always null on issue events, so the comparison always evaluated true. Escaping with sed ran only after GitHub expanded the template, which meant a quote in the title could break out of the shell string.

Red Agent’s CI/CD scan flagged untrusted input in those run: blocks. Wiz says the agent’s first title failed with a bash syntax error; it then adjusted the payload and received an out-of-band callback with the runner’s Jira secrets. Exploit mechanics beyond that stay in Wiz’s post. The operational point is that an unauthenticated issue was enough.

What the token could read

The exfiltrated credential authenticated as qa@snowflake.net to snowflakecomputing.atlassian.net. Wiz says it granted read access across Snowflake’s engineering, security compliance, and bug bounty tracking projects. Wiz published a screenshot of Snowflake’s Jira portal opened with that token.

The scan that stayed quiet

GitHub Advanced Security analyzed the final pull-request revision, including the vulnerable workflow, and did not flag the injection. That is the part security teams can act on: a known-bad interpolation replaced a known-good parser, and the installed scanner still passed the file.

Copilot’s involvement is narrower than a “Copilot wrote the bug” headline. Wiz updated its blog on August 17, 2026, at 1957 UTC to say Copilot was a co-author that checked the merged pull request and marked the change all-clear without noticing the injection. Wiz also says it is unclear whether the vulnerable edit was AI-assisted, and that Copilot Autofix’s documented contribution in the same PR was a separate fix to jira_close.yml, not the injectable lines in jira_issue.yml.

Forbes, in a same-day update, reported that GitHub completed an internal review and stated the contributions that introduced the vulnerability were authored by a human and were not reviewed by or contributed to by Copilot. Those two accounts do not fully line up. What is solid across the sources is the squash merge, the Advanced Security miss, and the five-day window — not a proven claim that Copilot authored the injectable workflow.

Patch, rotation, and Snowflake’s statement

Snowflake restored the env: and jq --arg pattern in commit 1dc7766 (pull request #1402) on June 23. The Jira token was rotated on June 24. Wiz’s timeline lists HackerOne report #3819931 and a Slack notice to Snowflake security on the day of discovery. Snowflake’s disclosure policy set a public deadline of July 25, 2026, 30 days after resolution.

Snowflake said it appreciated the report, investigated and remediated immediately, and found no evidence of unauthorized access. It also said it is working with Wiz to share the lessons more widely.

A short window, two kinds of agents

This is not a new class of GitHub Actions bug. It is a concrete case of CI code losing basic injection hygiene — after a safer pattern was already in the repo — while another agent independently found and used the hole. Gal Nagli, Wiz’s head of offensive security, told Forbes: “it was autonomously exploited and found by our AI. We didn’t need to intervene, which means frontier models already can exploit supply chain risks by themselves.”

Wiz’s published takeaways match that timeline. Treat AI-touched pull requests with the same static analysis as human code. Assume automated discovery can land in hours, which argues for short-lived CI secrets. And enforce the safe Actions pattern so a later edit cannot silently swap jq --arg for raw interpolation.

If you maintain issue-triggered workflows, read Wiz’s disclosure next and check every run: block that interpolates github.event fields. Then look at what GitHub Advanced Security actually reported on those files. This incident shows a scanner can extract a vulnerable workflow and still say nothing.