Wiz AI agent exposes Snowflake workflow security gap

An autonomous security agent developed by Wiz uncovered and exploited a serious vulnerability in a Snowflake GitHub Actions workflow that had passed GitHub Advanced Security checks, highlighting emerging risks as artificial intelligence becomes increasingly embedded in software development and cyber defence.

The flaw affected the public snowflakedb/snowflake-connector-net repository and allowed an unauthenticated GitHub user to execute arbitrary commands simply by opening an issue containing a specially crafted title. The vulnerable workflow automatically created Jira tickets when issues were opened and operated with credentials capable of accessing Snowflake’s internal Jira environment.

Wiz’s AI-powered Red Agent independently detected the script-injection weakness while conducting authorised security research through Snowflake’s HackerOne programme. The agent proceeded beyond identifying the vulnerable code. It constructed an exploit, encountered an initial shell syntax error, analysed the failure and modified its payload before successfully obtaining credentials from the GitHub Actions runner.

The exposed Jira token provided read access to projects covering engineering, security compliance and bug-bounty tracking. There is no evidence that customer data or a released version of Snowflake Connector for. NET was affected. Snowflake’s investigation also found no unauthorised third-party access during the five-day period in which the vulnerable workflow was active.

The vulnerability became active on June 18 after pull request number 1218 was merged into the repository. Wiz identified and reported the problem on June 23. Snowflake patched the workflow the same day and subsequently revoked and rotated the Jira credential. Audit-log analysis matched activity during the exposure period to Wiz’s authorised testing.

The weakness centred on the way the workflow handled information supplied by GitHub users. An earlier implementation stored an issue title in an environment variable and passed it safely to the jq utility when building structured data. The modified version directly inserted the issue title into a shell command before attempting to escape potentially dangerous characters.

That sequence was unsafe because GitHub substituted the attacker-controlled title before the shell’s sanitisation commands ran. A carefully placed single quotation mark could therefore escape the intended string and inject an arbitrary Bash command. Since the workflow ran automatically whenever an issue was opened, exploitation did not require repository write privileges.

Another apparent security condition in the workflow offered no effective protection. It checked a pull-request property even though the workflow was responding to an issue event. The missing property evaluated in a way that allowed ordinary users to satisfy the condition, leaving the command-injection path reachable from the public issue interface.

The episode has also drawn attention because GitHub Advanced Security scanned the final revision of the pull request, including the vulnerable workflow, without detecting the injection flaw. It demonstrates the limitations of relying on automated code-scanning systems as a definitive security barrier, particularly when vulnerabilities depend on interactions between workflow templates, user-controlled data and shell execution.

The role of GitHub Copilot Autofix requires a distinction. The merged pull request carried Copilot Autofix as a co-author, and Copilot participated in changes within the pull request. However, available repository history does not establish that Copilot authored the specific vulnerable lines in the jira_issue. yml workflow. Wiz updated its disclosure to clarify that Copilot checked the merged change without identifying the critical vulnerability and that it remained unclear whether the vulnerable code itself was AI-assisted.

That clarification makes the incident less a straightforward example of one AI system writing insecure code that another AI system discovered than a broader illustration of how human and AI contributions are increasingly intertwined in software engineering. Automated coding assistants can modify or approve code while security scanners analyse it, creating several layers at which unsafe assumptions may escape detection.

The case is particularly significant because Red Agent found the weakness only five days after it became active. Autonomous security tools are shortening the interval between the introduction of a vulnerability and its discovery, potentially benefiting defenders while giving attackers access to similar capabilities. Research published this year has found hundreds of exploitable workflow-injection weaknesses involving automated or AI-assisted GitHub workflows, underlining the expanding attack surface created by repository automation.