GitHub Actions Flaw Let Anyone Run Commands at Snowflake

The more consequential finding for GitHub administrators is not that an AI tool “wrote a vulnerability.” It is that the vulnerable workflow passed through a pull request where GitHub Advanced Security reviewed the final code, while the reporting initially overstated GitHub Copilot Autofix’s role. Wiz later corrected its own disclosure: Copilot Autofix had contributed a separate change in the same pull request, and it remains unclear whether AI assisted the code change that actually introduced the injection.

That correction changes the story. This was a CI/CD review failure involving untrusted GitHub event data, not evidence that Copilot Autofix independently authored the vulnerable line. But it is still a warning for enterprises using Copilot, CodeQL, and GitHub Actions together: a clean automated review is not proof that a workflow handling public issues, pull requests, or comments cannot be exploited.

SC Media reported the flaw on August 18, while Forbes covered the incident a day earlier under the stronger framing that Copilot missed the vulnerability. Wiz’s updated technical account and the public GitHub pull request support the narrower conclusion: GitHub’s security tooling did not catch the final dangerous workflow behavior, and the Copilot-associated change should not be conflated with the origin of the vulnerable code.

The vulnerable workflow ran on public issue creation​

The affected file, jira_issue.yml, automatically created a Jira ticket whenever an issue was opened in the public Snowflake repository. That trigger is significant: an attacker did not need repository write access, a pull request, or a maintainer to interact with the workflow. Opening a GitHub issue was enough to start the runner.

Wiz says the workflow placed the issue title directly into a shell command after GitHub expanded the ${{ github.event.issue.title }} expression. The code then attempted to sanitize quotation marks with sed, but the sequence was backwards from a security standpoint. GitHub had already substituted attacker-controlled input into the shell before the attempted escaping ran.

A single quote in the title could terminate the intended string and append shell syntax. In practical terms, that converted an ordinary issue title field into command input. Wiz’s Red Agent validated the condition, adjusted after an initial failed attempt, and extracted a Jira API token from the runner environment.

The workflow also had an if: condition that appeared to block an automated account. According to Wiz, it referenced github.event.pull_request even though the workflow was executing for an issues event. On an issue event, the pull-request object is null; the comparison evaluated in a way that left the gate effectively open to every GitHub user.

This is a familiar GitHub Actions failure mode. Expressions are expanded before the shell sees the resulting command, so embedding data from issue titles, branch names, comments, pull-request titles, labels, or commit messages directly inside run: blocks is dangerous. Shell escaping performed after expression interpolation cannot reliably repair that design.

The safe pattern had already existed in the repository​

Wiz’s report identifies the practical regression: the merged pull request removed an earlier, safer pattern that assigned the issue title to an environment variable and passed it to jq with --arg. The replacement built a shell variable by interpolating the GitHub expression inside an echo command, then attempted to escape it.

The distinction is more than coding style. Environment variables keep GitHub expression evaluation outside the shell source itself, while jq --arg treats the title as data when constructing JSON. Direct interpolation places untrusted text into a context where shells parse quotes, substitutions, separators, and redirects before any downstream JSON processing matters.

Snowflake’s June 23 patch restored the environment-variable-and-jq approach. It also rotated the Jira token the workflow could access. Wiz says the credential authenticated to an internal Snowflake Jira instance and had read access to engineering, security-compliance, and bug-bounty-tracking projects. Neither Wiz nor Snowflake has said that customer Snowflake accounts or customer data were exposed through this incident.

The exposure lasted five days, from the June 18 merge of pull request 1218 to Wiz’s June 23 disclosure and Snowflake’s same-day patch. Snowflake told Wiz that audit logs showed no third-party access during that period, and Wiz says it deleted data accessed during its validation. Those conclusions rest on Snowflake’s log review and Wiz’s report; there is no independent public forensic record.

Copilot Autofix was present, but the attribution needs correction​

Early coverage, including SC Media’s initial wording, described the flaw as arising from a commit co-authored by Copilot Autofix. The public pull request does contain a Copilot Autofix co-author line, and GitHub Advanced Security left review activity on the pull request. But Wiz updated its disclosure on August 17 at 19:57 UTC to state that the documented Copilot Autofix contribution was a separate fix in jira_close.yml, while the unsafe change was in jira_issue.yml.

Wiz further says it is unclear whether the vulnerable code change was AI-assisted. That means the available record does not establish that Copilot wrote, suggested, or directly modified the command-injection-prone jira_issue.yml line. It does establish that the final pull request included both an AI-associated contribution and an unsafe workflow revision that GitHub Advanced Security did not flag.

That is not a semantic technicality. Treating every pull request touched by an AI assistant as entirely AI-authored blurs accountability and makes it harder to fix review processes. The relevant failure was that a merged workflow accepted public input, interpolated it into a shell command, retained access to a useful credential, and passed existing checks.

GitHub’s own documentation says Copilot Autofix generates suggested fixes for code-scanning alerts, while agentic autofix can explore a codebase, make changes, rerun CodeQL, and open a pull request. GitHub also describes those validations as best-effort. Its documentation specifically notes that validation cannot confirm all issues found by custom queries, security-extended queries, or third-party tools.

The Snowflake case exposes another limitation: static analysis can miss a dangerous composition of GitHub expression expansion, shell parsing, event triggers, and workflow permissions. Code scanning is valuable, but it cannot substitute for a review discipline that understands the execution model of GitHub Actions.

Why GitHub Actions workflows deserve separate security review​

GitHub’s Copilot cloud-agent guidance already warns that generated code can introduce vulnerabilities and says agent-created pull requests require human review before merge. It also places limits around branch writes and workflow execution. Those controls protect against some risks from an autonomous agent, but they do not automatically make a workflow safe once a human merges it.

The Snowflake workflow was not waiting for a Copilot-created branch to run. It was a production-like automation triggered by an external event in a public repository. Once merged, it could run under the repository’s configured permissions and with its configured secrets. The trust boundary was therefore not “did a developer approve this pull request?” It was “can an anonymous GitHub user control any value that reaches a shell, API request, interpreter, or privileged action?”

Administrators should review public-repository workflows with that question in mind, particularly jobs triggered by issues, issue_comment, pull_request_target, discussion, workflow_dispatch, or webhooks. The immediate audit should include:

• Search every run: block for direct GitHub expressions that consume issue titles, comments, branch names, labels, commit messages, or pull-request fields.
• Move untrusted values into environment variables and pass them through parameterized interfaces such as jq --arg, rather than constructing shell commands or JSON with string concatenation.
• Confirm that each workflow condition references fields available for its actual event type, rather than null objects that can create accidental allow rules.
• Reduce workflow permissions and scope tokens to the minimum required, then replace long-lived credentials with short-lived or federated credentials where possible.
• Require a human security review for workflow changes that alter event triggers, run: blocks, secrets access, permission declarations, or external-ticket integrations.

These checks should apply equally to human-authored, Copilot-suggested, and agent-generated changes. The most dangerous workflow change is often a tiny convenience edit that changes data handling, not a large code generation event that visibly invites scrutiny.

The five-day discovery window is the real operational warning​

Wiz’s Red Agent found and exploited the flaw five days after it became live. Its ability to diagnose a failed payload, alter the test, validate access, and assess the credential’s reach is notable, but the operational lesson is straightforward: defenders should assume externally reachable CI/CD mistakes can be discovered in days or hours.

Snowflake’s response was appropriately rapid once notified. The company patched the workflow the same day, rotated the credential the following day, and says no unauthorized access occurred. That prevented a public-repository flaw from becoming a longer-lived exposure.

For Windows-focused development teams running GitHub Actions alongside Azure services, Microsoft Entra identities, Azure Key Vault, Jira, or internal APIs, the remediation priority is clear. Audit public-event workflows before the next AI agent—defensive or malicious—does it for you.