Cybersecurity researchers at **Wiz** have disclosed a significant **GitHub Actions** workflow injection vulnerability in **Snowflake**'s public `snowflakedb/snowflake-connector-net` repository.  The vulnerability, located in the `.github/workflows/jira_issue.yml` file, allowed for the execution of commands within a workflow containing internal **Jira** credentials. This issue arose because the workflow directly inserted attacker-controlled issue title and body values into a shell `run:` block. The weakness was specifically confined to the repository's CI/CD automation, with no identified impact on any released version of the **Snowflake Connector for .NET**. ### The Exploitation Mechanism The `jira_issue.yml` workflow was designed to run when a public issue was opened. Crucially, it exposed `JIRA_BASE_URL`, `JIRA_USER_EMAIL`, and `JIRA_API_TOKEN` to the same workflow step. An oversight in the workflow's conditional logic, specifically checking `github.event.pull_request.user.login` for an issue event (where the property doesn't exist and evaluates to an empty string), allowed ordinary issues to trigger the vulnerable job. **Wiz**'s **Red Agent** system successfully exploited this injection during authorized security testing. After an initial syntax error, the system adapted its payload, resulting in an out-of-band callback from the **GitHub Actions** runner and the exfiltration of the **Jira API token**. ### Access to Sensitive Data The compromised token, belonging to `[email protected]`, granted read access to **Jira** projects encompassing engineering, security compliance, and bug bounty tracking on `snowflakecomputing.atlassian.net`. While the underlying **Jira** permissions and audit records remain private, this level of access could have provided significant insights into **Snowflake**'s internal operations.  ### Rapid Remediation and No Evidence of External Exploitation **Wiz** reported the issue to **Snowflake** via **HackerOne** on June 23, 2026. **Snowflake** promptly merged a fix the same day in pull request #1402, which replaced direct **GitHub** expression expansion with intermediate environment variables passed to `jq` as arguments. The vulnerable workflow had been introduced just five days prior, on June 18, through pull request #1218. **Snowflake** stated that its investigation found no evidence of unauthorized access, and the **Jira** token was rotated on June 24. Their review also confirmed no unrelated external use of the token during its five-day exposure window.  ### The Role of AI in Code Generation **Wiz** initially attributed the flaw to a **GitHub Copilot Autofix** change. However, a review of the **GitHub** commit history indicates that while **Copilot** participated in pull request #1218, it was not the direct author of the specific vulnerable lines in `jira_issue.yml`. The unsafe refactor appears in a separate commit attributed to `sfc-gh-hpathak`. This incident highlights a known risk: **GitHub** itself had documented this class of workflow injection in July 2025, advising against expanding untrusted issue data directly within `run:` blocks and recommending the use of environment variables as a safer alternative. As of August 17, 2026, no **CVE**, **CVSS** score, or **CISA Known Exploited Vulnerabilities (KEV)** catalog entry has been associated with this issue, and no connector release update tied to it has been identified. The vulnerable interpolation is no longer present in the `master` branch, and there is no evidence of malicious exploitation in the wild or customer compromise.