AI Exploits GitHub Actions: Autonomous Agent Finds a Command Injection Path and Steals an API Token
AI Exploits GitHub Actions: Autonomous Agent Finds a Command Injection Path and Steals an API Token
Artificial intelligence is moving beyond its traditional role as a coding assistant. Security researchers are now demonstrating a more concerning capability: an autonomous AI agent can analyze a target, attempt an exploit, learn from failure, modify its approach, and ultimately achieve its objective.
A recent security research demonstration involving GitHub Actions showed exactly how dangerous this evolution could become. The AI agent identified a path to command injection through a vulnerable automation workflow and eventually obtained access to a sensitive API token.
The significance of the experiment is not simply that a vulnerability existed. The more important question is what happened when the first attack attempt failed: the AI agent was able to adapt its strategy and continue working toward exploitation instead of stopping at the first unsuccessful result.
How the GitHub Actions Vulnerability Worked
The vulnerability was discovered in the public snowflakedb/snowflake-connector-net repository. A GitHub Actions workflow processed the title of newly created GitHub issues and inserted that attacker-controlled data directly into a shell command.
This is where the problem began.
GitHub Actions expressions were expanded before the shell processed the command. As a result, a specially crafted issue title could break out of the intended shell syntax and inject additional commands into the GitHub Actions runner. The workflow could be triggered simply by opening an issue, making the attack surface particularly dangerous.
The workflow also contained a security condition that appeared to restrict execution. However, according to Wiz, the condition referenced pull-request data during an issue event. Because that property did not exist in that context, the intended restriction did not effectively block ordinary users from reaching the vulnerable workflow.
The Most Important Part: The First Exploit Failed
What makes this case particularly interesting is what happened next.
The autonomous Red Agent attempted to exploit the vulnerability, but its initial payload resulted in a shell syntax error. A conventional automated scanner might simply report the potential vulnerability or mark the exploitation attempt as unsuccessful.
The AI agent did something different.
According to Wiz, it analyzed the execution failure, modified its approach, retried the attack, and successfully triggered command execution. The agent then validated the impact by obtaining a Jira API token available to the vulnerable workflow and using it to confirm access to Snowflake’s internal Jira environment.
This is the part that should concern security teams the most.
The AI was not merely matching a known vulnerability pattern. It followed a process closer to that of a human penetration tester:
- Identify a potentially exploitable weakness.
- Build an exploit attempt.
- Observe the result.
- Analyze the failure.
- Modify the technique.
- Try again.
- Validate the impact.
That feedback loop is a major step beyond traditional vulnerability scanning.
From a GitHub Issue to an Internal API Token
The vulnerable GitHub Actions workflow had access to credentials used for Jira integration. Once command execution was achieved within the runner, the agent was able to access the exposed credential and verify that it provided access to internal Jira resources.
Wiz reported the vulnerability to Snowflake through its authorized HackerOne security research process on June 23, 2026. Snowflake remediated the issue, rotated the affected credential, and audit logs indicated that Wiz was the only actor that accessed the vulnerable path during the exposure period. There is no indication that unrelated attackers exploited the flaw.
Was GitHub Copilot Responsible for the Vulnerability?
This part of the story requires an important clarification.
Wiz’s original write-up described the vulnerable pull request as being co-authored by Copilot Autofix. However, subsequent reporting and GitHub’s response disputed the interpretation that Copilot itself had written the vulnerable lines.
According to GitHub’s position, the problematic code was written and merged by a human developer, although AI tooling was involved elsewhere in the pull request and security scanning process. Wiz subsequently clarified aspects of its original description.
So the bigger lesson should not be reduced to:
„AI created a vulnerability.”
The more accurate and arguably more important story is this:
An AI-powered security agent discovered and exploited a vulnerability that had made it through a modern software development and security pipeline.
That pipeline included automation, AI-assisted development, code review processes, and security tooling.
AI vs. AI Is Becoming a Real Security Scenario
This incident demonstrates a future that cybersecurity professionals have been discussing for years.
AI is increasingly being deployed on both sides of the security battlefield.
On the defensive side, AI can:
- analyze source code,
- identify suspicious behavior,
- prioritize vulnerabilities,
- investigate alerts,
- detect anomalies,
- generate patches.
On the offensive side, autonomous systems can potentially:
- scan large attack surfaces,
- identify vulnerable applications,
- test exploitation paths,
- adapt failed payloads,
- chain vulnerabilities,
- validate stolen credentials,
- assess the impact of a compromise.
The difference is scale.
A human security researcher has limited time and can investigate only a certain number of targets simultaneously. An autonomous AI agent can potentially analyze thousands of repositories, workflows, cloud environments, and applications continuously.
The technology does not need to become a fully autonomous „hacker” overnight to create a major security problem.
Even partial autonomy can dramatically increase the speed of vulnerability discovery and exploitation.
Why GitHub Actions Workflows Are an Attractive Target
CI/CD environments are particularly valuable targets because they often sit at the center of the software supply chain.
A compromised GitHub Actions workflow may have access to:
- API tokens,
- cloud credentials,
- deployment secrets,
- package repository credentials,
- signing keys,
- internal services,
- source code,
- production infrastructure.
This means that a seemingly small scripting mistake can potentially become the starting point for a much larger compromise.
The Snowflake case is also a reminder that data originating from GitHub events should be treated as untrusted input.
Issue titles, issue bodies, pull request titles, branch names, commit messages, comments, and usernames can all potentially contain attacker-controlled content.
Directly inserting such values into shell commands is dangerous.
How Developers Can Reduce the Risk
Organizations using GitHub Actions should review workflows for patterns where GitHub expressions are directly embedded inside shell commands.
For example, this type of pattern deserves careful scrutiny:
run: |
echo "${{ github.event.issue.title }}"A safer approach is generally to pass untrusted values through environment variables and then handle them as data rather than constructing shell commands dynamically.
env:
ISSUE_TITLE: ${{ github.event.issue.title }}
run: |
printf '%s\n' "$ISSUE_TITLE"Security teams should also consider:
- minimizing secrets available to each workflow,
- using short-lived credentials where possible,
- separating privileged and unprivileged workflows,
- avoiding unnecessary execution on public events,
- reviewing
pull_request_targetand similar high-risk triggers, - restricting network access from sensitive CI/CD jobs,
- monitoring unusual workflow behavior,
- rotating credentials exposed to potentially compromised jobs.
The important principle is simple:
Never assume that data coming from GitHub events is safe merely because it originated inside GitHub.
The Bigger Problem: Autonomous Exploitation
The Snowflake GitHub Actions incident may be remembered less for the specific vulnerability and more for what it demonstrates.
Security automation is changing.
Traditional scanners identify vulnerabilities. Advanced AI agents can potentially investigate whether those vulnerabilities are actually exploitable.
That distinction matters.
A vulnerability report can contain hundreds or thousands of potential findings. Exploitation requires reasoning about context:
- Is the vulnerable code reachable?
- Can an attacker control the input?
- Are credentials available?
- Does the environment contain valuable assets?
- Did the first exploitation attempt fail because the vulnerability is not real, or simply because the payload was incorrect?
These are precisely the kinds of questions autonomous security agents are beginning to address.
Wiz described its Red Agent as independently discovering the GitHub Actions flaw, exploiting it, validating access, and assessing the impact without human intervention during the operation.
AI Is Not Just Helping Hackers Anymore
The cybersecurity industry has spent years discussing whether artificial intelligence could help attackers write phishing emails, generate malware, or discover vulnerabilities.
The next stage may be more significant.
The question is no longer simply whether AI can generate an exploit.
The more important question is whether AI can continue working after the exploit fails.
In this case, the answer appears to be yes.
The Red Agent encountered an error, adapted its strategy, and successfully demonstrated the impact of the vulnerability. That capability brings autonomous systems closer to the iterative process traditionally associated with human security researchers.
For defenders, this means the window between vulnerability introduction, discovery, and exploitation may continue to shrink.
The Snowflake vulnerability reportedly existed for only five days before the autonomous security agent discovered it.
In the future, organizations may not have weeks or even days to discover that a dangerous change has entered their CI/CD pipeline.
Conclusion
The GitHub Actions vulnerability discovered by Wiz’s Red Agent is a glimpse into the next phase of cybersecurity.
The vulnerability itself was a serious example of workflow injection and unsafe handling of attacker-controlled input. However, the most significant part of the story was the behavior of the AI agent.
It did not simply find a suspicious pattern.
It attempted exploitation.
It failed.
It analyzed the failure.
It changed its approach.
And it succeeded.
Snowflake patched the vulnerability and rotated the affected credential, and available audit information indicated no malicious third-party exploitation.
But the broader lesson remains.
AI is increasingly becoming capable of performing iterative security research autonomously.
As AI-powered development accelerates, AI-powered offensive security capabilities are accelerating too.
The future of cybersecurity may increasingly look like this:
AI writes code. AI reviews code. AI finds the vulnerability. Another AI exploits it. And defensive AI has to detect the attack before a human even realizes what happened.
For developers, system administrators, and security teams, that means one thing: the attack surface is no longer evolving at human speed.
AI Agents Can Manipulate Other AI Agents: A New Security Threat Emerges Artificial intelligence agents are becoming increasingly autonomous. They Czytaj dalej
EU AI Act Enters a New Phase: What Changes on August 2, 2026? August 2, 2026 marks an important date Czytaj dalej
