The AI-wrote-it claim died in eight hours. The Actions injection pattern did not.

A security company said on Monday that an AI wrote a critical flaw into Snowflake's code and that another AI found it and broke in; the first half came apart in about eight hours ^[0]. What is left is a piece of ordinary GitHub Actions syntax, and that is the part that transfers to other people's repositories rather than to a press cycle. Wiz Research runs an autonomous scanner it calls Red Agent ^[1]. Under Snowflake's HackerOne programme it flagged a workflow file in the public repository for the company's .NET connector ^[2]. The workflow ran whenever anyone opened an issue, dropped the issue title straight into a shell script, and was reachable by any account on the internet ^[3]. The escaping existed but sat in the wrong order: GitHub's template engine substituted the title first and the sanitising commands ran afterwards, so a single quote in a title broke out of the shell string ^[4]. The second defect is the more instructive one. A guard condition compared a pull request property against a bot name; on issue events that property does not exist, GitHub evaluates a missing property as an empty string, and the comparison therefore returned true for everyone ^[5]. That line reads as a bot check and functions as an open door, and it will read the same way in any workflow that reuses a pull-request condition under an issue trigger. The exploitation is not disputed. Red Agent's first payload used a hash to comment out the rest of the line, 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 got its callback within seconds, with nobody at a keyboard ^[6]. The token it retrieved granted read access across Snowflake's engineering, security compliance and bug bounty projects ^[7]. Wiz reported on 23 June, Snowflake patched the same day, restored the safe pattern and rotated the Jira token on 24 June ^[8]. Audit logs matched every anomalous query to Wiz's own testing addresses, and Wiz says it deleted what it took ^[9]. Snowflake says the disclosure "was received on June 23, 2026, and it was immediately investigated and remediated," and that its investigation found no evidence of unauthorised access ^[10]. The headline died on provenance. The commit that carried the flaw onto main lists "Copilot Autofix powered by AI" among its co-authors, which Wiz read as an AI writing the vulnerable code ^[11]. Copilot's co-authored commit changed a different file; the unsafe refactor is a separate commit dated 25 August 2025 that GitHub attributes to a named Snowflake engineer ^[12]. Squashing folds a pull request into one commit and carries the co-author line with it, recording participation rather than authorship ^[13]. GitHub's internal review says a human wrote the contributions that led to the vulnerability and that Copilot Autofix neither reviewed nor contributed to them ^[15]. Wiz's own update, timestamped 19:57 UTC, now says "It's unclear whether the code-change was AI-assisted" ^[16]. The Register reversed its headline, appended a correction, and said it "won't be trusting Wiz for a very long time" ^[17]. Google owns Wiz; Microsoft owns GitHub, and Copilot with it ^[18]. One number does not sit right either. The account says the flaw was live for five days ^[19], while the refactor that introduced it is dated 25 August 2025 and the disclosure landed on 23 June 2026, roughly ten months apart ^[20]. Two things to watch. Neither Wiz nor GitHub, in this account, put a figure on how many other public workflows substitute untrusted issue text before sanitisation or gate an issue trigger on a pull-request property ^[21]; that count is the real scope of the finding, and it is unpublished.