Wiz Discloses GitHub Actions Workflow Injection in Snowflake Repo, Exposing a Live Jira API Token
Wiz's autonomous Red Agent found and exploited a GitHub Actions injection flaw in a Snowflake repo that GitHub's own scanner had missed, exfiltrating a live Jira token.
Overview
Security firm Wiz has disclosed a GitHub Actions workflow injection vulnerability in a public Snowflake repository that let an unauthenticated user execute arbitrary commands on a GitHub Actions runner simply by opening a crafted GitHub issue, according to Wiz. The flaw, in the snowflakedb/snowflake-connector-net repository, exposed a live Jira API token before Snowflake patched it, as also reported by The Hacker News. Wiz says the bug was found and exploited entirely by its autonomous “Red Agent” AI security research tool, without human intervention, five days after the vulnerable code went live, according to Wiz.
What We Know
The vulnerable pattern lived in jira_issue.yml, a workflow that triggered on issues: opened and interpolated the attacker-controlled issue title directly into a shell script rather than passing it through an environment variable, according to Wiz. Because the shell-escaping ran after GitHub’s own template expansion, a single quote inside an issue title could break out of the script and run arbitrary commands, Wiz explained.
A conditional check in the workflow appeared to gate execution to a specific bot account, but the check referenced github.event.pull_request.user.login — a property that does not exist on issue-triggered events. Per GitHub’s own documentation, quoted by The Hacker News: “If you attempt to dereference a nonexistent property, it will evaluate to an empty string.” That made the condition always evaluate to true, so every GitHub user passed the gate, according to Wiz.
Wiz traces the injection to pull request #1218 (“SNOW-2069227: Update jira workflows”), which was squash-merged on June 18, 2026 and removed the repository’s prior safe env: and jq parsing pattern in favor of direct interpolation of ${{ github.event.issue.title }} — a regression that GitHub Advanced Security’s scan reviewed but did not flag, Wiz said. The same repository, PR, and merge date are independently confirmed on GitHub.
Wiz’s Red Agent discovered the flaw while scanning Snowflake’s GitHub organization under its ongoing HackerOne bug-bounty engagement, according to Wiz. During exploitation, the agent’s first payload — using a # comment character to exfiltrate data — triggered a bash syntax error because the comment consumed the closing parenthesis of the script. Rather than stopping, Wiz says Red Agent “autonomously analyzed the syntax execution error” and adjusted its payload to properly close the shell block, then received an out-of-band callback from a GitHub Actions runner containing base64-encoded Jira credentials. The exfiltrated token authenticated as qa@snowflake.net and granted read access across Snowflake’s engineering, security-compliance, and bug-bounty Jira projects, Wiz said.
Wiz reported the vulnerability to Snowflake via HackerOne on June 23, 2026, and Snowflake patched the workflow the same day, restoring the safe env: and jq pattern, according to Wiz. The affected Jira token was rotated the following day. In a statement quoted by both Wiz and The Hacker News, Snowflake said “our investigation found no evidence of unauthorized access.” Wiz says its own audit-log analysis over the five-day exposure window matched all anomalous queries to its own testing infrastructure.
Wiz’s post also addresses the role of GitHub Copilot in the merged pull request. An update appended to the post at 1957 UTC on August 17, 2026 clarifies that “Copilot was a co-author that checked the merged PR and code change, and identified it as all-clear without noticing the critical vulnerabilities,” adding that “it’s unclear whether the code-change was AI-assisted.” Wiz notes that Copilot Autofix’s documented contribution to the same pull request was a separate fix applied to a different file, jira_close.yml, not the vulnerable jira_issue.yml.
GitHub Actions workflow injection is not a new vulnerability class: GitHub’s own security team published guidance on catching this exact pattern — untrusted input such as issue titles expanded directly into run: blocks — in July 2025, as referenced by The Hacker News and detailed in GitHub’s security blog, which recommends passing untrusted values through environment variables instead of direct template expansion.
What We Don’t Know
Neither Wiz nor Snowflake has said whether the code change that introduced the vulnerable pattern in PR #1218 was itself AI-generated; Wiz’s own post states this remains unclear. No CVE identifier or CVSS score has been assigned to the flaw in the sources reviewed.
Analysis
Wiz frames the incident as evidence of a widening gap between the speed of automated vulnerability discovery and the speed of secure code review. In its own words, “the vulnerability was live for only five days before an automated agent discovered and validated it,” and the firm argues that AI-generated or AI-reviewed pull requests “must undergo the same static analysis and security scrutiny as human code,” according to Wiz. The episode also illustrates that automated tooling on both sides of the equation — GitHub Advanced Security’s scanner and, per Wiz’s clarified account, a Copilot review pass on the same pull request — can clear a change that an autonomous offensive agent later exploits within days, underscoring why CI/CD pipelines that process untrusted, world-writable input like issue titles remain a persistent target for supply-chain-style attacks.