GitHub Actions Injection Found in Snowflake .NET Repo

Snowflake’s public .NET connector repository had a GitHub Actions workflow injection vulnerability. A crafted GitHub issue could trigger arbitrary command execution in a workflow that held internal Jira credentials. Wiz disclosed it; Snowflake has fixed it.

The affected workflow was .github/workflows/jira_issue.yml, which fired automatically when a GitHub issue was opened. According to The Hacker News coverage of Wiz’s research, the workflow incorporated unsanitized data from the triggering event — creating the injection point. The runner had access to Jira credentials, which would have been exposed to a successful exploit.

Why this keeps happening

GitHub Actions workflows triggered by issues or pull_request_target events run in the context of the base repository, not the submitter’s fork. That means they have access to repository secrets — and if they naively interpolate issue or PR metadata into shell commands, whoever can open an issue or PR can potentially inject commands that the CI runner executes with those credentials.

This is a well-understood class of vulnerability. GitHub’s own security hardening guide has covered script injection for years. It keeps appearing in production because the GitHub Actions YAML format makes the dangerous pattern look identical to the safe one, and there’s no inline warning when you author it.

Snowflake’s .NET connector is an open-source client library — any GitHub user could open an issue against it. That makes the attack surface wide.

What to audit in your own repos

Check any workflow that triggers on issues, pull_request_target, or workflow_dispatch with external inputs. The question to answer: does this workflow pass event metadata — issue title, issue body, PR title, PR branch name — into a run: shell step?

Safe pattern: set the untrusted value as an environment variable first, then reference the env var in the shell. The substitution happens at the environment layer rather than at YAML parse time, so the value is treated as data, not as part of the command.

Risky pattern: directly embedding ${{ github.event.issue.title }} or similar expressions inside a run: block’s shell command string. If an attacker controls that value, they control what the shell runs.

Also check which secrets each workflow job can access. If a Jira-sync or issue-labeling job runs on public issue open events, it should not hold credentials that cover more than that narrow task.

Priority call

If your organization maintains public GitHub repositories with any CI automation that reacts to issues or PRs: audit those workflows now, before this disclosure circulates further. Prioritize workflows that hold secrets (API keys, deploy credentials, cloud access tokens) and trigger on publicly submittable events.

This is not a Snowflake-specific problem. It’s a pattern that Wiz found in one well-known repo — and the same pattern exists in countless others. The fix for the Snowflake repository is done; the broader audit work is yours to do.

Related: the supply-chain security topic hub has prior coverage on DPRK npm package supply-chain attacks and GitHub’s signed-commit trust assumptions — both relevant context for teams thinking through their CI/CD risk surface.