A new workflow injection vulnerability has been discovered by Wiz cybersecurity researchers in a public Snowflake GitHub repository . The issue involved snowflakedb/snowflake-connector-net , specifically a GitHub Actions automation that could, under certain conditions, allow the execution of arbitrary commands and the exposure of internal credentials .
The vulnerability was not found in the Snowflake Connector for .NET itself, nor in any of its versions. Instead, it was in the repository's CI/CD, highlighting an often underestimated risk: development and automation tools can be a target for attack even when the underlying software remains secure.
How could the attack have been triggered?
The issue was found in the .github/workflows/jira_issue.yml file , which was triggered when a public GitHub issue was created . The workflow used data that an external user could control, such as the issue title and content, within shell commands.
This created the perfect environment for command injection. A malicious user could craft specially crafted contentso that part of it would be treated not as plain text but as a command to be executed by the GitHub Actions runner.
See also: GitHub Actions strengthens checkout security to block 'pwn request' attacks
At the same time, the same task had access to the variables JIRA_BASE_URL, JIRA_USER_EMAIL , and JIRA_API_TOKEN. Therefore, successful exploitation was not limited to executing a command, but could also lead to the disclosure of an internal API token.
The wrong logic in security screening
Another interesting element concerned the mechanism that was supposed to prevent unauthorized users. The code checked the github.event.pull_request.user.login, even though the workflow was triggered by an issue event, not a pull request.
Because the property was not present in the specific event, it was evaluated as an empty string. Thus, the comparison with the account whitesource-for-github-com[bot] did not act as an effective filter and a regular public issue could proceed to execute the job.
Wiz's confirmation of the exploit
Wiz said that Red Agent, the system it uses for approved security testing, was able to exploit the vulnerability. The initial attempt failed due to a shell syntax error, but the system adapted and changed its approach.
The researchers then received an out-of-band callback from the GitHub Actions runner, confirming that the command had been executed. Through the same process, they were able to obtain the Jira API token that the workflow used.
According to Wiz, the token belonged to the account qa@snowflake.net and provided read permissions to Jira projects related to engineering, security compliance issues, and bug bounty programs.
See also: Trivy Security Scanner GitHub Actions Breach
Immediate reaction and correction
Wiz notified Snowflake via HackerOne on June 23, 2026, with reference #3819931. The company issued a fix the same day via pull request #1402, replacing the direct data insertion into commands with environment variables that are passed more safely to jq.
The vulnerable implementation was pushed to the default branch on June 18th, via pull request #1218, and remained active for about five days. The Jira token was replaced on June 24th.
🔒 Protect your privacy with Proton VPN
Swiss VPN from the creators of Proton Mail — strict no-logs policy, strong encryption, and built-in NetShield that blocks ads, trackers, & malware.
- ✔ No-logs, based in Switzerland (except 14-Eyes)
- ✔ NetShield: blocks ads, trackers & malicious domains
- ✔ Covers all devices — free version available
The link is an affiliate link — SecNews may receive a commission at no additional cost to you. It does not affect the independence of our article writing.
Snowflake stated that its investigation did not identify any evidence of unauthorized access, while the audit did not indicate any external use of the specific token during the exposure period.
GitHub Copilot's role remains unclear
Of particular interest is the discussion surrounding GitHub Copilot Autofix. Wiz linked the incident to a change related to the tool, but the commit history does not prove that Copilot created the vulnerable lines.
GitHub confirms Copilot's involvement in the relevant pull request, but the unsafe reorganization of jira_issue.yml is attributed to a separate commit. Therefore, this case cannot be used as evidence that the AI tool was the creator of the vulnerability.
See also: Coinbase was the target of GitHub Actions breaches
A lesson in CI/CD pipeline security
The incident is a reminder that GitHub Actions workflows should be treated as a critical part of the attack surface. Data from issues, pull requests, and commits should not be injected directly into run: blocks without proper isolation.
GitHub itself had already warned in July 2025 about the risk of workflow injection and had recommended the use of intermediate environment variables.
As of August 17, 2026, there has been no CVE, CVSS score, or CISA KEV entry for this issue. There is also no evidence available to support actual malicious exploitation or compromise of customer systems. However, the case highlights how easily seemingly helpful automation can become an entry point when untrusted data is combined with access privileges to internal services.
