Cybersecurity researchers at Wiz have disclosed a new GitHub Actions workflow injection vulnerability in Snowflake’s public snowflakedb/snowflake-connector-net repository that it said could be exploited through a crafted GitHub issue to execute commands in a workflow containing internal Jira credentials.
The issue was present in .github/workflows/jira_issue.yml, which 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 says, “If you attempt to dereference a nonexistent property, it will evaluate to an empty string.” In this case, the comparison against whitesource-for-github-com[bot] did not stop an ordinary issue from reaching the job.
Wiz said its Red Agent system exploited the injection during authorized security testing after the first payload resulted in a shell syntax error and the system changed its approach. The researchers said they subsequently received an out-of-band callback from the GitHub Actions runner and obtained the Jira API token used by the workflow.
The token, according to Wiz, belonged to qa@snowflake.net and allowed read access to Jira projects covering engineering, security compliance, and bug bounty tracking on snowflakecomputing.atlassian.net. The underlying Jira permissions, workflow run, and audit records are not public.
Wiz said it 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 that are 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. The corrected handling remains in the repository’s master branch.
Snowflake said in a statement reproduced by Wiz that “our investigation found no evidence of unauthorized access.” Wiz said the Jira token was rotated on June 24 and that Snowflake’s review found no unrelated external use of it during the five-day exposure window. Snowflake’s underlying audit logs have not been made public.
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 therefore 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.
