Snowflake GitHub Actions Flaw Allows Command Injection via Crafted Issues

Cybersecurity researchers at Wiz have disclosed a GitHub Actions workflow injection vulnerability in Snowflake’s public snowflakedb/snowflake-connector-net repository. The flaw, present in the .github/workflows/jira_issue.yml file, could be exploited through a crafted GitHub issue to execute arbitrary commands in a workflow that contained internal Jira credentials.

The vulnerable workflow ran when a public issue was opened and exposed JIRA_BASE_URL, JIRA_USER_EMAIL, and JIRA_API_TOKEN to the same workflow step. The weakness was confined to the repository’s CI/CD automation, with no affected Snowflake Connector for .NET release identified. The workflow inserted attacker-controlled issue title and body values directly into a shell run: block. It also checked github.event.pull_request.user.login even though the event was an issue, meaning the referenced pull request property did not exist. GitHub states that dereferencing a nonexistent property evaluates to an empty string, so the comparison against whitesource-for-github-com[bot] did not stop an ordinary issue from reaching the job.

Wiz’s Red Agent system exploited the injection during authorized security testing. After an initial payload caused a shell syntax error, the system adjusted its approach and subsequently received an out-of-band callback from the GitHub Actions runner, obtaining the Jira API token used by the workflow. The token belonged to qa@snowflake.net and allowed read access to Jira projects covering engineering, security compliance, and bug bounty tracking on snowflakecomputing.atlassian.net.

Wiz reported the issue to Snowflake through HackerOne on June 23, 2026, under report #3819931. Snowflake merged a fix that day in pull request #1402, replacing the direct GitHub expression expansion with environment variables passed to jq as arguments. The vulnerable workflow had reached the default branch five days earlier, on June 18, when pull request #1218 was merged. Snowflake stated that its investigation found no evidence of unauthorized access. The Jira token was rotated on June 24, and Snowflake’s review found no unrelated external use during the five-day exposure window.

Wiz described the flaw as resulting from a GitHub Copilot Autofix change, although the underlying GitHub history does not establish Copilot as the author of the vulnerable jira_issue.yml code. The explicit Copilot co-authored commit, 6d0e2fa, changed jira_close.yml, while the unsafe jira_issue.yml refactor appears in a separate August 25, 2025, commit, 094038e, attributed by GitHub to sfc-gh-hpathak. Both changes were later folded into the June 18 squash merge commit 4a1b8ce, which lists Copilot Autofix among its co-authors. The commit history confirms Copilot participation in pull request #1218, but not authorship of the vulnerable lines.

GitHub had documented this class of workflow injection in July 2025, warning against expanding untrusted issue data directly inside run: blocks and recommending the use of intermediate environment variables. As of August 17, 2026, no CVE, CVSS score, or CISA Known Exploited Vulnerabilities (KEV) catalog entry had been located for the issue, and no connector release update tied to it had been identified. The vulnerable interpolation is no longer present on master, and the available primary material does not establish malicious exploitation in the wild or customer compromise.