TL;DR
- The same five-step chain keeps reproducing across nearly every major AI coding agent: untrusted content reaches an agent, the agent treats it as an instruction, a config file changes, a safeguard relaxes, commands execute.
- It’s architectural, not a single vendor’s bug: any agent that can read/write files, approve its own actions, and persist configuration changes is exposed by design.
- Patching each individual disclosure hasn’t stopped the pattern, because the fix addresses one instance while the underlying combination of permissions remains standard across the category.
- The chain has escalated from click-required proof-of-concept to fully zero-click compromise, and most recently to active, self-propagating exploitation in production environments.
- Model Context Protocol and conventional security tooling both miss this by design: neither reasons about whether a sequence of individually valid actions adds up to compromise, which is exactly where detection now needs to shift.
It’s one pattern
An agent reads a file, approves its own next action, and the change survives the session. That one design choice, repeated across nearly every AI coding tool built in the last eighteen months, is the reason this keeps happening.
The pattern surfaced first in GitHub Copilot: a 2025 disclosure (CVE-2025-53773) showed that a prompt injection hidden in a GitHub issue or Markdown file could get Copilot to add an auto-approve setting to its workspace configuration, silently enabling unrestricted shell execution that persisted across sessions. That was the origin case. It is not, however, where the pattern stopped; 2026 is where it became systemic. By July 2026, security researchers had confirmed the same five-step sequence in at least eight major agentic coding tools, and one class-level disclosure had already been exploited in the wild against Microsoft’s own repositories.
What does “the same vulnerability” mean?
Every incident below reduces to the same sequence:
Untrusted input reaches the agent → the agent treats it as an instruction → a local config file changes → a safeguard is relaxed or bypassed → commands executed.
Nothing in that chain is a broken feature. File editing, configuration persistence, and command execution all work exactly as designed, which is precisely why none of it looks like an attack while it’s happening.
Which AI coding tools has this actually hit?
Cursor has patched the same category of flaw three times in 2026 alone. A prompt-injection-to-command-execution flaw (CVE-2026-31854), patched in March, let instructions hidden on a visited website bypass Cursor’s command whitelist and trigger unauthorized execution. A Git hook injection (CVE-2026-26268) followed, hiding a booby-trapped hook in a repository that fired the moment the agent ran a Git command. DuneSlide (CVE-2026-50548/50549, CVSS 9.8), disclosed by Cato AI Labs in July, went further still: prompt-injected content escaped Cursor’s terminal sandbox entirely, with zero clicks required.
Claude Code’s most recent disclosed flaw exfiltrated credentials rather than triggering a shell. CVE-2026-21852, patched in January 2026, allowed API tokens to be exfiltrated through a configuration override that redirected traffic to an attacker-controlled endpoint.
Windsurf’s case needed no user interaction of any kind. CVE-2026-30615, patched in April 2026, let a prompt injection trigger arbitrary command execution with no prior approval step whatsoever, the purest zero-click version of the chain.
TrustFall (May 2026) showed the pattern wasn’t tool-specific, it was architectural. Claude Code, Gemini CLI, Cursor CLI, and GitHub Copilot CLI all could auto-execute project-defined MCP servers the instant a user accepts a folder-trust prompt, and all four default to “Yes.” One keypress on a cloned repository was enough to trigger remote code execution across every tool tested .
A prompt injection to the supply chain incident in Cline (February 2026) moved the same pattern into CI/CD. An injection planted in a GitHub issue title hijacked Cline’s own AI triage bot, which had write access to the repo. The bot poisoned the build cache, extracted publish tokens, and pushed a malicious package that reached roughly 4,000 developers before the eight-hour window closed.
A worm campaign in June 2026 is the pattern in production. The self-replicating Miasma worm planted MCP and IDE configuration files inside a Microsoft Azure repository via a compromised contributor account. Developers who opened it in Claude Code, Cursor, or Gemini CLI triggered a credential harvesting payload automatically, no click beyond opening the project. GitHub disabled 73 repositories across four Microsoft organizations within 105 seconds of detection (StepSecurity).
One distinction is worth holding onto across all of these: some required one prior approval click, others required none. That single variable: how much a user has to do before the chain fires is the closest thing to a meaningful difference between any of these cases.
So why does it keep recurring?
Every case above shares three ingredients: an agent that can read and write files, approve or automate its own tool use, and persist configuration changes across sessions. That combination is the actual point of failure.
Shell access is not a rare privilege granted to one misbehaving tool. It’s a baseline requirement for any coding agent to be useful, filesystem access to read and write code, network access to reach services, environment access to launch processes, and identity inheritance, since the agent runs as the logged-in user with whatever permissions that user holds. The question was never whether agents should have this access. It’s how to notice when it’s being used in a sequence nobody authorized.
Doesn’t MCP already solve this?
Model Context Protocol standardizes how agents discover and invoke tools, bringing structure to what used to be fragmented, per-platform tool calling. That consistency genuinely helps: permissions can be scoped, invocations logged.
But MCP governs how a tool is called, not whether a sequence of calls makes sense in context. Cursor’s Git hook flaw, DuneSlide, TrustFall, and the June 2026 worm campaign all involved MCP configuration directly, and the protocol’s design didn’t prevent any of them. When an attack chain never breaks a schema or bypasses an authentication check, security has to look past the interface and start watching behavior.
See AppSentinels MCP Security →
Why don’t existing security tools catch this?
File edits get logged as normal developer activity. Shell commands run under the developer’s own account. Network calls resemble routine workflows. No policy is violated at any single step, which is exactly why endpoint and application security tools, built to catch violations, don’t fire.
The risk accumulates through permitted actions, not a prohibited one. An agent that reads local files on day one, environment variables by day three, and cloud credentials by day five hasn’t done anything overtly wrong at any individual point. The trend is the signal, not any single action and most current tooling is built to record events, not to interpret how they relate to each other over time.
What should security teams watch instead?
Detecting this class of failure means tracking behavior over time, not point-in-time actions: sequential configuration changes that progressively relax controls, gradual expansion of data access across sessions, tool invocations that correlate with ingestion of untrusted content, and configuration state that persists across resets and drifts from a user’s original intent.
AppSentinels studies this pattern at the business logic layer, not the CVE layer. Individual disclosures: Copilot, Cursor, Claude Code, Windsurf, Cline are treated as signals of how agent behavior evolves in production, not a checklist to close out. The focus stays on how small, individually valid actions combine into risky sequences, and on catching that drift while it’s forming rather than after a worm has already moved.
See AppSentinels Agentic AI Security →
So, why do AI coding agents keep getting hit?
Copilot’s disclosure was never a one-off. It was the first documented instance of a chain that has since reproduced across nearly every major AI coding tool on the market and in June 2026, that chain moved from disclosure to active exploitation against production infrastructure. As agents gain broader permissions in the name of speed, more of this will surface as quiet drift, not loud failure. The question isn’t whether the next one shows up. It’s whether it’s caught while it’s happening, or only after.
Book a demo to learn how business logic security keeps you ahead of such threats.
FAQs
What is the Agentic RCE chain?
It’s a five-step pattern: untrusted content reaches an agent, the agent treats it as an instruction, a config file changes, a safeguard relaxes, commands execute, first exposed in GitHub Copilot in 2025 and now reproduced across at least eight major AI coding tools, most recently through a run of 2026 disclosures.
Has this actually been exploited in the wild, or is it just disclosed research?
Both. Most 2026 cases (Cursor’s CVE-2026-26268, CVE-2026-31854, and DuneSlide; Claude Code’s CVE-2026-21852; Windsurf’s CVE-2026-30615; and the TrustFall flaws) were responsibly disclosed and patched. Two were exploited live: the Cline incident compromised roughly 4,000 developers through a poisoned npm package in February 2026, and a worm campaign auto-compromised developer machines across 73 Microsoft repositories in June 2026.
Which AI coding tools have been affected?
At minimum: GitHub Copilot, Cursor, Claude Code, Windsurf, Cline, Gemini CLI, GitHub Copilot CLI, Grok Build, and OpenAI Codex. Two separate class-level disclosures each confirmed the same underlying flaw across four and six tools respectively, indicating a shared architectural pattern rather than isolated vendor bugs.
Will Model Context Protocol (MCP) prevent future versions of this?
Not on its own. MCP standardizes how tools are invoked and improves auditability, but several of the incidents above involved MCP configuration directly. The protocol governs how a call is made, not whether a sequence of calls makes sense in context.
How can development teams reduce exposure right now?
Disable auto-approval for agent tool actions, review configuration changes before accepting them, restrict agent permissions to the minimum scope needed, and treat any repository from an unfamiliar source, including its config files, with the same caution as untrusted code. Monitor for configuration drift across sessions, not just single suspicious commands.
What should security teams monitor to catch this before a patch exists?
Shift from single-action alerts to sequence-based detection: configuration changes that progressively relax controls, tool invocations that correlate with ingestion of untrusted content, and access scope that expands gradually across sessions. Traditional anomaly detection misses this because each individual step is logged as legitimate activity.
