For most of their history, code editors were passive. They showed you text and ran what you told them to run. The AI editor broke that assumption. Cursor, VS Code, and Google Antigravity now read content on your behalf, plan actions, and run commands in your terminal, often behind a sandbox that is thinner than it looks. In 2026, three separate flaw clusters turned that convenience into full remote code execution. One needed a single click. One needed no click at all.
The through-line matters more than any single bug. Prompt injection used to be a chatbot curiosity: feed a model some sneaky text and get a bad answer back. Put the same model inside an editor that can call run_terminal_cmd, and the worst case stops being a wrong answer. It becomes code running on your laptop.
Why an AI editor is a different attack surface
A traditional editor only executes what you type. An agentic editor executes what it decides to do after reading input, and a lot of that input is not written by you. A Git commit message. A web page the agent fetches to "research" a task. A file that another tool generated. A config file inside a repository you just cloned.
That is the shift. The trust boundary moved from "the code you run" to "everything the agent reads." Indirect prompt injection, where attacker-controlled text reaches the model as if it were an instruction, becomes a path to execution rather than a prompt-engineering party trick. All three of the flaws below are variations on the same theme: untrusted content reaches an agent that can act, and the guardrail between "suggest" and "execute" turns out to be soft.
The 1-click RCE: a commit message that owns your machine
The AI-native security firm AISLE found the broadest of the three. An attacker embeds a malicious link inside a Git commit message. When a developer clicks that link inside the editor, the application executes arbitrary code with full terminal privileges. No confirmation dialog. No warning prompt. No visible sign that anything happened.
AISLE's automated analysis first flagged the weakness in VS Code in the autumn of 2025. Because Cursor is built on VS Code, it inherited the same flaw, and the issue persisted into 2026 and later surfaced in Google Antigravity as well. By AISLE's estimate, the bug exposed roughly 50 million developers to silent, total system compromise from a single click.
The impact is exactly what terminal-level access implies. An attacker could exfiltrate API keys for services like OpenAI, Anthropic, and Stripe, drop a persistent keylogger, and rewrite files on disk, with the malware surviving after the editor was closed. Following AISLE's reports, Google and Cursor addressed the flaw, and Microsoft subsequently fixed it in VS Code.
DuneSlide: a zero-click sandbox escape
If the 1-click bug is alarming, the pair that Cato AI Labs disclosed is worse, because it needs no click at all. Tracked as CVE-2026-50548 and CVE-2026-50549 and nicknamed DuneSlide, the two flaws carry a CVSS score of 9.8 and affect an editor used by more than half of the Fortune 500.
The attack begins when a developer submits a perfectly innocuous prompt. That prompt causes Cursor's agent to ingest attacker-controlled content from an untrusted source, and from there the chain runs on its own, with no further click or approval. This is indirect prompt injection with an RCE payoff.
The two bugs each break a different assumption:
- CVE-2026-50548 abuses the optional
working_directoryparameter of Cursor'srun_terminal_cmdtool. The sandbox permits writes to a command's working folder, and the agent can set that folder to anything it likes, including a path outside the project such as thecursorsandboxbinary on macOS or a shell startup file like~/.zshrc. Overwrite the sandbox binary, and the next "sandboxed" command runs unsandboxed. - CVE-2026-50549 breaks Cursor's path-resolution logic. Before writing a file, Cursor resolves symbolic links to confirm the real destination sits inside the project. The bug is in the fallback: when that check fails, Cursor trusts the path the symlink declared instead of blocking the write.
Put together, a benign-looking request lets attacker text steer a file write to a location that flips the whole sandbox off.
Rendering diagram
Cato reported both bugs to Cursor in February 2026. Cursor 3.0 shipped the fixes on April 2, and the CVE IDs were assigned on June 5. Every version before 3.0 is affected.
Workspace hooks that run without asking
The third flaw is the simplest, and the one most likely to catch a careful engineer off guard. Tracked as CVE-2026-48124, it let Cursor Desktop execute workspace-defined Claude hook commands from a repository's .claude/settings.local.json without a dedicated approval step. A malicious repository, or even a file the agent itself created during a session, could configure a hook that runs local commands in the user's context.
There is no clever exploit chain here. Clone an untrusted repository, open it, and a configuration file runs code. Cursor resolved the issue in version 3.0.0. It is a clean illustration of the core problem: config that used to be inert is now executable, because an agent is standing behind it ready to act.
The pattern under all three
| Flaw | Trigger | What the attacker controls | Impact | Fixed in |
|---|---|---|---|---|
| 1-click RCE (AISLE) | One click on a link in a Git commit message | The commit message contents | Arbitrary code, full terminal privileges, no prompt | VS Code, Cursor, and Antigravity patches |
| DuneSlide (CVE-2026-50548 / 50549) | A benign prompt, then no further click | Content the agent ingests | Sandbox escape to OS-level RCE, CVSS 9.8 | Cursor 3.0 (April 2, 2026) |
| Workspace hooks (CVE-2026-48124) | Opening a malicious repo or workspace | .claude/settings.local.json hooks | Local command execution in the user context | Cursor 3.0.0 |
Three different vectors, one root cause: an autonomous agent, plus untrusted input, plus a terminal, plus a sandbox that can be edited from inside it. Each ingredient is individually reasonable. Together they are a remote code execution primitive.
The blast radius is the reason this deserves attention beyond the AI-tooling crowd. A developer machine is not a low-value target. It holds cloud credentials, signing keys, source code, session tokens, and a direct line into CI and production. One RCE on a laptop is frequently the first hop of a much longer chain.
What to do now
- Patch. Move to Cursor 3.0 or later, and keep VS Code and Antigravity current. This closes the specific bugs above.
- Turn off auto-run. Require a human approval for every command the agent wants to execute, at least for repositories you do not fully trust. Convenience auto-approve is exactly what these attacks rely on.
- Treat what the agent reads as untrusted input. Commit messages, issues, fetched web pages, and files other tools generate are all attacker-reachable. Apply the same suspicion you already apply to user input in a web app.
- Shorten the life of your secrets. Do not keep long-lived API keys in an environment the agent can read. Scoped, short-lived tokens from a secrets manager make an exfiltrated key far less useful.
- Watch egress. A developer machine that suddenly connects to an unfamiliar host is a signal worth alerting on.
- Open unknown repositories in a throwaway VM or container, not on your primary workstation.
How Breachline helps
Nebula tests AI and LLM systems the way an attacker does, including the exact bug class behind these editor flaws: direct and indirect prompt injection, tool and function-call abuse, and sandbox escapes, mapped to the OWASP LLM Top 10. If your product embeds an agent that reads untrusted content and can act on it, the question is not whether the model is clever. It is whether that content can steer the agent into something it was never meant to do. That is what we prove, with a working exploit, before an attacker does.
Takeaways
- Prompt injection is no longer a chatbot problem. Inside an agentic editor it is a remote-code-execution vector, and 2026 produced three separate proofs of it.
- Patch Cursor to 3.0 or later, update VS Code and Antigravity, and require approval for any command an agent wants to run.
- Any system where an AI agent ingests untrusted content and can execute actions needs to be tested as an attack surface, not trusted as a feature.
Sources
- A 1-Click RCE Issue in Cursor, VS Code, and Antigravity, AISLE
- DuneSlide: Two Critical RCE Vulnerabilities in Cursor IDE, Cato Networks
- Critical Cursor Flaws Could Let Prompt Injection Escape Sandbox and Run Commands, The Hacker News
- Critical Cursor AI Code Editor Flaws Could Lead to OS-Level Remote Code Execution, SecurityWeek
- CVE-2026-48124: Cursor Code Editor RCE Vulnerability, SentinelOne