The AI Review Missed the Bug. Five Days Later, Another Agent Exploited It.

The code passed

On 18 June 2026 at 10:18 UTC, pull request 1218 was merged into snowflakedb/snowflake-connector-net, titled "SNOW-2069227 : Update jira workflows". The repository is public, so the record is public with it. The squash commit, 4a1b8ce, lists three co authors: two Snowflake engineers and "Copilot Autofix powered by AI", attributed to the GitHub Advanced Security bot account.

The change touched a workflow that opens Jira issues from GitHub issues. It removed a pattern that existed for a reason. The old version passed the issue title into an environment variable and built the Jira payload with jq using an argument, which keeps attacker text as data. The new version interpolated the issue title straight into a shell command and tried to make it safe afterwards with sed. That ordering is the whole problem. GitHub expands the template first, so the shell sees the attacker's characters before any escaping runs. A single quote in an issue title escapes the string and the rest becomes commands.

The workflow triggered on issues being opened, which means any GitHub user could fire it. Wiz also documented a condition on the job that looked protective and was not, because it tested a pull request field that is always null on an issues event, so the check passed for everyone.

Two review layers looked at this. Human reviewers approved the pull request. GitHub's AI assisted security review checked the merged pull request and the code change and, in Wiz's words, identified it as all clear without noticing the critical vulnerabilities.

Be precise about what Copilot did

This is the part where most of the coverage moved faster than the evidence.

Wiz's original post said, in the body, that an AI autofix commit created the injection vector. The Register ran with that framing on 17 August. Then Wiz added a dated update at 1957 UTC on 17 August clarifying that Copilot was a co author which checked the merged pull request and code change and identified it as all clear without noticing the critical vulnerabilities, and that it is unclear whether the code change itself was AI assisted. The Register published a correction dated 00:00 GMT on 18 August saying Wiz is not sure Autofix introduced the error, that a human may have introduced it, and that Autofix simply failed to correct it.

So here is the formulation the public record actually supports. The vulnerable change was merged in a pull request whose final commit credits Copilot Autofix as a co author, and GitHub's AI assisted security review did not detect the critical vulnerability. Co authorship metadata on a squash commit does not establish which lines any contributor wrote.

What remains unknown: whether Copilot authored the vulnerable lines, how much of the pull request was AI generated, and what Snowflake's internal review involved beyond what the public GitHub record shows. I am not going to fill those gaps, and I would treat anyone who does with suspicion.

Five days later, the attacker was software too

On 23 June 2026, Wiz Red Agent, which Wiz describes as an autonomous AI powered security research tool, scanned Snowflake's public GitHub organisation and flagged the workflow as vulnerable to script injection through untrusted input in a run block.

Then it did the thing that makes this incident worth writing about. Its first exploitation attempt failed. Wiz reports that the agent used a comment character which swallowed a closing parenthesis, and the runner returned a bash syntax error. The agent did not stop and did not escalate to a person. It analysed the error, changed the structure of its payload to close the shell block correctly, retried, and received an out of band callback within seconds from a GitHub Actions runner carrying base64 encoded credentials.

From there it authenticated to Snowflake's Jira instance with the exfiltrated token, confirmed the access was live, and assessed the blast radius. Wiz states this sequence ran without human intervention.

I am deliberately not reproducing the payload. The mechanism matters here, the recipe does not.

The consequence was a credential

The exfiltrated token authenticated as a qa account to Snowflake's Atlassian tenant and granted read access across Snowflake's engineering, security compliance and bug bounty tracking projects. That is the documented scope. It was not database access. It was not customer data. Read access to a security compliance and bug bounty project is still an unpleasant place for an outsider to stand, because it is where an organisation writes down what it already knows is wrong with itself.

Snowflake's response, as published by Wiz and given to The Register: the disclosure was received on 23 June, immediately investigated and remediated, and the investigation found no evidence of unauthorized access. Wiz reports the workflow was patched the same day in commit 1dc7766 through pull request 1402, restoring the safe env plus jq argument pattern, with the Jira token rotated on 24 June. Wiz says audit log analysis confirmed no external third party reached the endpoint during the five day exposure window and that all anomalous queries matched its own testing addresses.

Review is evidence. It is not an authority boundary.

Everything above is what other people reported. This section is Moona Intelligence interpretation, and it should not be attributed to Wiz, GitHub or Snowflake.

Code review, human or model assisted, produces an estimate. A reviewer reads a diff and forms a judgement about whether the change is acceptable. That judgement is probabilistic even when the reviewer is excellent, and this diff was a small workflow edit of the kind that reviewers approve all day. The AI reviewer's failure mode here was not exotic either. It saw a change that looked like escaping and did not model the ordering that made the escaping useless.

An authority boundary is a different object. It sits at the moment a consequential action is about to execute and decides whether that action is permitted, given what it targets and who authorized it. It does not depend on anyone having correctly predicted the consequence in advance.

The distinction matters because review is the control most organisations are implicitly relying on, and review can be wrong. This is not an argument against code review, and it is certainly not an argument that source code security can be solved at execution time. It is narrower than that. If the decision to allow a change can be mistaken, then whatever the mistaken change reaches later still needs boundaries of its own. In this case the mistaken change reached a runner holding a long lived credential for a system full of internal engineering and security records, and nothing between the injected shell command and that credential asked a further question.

AI compresses both sides of the chain

The chain here had a lot of decision points: write the change, review it with a model, review it with humans, merge it, discover the flaw, exploit it, use the credential. Probabilistic systems now sit on both ends of that chain, and their effect is asymmetric in an unhelpful way.

On the defensive side, model assisted review makes approval cheaper and faster, which increases throughput and, occasionally, confidently misses something. On the offensive side, autonomous agents make discovery continuous rather than episodic. Wiz's agent was not tipped off. It was scanning, and it recovered from its own failure without asking anyone.

The recovery window is what shrinks. Historically, an organisation could rely on a wrong approval sitting undiscovered for a while, and on the discovery arriving as an alert, a report, or a researcher's email. That slack is what "we will catch it in the next review cycle" was quietly built on. Five days of exposure, ended by a machine that scans public repositories as a matter of routine, is a different operating assumption.

End with the clock

Five days used to sound fast for finding and exploiting a newly introduced workflow flaw. With autonomous offensive agents scanning continuously, it may soon sound slow.

So the question I would put to anyone shipping with AI in the review path: if the review decision can be wrong, and it can, what still protects the consequential action once the mistake reaches execution?

Related reading: what happens when the actor giving an approval is an agent, why model cyber capability is not the same question as execution authority, the difference between planning a change and executing it, and why authority has to be answered at the moment of execution.