BIP Austin digital publishing platform

collapse
Home / Daily News Analysis / Copilot Autofix did not write the Snowflake flaw, GitHub say

Copilot Autofix did not write the Snowflake flaw, GitHub say

Aug 18, 2026  Twila Rosenbaum 42 views
Copilot Autofix did not write the Snowflake flaw, GitHub say

On Monday, a security firm released research claiming that an artificial intelligence system had written a critical vulnerability into Snowflake's code, and that another AI agent discovered the flaw, exploited it, and retrieved valid credentials. Within eight hours, the first half of that claim collapsed. The second half, however, remains intact and is a significant milestone in the evolution of autonomous AI security tools.

What follows is a look at what the agent actually did, why the AI authorship claim fell apart, and what is still worth paying attention to.

Key facts at a glance

  • Wiz Research's autonomous tool, Red Agent, found a command injection flaw in a GitHub Actions workflow in Snowflake's public .NET connector repository.
  • The workflow was triggered by opening an issue, and the issue title was inserted into a shell script with dangerous escaping.
  • Red Agent exploited the flaw on its own, hit an error, corrected its payload, and retrieved a Jira token with read access across Snowflake's engineering, security, and bug bounty projects.
  • Snowflake patched the flaw on the same day it was reported and rotated the token the next day.
  • A commit listing "Copilot Autofix powered by AI" as a co-author initially suggested AI wrote the vulnerable code, but the co-author line was a squash artifact.
  • GitHub's internal review concluded that a human wrote the contributions that led to the vulnerability and that Copilot Autofix did not review or contribute to them.
  • Wiz later softened its post, saying it was unclear whether the code change was AI-assisted.

What Red Agent actually did

Wiz Research operates an autonomous tool called Red Agent. Under Snowflake's HackerOne disclosure program, the agent scanned Snowflake's GitHub organization and flagged a workflow file in the public repository for Snowflake's .NET connector. The workflow was configured to run whenever anyone opened an issue. It took the issue title and placed it directly into a shell script. Because the repository was public, any account on the internet could reach the workflow and trigger it.

The vulnerability was a command injection flaw caused by improper escaping order. GitHub's template engine substituted the issue title first, and the sanitization commands ran afterward. A single quote in the title could therefore break out of the shell string and execute arbitrary commands. A guard condition designed to check whether a pull request property matched a bot name was ineffective on issue events, because GitHub evaluates missing properties as empty strings. That made the comparison always return true, allowing every user through.

Then came the part that matters. Red Agent's first payload used a hash character to comment out the rest of the line, and the runner threw a syntax error. The agent read the error, worked out that the comment had swallowed a closing bracket, rewrote the payload, and tried again. The callback arrived within seconds. Nobody touched a keyboard.

The token it pulled out granted read access across Snowflake's engineering, security compliance, and bug bounty projects. This was not a simulated exercise. The agent operated against a live production environment under a legitimate bug bounty program.

Snowflake patched the same day

Wiz reported the flaw on 23 June. Snowflake patched it that day, restored the safe pattern, and rotated the Jira token on 24 June. Audit logs matched every anomalous query to Wiz's own testing addresses. Wiz says it deleted what it took.

Crucially, the vulnerability was live for only five days. That was the entire window between the introduction of the vulnerable code and the patch. No evidence has surfaced that anyone other than Wiz exploited the flaw, and Snowflake said its investigation found no evidence of unauthorized access.

The co-author line was a squash artifact

Here is where the story went wrong. The commit that carried the flaw onto the main branch listed "Copilot Autofix powered by AI" among its co-authors. Wiz read that as an AI writing the vulnerable code. Its own post said an AI autofix commit created the injection vector. Most coverage followed that framing.

Then journalists and security researchers went and read the commits underneath. Copilot's co-authored commit changed a different file. The unsafe refactor sat in a separate commit dated 25 August 2025, which GitHub attributed to a named Snowflake engineer.

Squashing folds every commit in a pull request into one. The co-author line came along for the ride. It records participation in the pull request, not authorship of the lines that broke. In other words, the history confirmed that Copilot took part in the pull request, but it did not establish that Copilot wrote the flawed code.

GitHub's answer

GitHub ran an internal review and rejected the framing. The company said a human wrote the contributions that led to the vulnerability, and that Copilot Autofix neither reviewed nor contributed to them.

Wiz softened its own post the same evening. An update timestamped 19:57 UTC added a sentence that undid the headline: "It's unclear whether the code-change was AI-assisted." The update also described Copilot as a co-author that checked the merged pull request and called it clear without noticing the vulnerability.

One technology publication had already published its story. By midnight it had changed its headline from an AI breaking the code to an AI failing to detect it, and appended a correction. The publication's cybersecurity editor ended the correction with a blunt line about not trusting the security firm for a very long time.

Two owners worth naming

There is a corporate layer that probably should have been flagged earlier. Google owns Wiz. Microsoft owns GitHub, and Copilot with it. That does not necessarily make the research wrong, but it means a Google-owned firm published a claim that a Microsoft product wrote a critical flaw, then withdrew the load-bearing part of the claim once people checked. The commercial rivalry between the two cloud giants is well known, and that context matters when evaluating how such a story travels.

What survives is not small

Strip out the disputed half, and a real finding remains. An autonomous agent scanned a public repository, spotted a live injection vulnerability, wrote an exploit, hit an error, diagnosed the error, corrected itself, and took working credentials. That happened without human intervention at any step of the attack chain.

This is part of a broader trend. Researchers jailbroke Copilot workflows in July, and a separate GitHub agent leaked private repositories a day earlier. Since then, AI-discovered flaws have moved into real exploitation. Another report showed an agent building a working exploit for a macOS flaw in four hours. Greg Brockman conceded on Sunday that OpenAI had underestimated its own models in exactly this regard. The direction of travel is not in question.

What the record does not show

Several things remain unestablished, and the gap matters given how the claim spread. No CVE exists. No CVSS score, and no entry in the US catalogue of exploited vulnerabilities. The weakness sat in repository automation, so no connector release carried it, and no evidence points to anyone else exploiting it.

Snowflake's audit logs are not public. Neither are the Jira permissions or the workflow run. Everything about the blast radius rests on what Snowflake and Wiz say they saw. That is not the same as verified public evidence.

One more detail deserves mention. GitHub published guidance in July 2025 warning against exactly this pattern of unsafe shell interpolation in workflows. The vulnerable commit was introduced a month later. Whether the developer saw that guidance is unknown, but the warning existed.

What would settle the AI question

The useful question is not which AI should be blamed. It is whether GitHub's AI review looked at this change and passed it. Wiz says it did. GitHub says Copilot Autofix never reviewed the code at all. Those two statements cannot both be true, and only one company holds the logs that would show which one is correct.

Until those logs are made available, the responsible takeaway is this: an AI agent found and exploited a real vulnerability in a major company's public infrastructure, but the claim that another AI wrote that vulnerability remains unproven and is contradicted by the commit history. The incident demonstrates both the power of autonomous security agents and the ease with which a plausible but misleading attribution can spread before anyone checks the underlying commits.


Source:TNW | Data-security News


Share:

Your experience on this site will be improved by allowing cookies Cookie Policy