This one broke on August 17 and it's still generating heat.
Forbes, SC Media, The Hacker News, and a handful of other outlets all covered the same story at once: Wiz ran their autonomous AI red agent against Snowflake's public GitHub repos, found a live command injection in a CI/CD workflow, and the commit that introduced the vulnerability listed "Copilot Autofix powered by AI" as a co-author.
Wiz's initial read: Copilot helped write the vulnerable code and didn't catch it.
GitHub's response: actually, Copilot touched a different file in that PR. The unsafe code came from a human commit 11 months earlier. Copilot co-authored the PR but didn't write the vulnerability.
Wiz updated their post to clarify. GitHub went on record with IT Pro about it. Two major cloud companies are still publicly untangling the specifics.
Here's what actually matters for your team.
The Vulnerability Was Classic and Simple
The command injection in Snowflake's connector repo worked like this: a GitHub Actions workflow built shell commands using ${{ github.event.issue.title }} — the title of a GitHub issue — without sanitizing it first.
Open an issue with a crafted title containing shell metacharacters and the Actions runner executes it. Your build pipeline leaks its secrets to whoever opened the issue. No authentication required, because GitHub issues are public by default.
Wiz found it June 23, Snowflake patched it the same day. Nobody outside Wiz accessed the exposed Jira token. Good outcome, but the important part is that it sat there for five days and nobody noticed until an AI agent went looking.
This pattern is not exotic. Security teams have been warning about it for years. It keeps showing up because it's easy to introduce and doesn't look wrong until you ask the right question.
The Copilot Question
Whether Copilot wrote the vulnerable line or reviewed the PR and didn't flag it, the result is the same: an AI coding tool was in the loop during the commit that made this code live, and the vulnerability survived.
That's worth sitting with.
Copilot Autofix is marketed specifically as a security layer — it's supposed to find and fix problems automatically. And here we have a case, publicly documented and confirmed by both parties, where a classic injection pattern made it to production without being caught.
This isn't a gotcha against Copilot specifically. It's a data point about what AI code review tools do and don't do. They are good at completing code, suggesting fixes for patterns they've been trained on, and speeding up routine work. They are not doing adversarial analysis — they're not asking "how would an attacker abuse this input?" with the same focus that a security researcher would.
The training objective is different. Helpful is not the same as adversarially safe.
What Wiz's Red Agent Actually Did
The other half of this story is useful to understand.
Wiz's autonomous agent is built specifically to be adversarial. It scans repos, maps attack surface, attempts exploitation, and reports findings. It found a live command injection in five days, autonomously, without a human directing each step. The write-up on their blog is worth reading if you want to understand the methodology.
This is the difference between a code assistant and a security-specialized AI. One is tuned to help you ship. The other is tuned to break things. They're doing fundamentally different work and you cannot substitute one for the other.
If your team is relying on a code assistant to catch security vulnerabilities in your CI/CD automation, that reliance is misplaced.
Why This Pattern Is All Over Your Pipelines
GitHub Actions workflows that process user-controlled input are extremely common. Any workflow that triggers on issues, issue_comment, or pull_request events and uses payload data — issue titles, comment bodies, PR descriptions — in shell commands has exposure to this class of vulnerability.
A lot of teams built these workflows gradually, with AI assistance, and nobody ever did a targeted security review on the automation layer. The workflows run fine, no errors, so the assumption is they're fine. That assumption is not safe.
The safe pattern: assign the payload to an environment variable first:
- name: Do something
env:
ISSUE_TITLE: ${{ github.event.issue.title }}
run: echo "$ISSUE_TITLE"
The raw ${{ github.event.issue.title }} expression interpolated directly into a run: block does not sanitize anything. It just drops the string into the shell.
Quick audit: search your .github/workflows/ directory for github.event.issue or github.event.pull_request. Anywhere that data appears directly in a run: step is worth reviewing.
Also check: who can trigger the workflow. Anything that fires on issues.opened in a public repo can be triggered by anyone with a GitHub account. Combined with injection, that's open to everyone on the internet.
The Part Both Companies Are Missing
GitHub and Wiz are both focused on who co-authored which commit. The more important question: how many CI/CD workflows across how many repos have this exact pattern right now, and nobody's running an adversarial agent against them?
The answer is a lot. Probably including some of yours.
This is not about blaming AI tools. It's about being realistic about what they do. Use Copilot Autofix to generate fixes after you've identified a problem. Don't use it as the thing that identifies the problem. That's a different job.
A focused review of your GitHub Actions workflows — looking specifically for injection patterns, over-permissioned runners, and secrets exposure — is one of the higher-value security tasks a small team can run right now. It doesn't take months. It takes someone who knows what to look for running a targeted pass.
Most teams haven't done it. Most teams have more exposure than they realize. That's true whether or not you're using AI coding tools.
This is exactly the kind of sprint work we do. If you want to know where you actually stand, it's a good time to look.