“We crafted an issue title that, after template expansion, breaks out of the echo string and exfiltrates the Jira credentials via an out-of-band callback,” Wiz’s head of threat exposure Gal Nagli wrote. That sentence describes both the discovery and the danger: an AI-assisted commit introduced a workflow injection bug, and an AI attacker autonomously found and abused it — all inside a five-day window that ended without known harm only because the activity was part of a sanctioned bug hunt.
How an AI co-author changed a workflow (June 18)
On June 18 a commit co-authored by GitHub Copilot Autofix altered a GitHub Actions workflow in the snowflakedb/snowflake-connector-net repository. According to the report, the commit removed the repository’s existing sanitized input pattern and replaced it with direct string expansion in a shell script. That change created a script-injection vulnerability inside run: blocks that could be triggered through template-expanded input.
Wiz’s red agent found and exploited the flaw (June 23)
Wiz, using its red agent — an AI-powered autonomous attacker designed for offensive security — discovered the workflow flaw on June 23 during a routine public‑repository scan. The vulnerability let an unauthenticated actor execute arbitrary commands on a GitHub Actions runner simply by opening a GitHub issue with a specially crafted title. Wiz’s team demonstrated the issue by crafting an issue title that broke out of an echo string and exfiltrated Jira credentials via an out‑of‑band callback.
The cyber insurance questionnaire just landed. Now what?
SOC 2, HIPAA, insurance renewals - someone has to own security strategy. Nubivance provides fractional CISO leadership without the full-time salary.
Get a security leadWhat was accessed, and how Snowflake responded
The exfiltrated Jira credentials gave read access to Snowflake’s engineering, security compliance, and bug bounty tracking projects. Wiz reported the workflow vulnerability to Snowflake through Snowflake’s HackerOne vulnerability disclosure program on June 23. Snowflake patched the flaw the same day, revoked and rotated the affected Jira token the following day, and — via audit logs — confirmed Wiz was the only third party to access the endpoint during the five‑day exposure window.
“The disclosure was immediately investigated and remediated, and our investigation found no evidence of unauthorized access,” a Snowflake spokesperson told The Register. “We are working together with Wiz to share these learnings with the broader industry to encourage widespread adoption of these security best practices.” Wiz says it deleted all of the data it accessed during the vulnerability research and proof‑of‑concept exploit testing.
Technical anatomy: template expansion, run: blocks, and exfiltration
The root cause was a change to how user-controlled content was handled inside a GitHub Actions run: block. Removing the sanitized input pattern and switching to direct shell string expansion allowed specially crafted issue titles to break out of echo statements after template expansion. Once the attacker-controlled input executed commands on the Actions runner, those commands could call back to an external server to deliver the Jira credentials out‑of‑band — the path Wiz used to prove the issue.
What this means for security teams, open-source maintainers, and enterprise procurement
- Security teams: Expect AI‑produced commits to introduce non-obvious workflow injection classes of risk. Wiz’s own assessment — that human code review alone may not catch such bugs quickly — underscores the need for automated scanning of CI/CD templates and activity monitoring that can detect unusual runner behavior and out‑of‑band callbacks.
- Open‑source maintainers: Review AI co‑authored changes to CI workflows closely, especially any edits that alter input sanitization or string interpolation in run: blocks. The vulnerability here arose after a standard sanitization pattern was removed and replaced by direct string expansion.
- Enterprise procurement and project owners: Ensure tokens tied to third‑party services (for example, Jira) are scoped, monitored and rotateable. Snowflake revoked and rotated the affected Jira token the day after the report and used audit logs to confirm no other third‑party access during the exposure window — concrete steps any organization should be ready to take following a workflow exposure.
This episode is notable because both ends of the chain involved AI: an AI coding assistant co‑authored the commit that introduced the flaw, and an AI attack agent autonomously located and proved the exploit. Wiz framed the event as evidence that “AI coding assistants can inadvertently introduce workflow injection vulnerabilities, and automated AI agents can rapidly surface them in the wild.” Snowflake and Wiz treated the encounter as a controlled, cooperative disclosure: the vulnerability was patched the day it was reported, credentials were rotated, and data gathered during testing was deleted.
The facts on the record end with a fixed workflow, a rotated token, and audit logs that identify only the sanctioned tester as the third‑party accessor during the exposure window. But the sequence — AI‑assisted code change, automated discovery, and instantaneous proof‑of‑concept exfiltration — leaves a clear operational question: can organizations adapt CI/CD review, token hygiene, and automated scanning fast enough to keep AI‑created mistakes from becoming AI‑amplified incidents?
