Skip to content
NewsIncident

Wiz Red Agent found Snowflake GitHub Actions injection in five days; GitHub disputes Copilot Autofix's role in the missed flaw

· by Pondero Newsdesk

The short version

Wiz's Red Agent discovered and exploited a command injection in Snowflake's snowflake-connector-net Actions workflow just five days after it merged, exfiltrating internal Jira credentials. GitHub and Wiz now disagree on what Copilot Autofix actually reviewed and whether the flaw was within its scope.

Wiz Red Agent found Snowflake GitHub Actions injection in five days; GitHub disputes Copilot Autofix's role in the missed flaw

Wiz's autonomous Red Agent found an exploitable command injection in Snowflake's public GitHub repository exactly five days after the flaw went live, then accessed Snowflake's internal Jira environment using the exfiltrated token. Per Wiz's August 17 post-mortem, GitHub Copilot Autofix had co-authored the pull request that introduced the flaw and reviewed the final code change as all-clear. GitHub disputes that characterization.

What happened

On June 18, 2026, Snowflake's snowflake-connector-net repository merged pull request #1218, titled "SNOW-2069227: Update jira workflows." The merge introduced a script injection vulnerability into .github/workflows/jira_issue.yml. The workflow triggered on issues: opened, meaning any unauthenticated GitHub user could fire it by opening an issue. It expanded ${{ github.event.issue.title }} directly into a shell run: block using broken sed escaping: the escaping ran after GitHub's template expansion, so a single quote in the issue title broke out of the surrounding shell string and allowed arbitrary command execution inside the runner.

The workflow also carried a conditional check that appeared to restrict access to authorized users. Per The Hacker News, the condition referenced github.event.pull_request.user.login during an issues event, which always evaluates to null. The comparison reduced to null != 'whitesource-for-github-com[bot]', which is always true. Every GitHub user passed the gate.

Wiz Red Agent's CI/CD scanning capability flagged jira_issue.yml on June 23, 2026, five days after the flaw merged. The agent crafted an exploit payload, encountered a syntax error on the first attempt, autonomously analyzed the error, adjusted its payload, and then received an out-of-band callback from a GitHub Actions runner at Azure IP 20.106.182.197. The callback contained the base64-encoded Jira API token, email, and base URL used by the workflow. The token authenticated as [email protected] to snowflakecomputing.atlassian.net, giving read access across Snowflake's engineering, security compliance, and bug bounty tracking projects, per Wiz's post-mortem.

Wiz reported the vulnerability to Snowflake through HackerOne on June 23, 2026 (report #3819931). Snowflake patched the workflow the same day in pull request #1402, restoring the safe env: variable assignment approach that passes values to jq as arguments rather than interpolating them directly. The Jira token was rotated on June 24. A forensic review found no evidence of unauthorized external access during the five-day exposure window. Snowflake has not made the underlying audit records public.

The dispute over Copilot Autofix

The disagreement centers on what role GitHub Copilot Autofix played in pull request #1218 and whether it should have caught the injection.

Wiz updated its post-mortem on August 17 at 1957 UTC to state: "Copilot was a co-author that checked the merged PR and code change, and identified it as all-clear without noticing the critical vulnerabilities. It's unclear whether the code-change was AI-assisted."

GitHub's position, as reported by The Hacker News, is specific about the commit history inside PR #1218. The explicit Copilot Autofix co-authored commit (6d0e2fa) modified jira_close.yml, a separate file within the same pull request. The unsafe jira_issue.yml refactor that introduced the injection appears in a different commit (094038e), attributed by GitHub to a human engineer identified as sfc-gh-hpathak. GitHub Advanced Security scanned the final PR revision, including the vulnerable jira_issue.yml, and did not flag the injection.

Both positions can be factually compatible. A co-author on a multi-file pull request can have contributed code to only specific files. Wiz's claim is that Copilot reviewed the overall PR and cleared it; GitHub's claim is that Copilot's contribution was confined to a different file within the same PR. What neither party disputes: the merged PR removed a safe env: variable pattern and replaced it with direct expression interpolation, GitHub Advanced Security did not flag it, and an autonomous agent found and exploited it in five days without human intervention.

Wiz's original post-mortem headline described the flaw as one "missed by GitHub Copilot." After GitHub objected, Wiz updated the framing to the co-authorship and all-clear characterization. The underlying technical facts remained unchanged.

Why it matters

The practical weight of this incident falls on teams that use Copilot Autofix as part of their pull request security workflow.

Copilot Autofix is designed to identify security vulnerabilities in code and suggest fixes automatically. In this case, the tool's co-authorship relationship with PR #1218 did not result in the injection being caught, regardless of which specific file Copilot directly touched. Engineering teams that treat Copilot Autofix or GitHub Advanced Security as the primary security gate for CI/CD workflow changes should note that both cleared this PR before merge.

The vulnerability class is well-documented. GitHub's own Actions security hardening guidance lists direct expression expansion into run: blocks as a pattern to avoid, with environment variable assignment as the recommended safe alternative. The flaw survived both AI-assisted code review and GitHub's own static analysis scanner, which suggests that documented antipatterns can persist through workflow refactors that rearrange surrounding code without introducing new files.

Two operational changes apply broadly. First, CI/CD workflow files warrant a dedicated security review step separate from general PR review, particularly for files that handle untrusted inputs such as issue titles, PR body text, or comment content. Second, short-lived credentials scoped tightly to specific workflow operations reduce blast radius when these patterns reach production. The five-day exposure window here covered read access to internal Jira data because the credential was scoped to a Jira integration account, not production infrastructure or secrets management.

Context and reactions

Wiz published the post-mortem under Snowflake's HackerOne bug bounty program. Snowflake's statement, quoted in Wiz's write-up, confirmed same-day remediation and found no evidence of unauthorized external access. Snowflake thanked Wiz for responsible disclosure.

Wiz framed the discovery as evidence of how autonomous security agents compress detection windows. A five-day interval from exposure to discovery, exploitation, and remediation contrasts with historical CI/CD misconfiguration dwell times in public repositories, which security research has often measured in months.

GitHub Advanced Security's failure to flag the injectable pattern is a separate finding from the Copilot authorship dispute, but it reinforces the same conclusion: neither automated tool caught the vulnerability before it reached the default branch. No CVE had been assigned to the Snowflake Actions flaw as of Wiz's August 17 publication date.

What to watch next

Three questions are worth tracking. Whether GitHub publishes a technical post-mortem specifying which files Copilot Autofix analyzed within PR #1218, which would resolve the attribution dispute. Whether CISA or GitHub's security advisory database assigns a formal CVE, placing the flaw in standard enterprise remediation tracking. Whether enterprise security teams begin auditing CI/CD workflow files modified in pull requests where Copilot Autofix appeared as a co-author.

Sources