← Back to feed

An AI coding assistant introduced a script injection vulnerability into a Snowflake GitHub Actions workflow on June 18, 2026. An AI security agent found it, exploited it, and exfiltrated credentials five days later.

The Wiz research team published the full incident on August 17. The timeline is specific: a single Copilot Autofix commit removed an existing safe pattern and created the opening; Wiz’s autonomous Red Agent closed the loop.

The Commit That Created the Hole

The vulnerable repository is snowflakedb/snowflake-connector-net. On June 18, commit 4a1b8ce landed via PR #1218 — “SNOW-2069227: Update jira workflows” — co-authored by GitHub Copilot Autofix.

The workflow in question (jira_issue.yml) triggers on issues: opened, meaning any GitHub user can fire it by opening an issue. Before the Autofix commit, the workflow passed the issue title through an env: variable and used jq to build the JSON payload safely. Autofix removed both of those. In their place it interpolated ${{ github.event.issue.title }} directly into a shell sed command.

That is the injection vector. The sed escaping runs after GitHub’s template expansion. A single quote in an issue title breaks out of echo '...' and allows arbitrary command execution in the GitHub Actions runner.

The pre-Autofix pattern is a textbook safe approach to handling untrusted shell input in CI. The post-Autofix pattern is a textbook script injection. The AI assistant replaced the former with the latter.

How Wiz Red Agent Reached Snowflake’s Jira

Wiz Red Agent is an autonomous, AI-powered security research tool. As part of ongoing research conducted through Snowflake’s HackerOne program, Red Agent scanned Snowflake’s GitHub organization and flagged jira_issue.yml as vulnerable to script injection via untrusted input in run: blocks.

Red Agent then:

1. Opened a GitHub issue in snowflakedb/snowflake-connector-net with a specially crafted title containing a shell escape sequence
2. Triggered the vulnerable jira_issue.yml workflow
3. Executed arbitrary commands inside the GitHub Actions runner
4. Exfiltrated a credential from the runner environment
5. Used that credential to access Snowflake’s internal Jira portal

Wiz reported the vulnerability to Snowflake on June 23 — the same day Red Agent completed the proof-of-concept. Snowflake patched the workflow and rotated the affected credential on the same day. Audit logs confirmed Wiz was the sole actor during the exposure window.

The Incident Structure Matters

This is not the first time AI-generated code introduced a security flaw. What is new is the complete loop: an AI assistant created the vulnerability, and an AI agent found and exploited it — without a human in either role.

The gap between creation and discovery was five days. The vulnerability would not have survived a manual code review from anyone familiar with GitHub Actions injection patterns. The safe pattern was already in the repository; Autofix replaced it.

The specific failure mode is well-documented in GitHub’s own Actions security hardening guidance: never interpolate ${{ github.event.issue.title }} or similar untrusted context values directly into run: shell commands. The guidance existed. The AI assistant did not apply it.

What This Points To

AI coding assistants are now committing to shared repositories at scale. Security tooling designed for human-written code is not sufficient to catch all of the categories of error these tools introduce — partly because the errors look syntactically correct, and partly because the unsafe pattern may be more common in training data than the safe one.

Wiz’s Red Agent being able to discover and exploit this without human direction within five days suggests that the detection-to-exploitation gap for AI-introduced CI/CD vulnerabilities may be shorter than the detection-to-patch gap at many organisations.

Snowflake’s response was fast and correct. The broader question is how many similar Autofix-introduced regressions exist in repositories where automated security scanning is not running.