Security researchers at Wiz have uncovered a GitHub Actions workflow injection vulnerability in Snowflake's public snowflakedb/snowflake-connector-net repository. The flaw could be triggered through a specially crafted GitHub issue, allowing commands to execute in a workflow that contained internal Jira credentials. The issue was found in the .github/workflows/jira_issue.yml file, which ran whenever a public issue was opened, exposing JIRA_BASE_URL, JIRA_USER_EMAIL, and JIRA_API_TOKEN to the same workflow step. The weakness was limited to the repository's CI/CD automation, and no affected Snowflake Connector for .NET release was identified.
The workflow directly inserted attacker-controlled issue title and body values 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 notes that dereferencing a nonexistent property evaluates to an empty string, so the comparison against whitesource-for-github-com[bot] did not block an ordinary issue from reaching the job.
Wiz said its Red Agent system exploited the injection during authorized security testing. After an initial payload caused a shell syntax error, the system adjusted its approach, later receiving an out-of-band callback from the GitHub Actions runner and 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. The underlying Jira permissions, workflow run, and audit records are not public.
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. The corrected handling remains in the repository's master branch.
Snowflake stated that its 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, but the 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 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 available primary material does not establish malicious exploitation in the wild or customer compromise.
Source: The Hackers News
