Copilot Autofix Introduces Vulnerability in Snowflake CI/CD,…

GitHub Copilot Autofix introduced a script injection flaw into a Snowflake GitHub Actions workflow. Five days later, Wiz's autonomous Red Agent discovered and exploited the vulnerability to exfiltrate internal Jira credentials, marking the first documented case of an AI generating a security regression and another AI discovering and exploiting it.

On June 18, 2026, a commit co-authored by "Copilot Autofix powered by AI" introduced a script injection vulnerability into the CI/CD pipeline of Snowflake's .NET connector. Five days later, Wiz Red Agent — an autonomous AI vulnerability research agent — identified the flaw, exploited it to steal internal Jira credentials, and received a callback from an Azure runner. The incident documents, for the first time in a verifiable manner, the complete cycle: AI generating a security regression, and AI discovering and exploiting it.

Key Takeaways

Copilot Autofix removed a secure pattern using environment variables and jq --arg, replacing it with direct interpolation of ${{ github.event.issue.title }} inside a shell run: block
The protective if: condition was logically bypassable: on an issues:opened event, the reference github.event.pull_request.user.login is always null, so the check always evaluates to true
Wiz Red Agent received an out-of-band callback from the Azure IP 20.106.182.197 with base64-encoded credentials authenticated as qa@snowflake.net for snowflakecomputing.atlassian.net
Snowflake patched the flaw on June 23, 2026, with commit 1dc7766, restoring the env+jq --arg pattern; the audit found no unauthorized access beyond the Wiz test

How the Secure Pattern Became Vulnerable

The snowflakedb/snowflake-connector-net repository contained a GitHub Actions workflow that processed titles of newly opened issues. The original code used two safeguards: an ISSUE_TITLE variable in env: and the JSON parser jq --arg, which treats the content as literal data rather than executable code.

In commit 4a1b8ce of PR #1218, Copilot Autofix removed both safeguards. In their place, it inserted TITLE=$(echo '${{ github.event.issue.title }}' | sed ...) followed by an echo that interpolated the variable directly in the shell. The untrusted input — the title of a GitHub issue opened by any authenticated user — thus became executable.

The co-authorship "Copilot Autofix powered by AI" is visible in the commit message. The source does not specify whether the human maintainer (sfc-gh-hpathak) manually reviewed the PR before merging, nor whether the AI acted autonomously or on an explicit fix request.

The If Condition That Protected Nothing

The workflow included an apparently protective if: condition: github.event.pull_request.user.login != 'whitesource-for-github-com[bot]'. The logical flaw is immediate: the trigger was issues:opened, not pull_request. On that event type, github.event.pull_request always exists as a null object. The comparison null != 'string' always returns true in GitHub Actions. The condition therefore filtered no input: any authenticated user could open an issue and inject commands.

This mechanism is documented in the commit diff and confirmed by GitHub Actions runtime logic. It is not a sophisticated bypass but a structural vulnerability in the workflow itself, introduced alongside the parsing regression.

The Exploit: From Syntax Error to Exfiltrated Credentials

Wiz Red Agent discovered the vulnerability on June 23, 2026. According to the Wiz report, the agent did not stop at the first failure. It autonomously analyzed the bash syntax error, adapted its payload from a # character to a ; echo ' sequence, and successfully received an out-of-band callback from the IP address 20.106.182.197 — a GitHub Actions Azure runner.

"Rather than stopping or failing, Red Agent: 1. autonomously analyzed the syntax execution error 2. adjusted its payload... 3. successfully received the out-of-band callback"
— Wiz Research

The execution log shows a curl to a Wiz-controlled listener. The payload returned base64-encoded credentials, decoded as an authenticated token for the account qa@snowflake.net on the Jira instance snowflakecomputing.atlassian.net. The token granted read access to Snowflake engineering, security compliance, and bug bounty tracking projects. The source does not specify the exact volume of data accessible during the test.

Remediation and Snowflake Statement

HackerOne report #3819931 was received by Snowflake on June 23, 2026. The same day, maintainer sfc-gh-mcepiga opened PR #1402 with commit 1dc7766, which restored the original pattern: ISSUE_TITLE variable in env:, parsing with jq --arg title "$ISSUE_TITLE" --arg body "$ISSUE_BODY". The exposure window lasted five days, from June 18 to June 23.

In a statement reported by Wiz, Snowflake confirmed: "The disclosure was received on June 23, 2026, and it was immediately investigated and remediated, and our investigation found no evidence of unauthorized access." The Jira credentials were revoked and rotated. Audit logs revealed no third-party access during the window.

What to Do Now

The operational implications emerge clearly from this case. Organizations using AI coding assistants in CI/CD must implement controls that block known regression patterns before merge, regardless of whether the author is human or AI. The specific mechanism documented here — string interpolation in shell instead of env+jq --arg — is detectable in automated review.

Audit GitHub Actions workflows for replacements of env variables with direct interpolation in shell run: blocks, particularly on events triggerable by external users (issues, issue_comment, pull_request_target)
Verify that if: conditions use references to objects that exist for the declared trigger type; a github.event.pull_request on an issues:opened workflow is always null and invalidates any check based on it
Evaluate the use of short-lived credentials for CI/CD service accounts, with scope limited to the single job and automatic revocation post-execution, to reduce the persistence of exfiltratable tokens
Implement pre-merge security gates that detect shell injection patterns in workflow YAML, treating AI-generated commits with the same rigor — not less — than human commits

It is not documented whether Snowflake implemented additional guardrails beyond the single fix. The brief does not specify structural post-incident corrective measures.

The Two Faces of AI in Security

The incident escapes the binary narrative — good AI versus bad AI. The same tool, Copilot Autofix, generated the regression. Another tool, Wiz Red Agent, discovered and exploited it. Both events are probabilistic, automated, and devoid of intent. The lesson is not to demonize AI but to recognize that the speed of automatic generation outpaces the speed of human review, and that guardrails must be equally automatic.

The source explicitly emphasizes: "how AI coding assistants can inadvertently introduce workflow injection vulnerabilities, and how automated AI agents can rapidly surface them in the wild." Speed is the new factor: five days between introduction and discovery, a cycle that traditional manual reviews would hardly cover. The implications for the governance of AI-generated code — particularly in CI/CD pipelines with access to production credentials — are immediate and concrete.

Sources

Information verified against cited sources and current as of publication.

Sources

Sources and references