Skip to content
Security Article

One Link in a Commit Message Owns Your Editor

AISLE found the same click-to-execute bug in VS Code, Cursor, and Antigravity, proving the fork monoculture ships shared risk.

Ji-ho Choi
Ji-ho Choi
Security & Cloud Editor · Aug 5, 2026 · 5 min read
One Link in a Commit Message Owns Your Editor

You review a pull request. You clone a repo to poke at it. You scroll through git log in your editor's source-control panel and click a link in a commit message — an issue reference, a changelog URL, something that looks routine. On unpatched builds of VS Code, Cursor, and Google Antigravity, that single click was enough to run arbitrary code on your machine with full terminal privileges. No confirmation dialog. No warning. No visible sign anything happened.

That's the flaw AISLE disclosed this week, and the reason it matters is not the bug itself — it's how many editors shipped it at once.

The read/execute line just moved

For twenty years the security contract of a code editor was simple: opening a file shows you text, running it is a separate, deliberate act. Workspace Trust, Restricted Mode, "do you want to run this task?" — all of it exists to keep viewing untrusted code from executing untrusted code. A commit-message link that pops a shell erases that line entirely. The payload rides in content you're expected to read, not run. Reviewing a hostile fork, triaging a drive-by PR, browsing git blame on a dependency you're evaluating — every one of those became a code-execution surface.

AISLE hasn't published the exact handler, and I'm not going to invent one. But the shape is familiar to anyone who's watched VS Code's security history. The editor has repeatedly been bitten by the same family of bugs: UI surfaces that render semi-trusted content as clickable actions, where a crafted command: URI or deep link reaches an internal command that can spawn a process or install an extension. It's the lineage behind the old Restricted Mode escape (CVE-2021-43908) and a long tail of markdown-hover and command-URI-with-arguments issues. The novelty here isn't the mechanism. It's that the same code shipped in three products at once.

One bug, one codebase, three brands

Cursor is a fork of VS Code. Antigravity is built on the same foundation. So is a good chunk of the AI-editor field. When the rendering and link-handling core lives upstream, a single upstream defect isn't one product's problem — it's the shared inheritance of everything downstream. AISLE says it found the flaw in VS Code via automated scanning in the fall of 2025, then found the same flaw sitting in Antigravity months later. That's the monoculture doing exactly what monocultures do.

The reporting puts the blast radius near 50 million developers. Treat that number as a back-of-envelope estimate — I couldn't find a cited methodology behind it — but the order of magnitude is right, and the mechanism is what makes it credible. You don't need 50 million targets; you need one poisoned repository that enough people clone or review. A malicious commit in a popular open-source project, a booby-trapped PR against a widely watched repo, a typosquatted mirror — the delivery is trivial precisely because commit messages travel everywhere and nobody treats them as executable.

And the payoff is total. On a developer's box, arbitrary execution means the crown jewels: OPENAI_API_KEY, ANTHROPIC_API_KEY, cloud credentials, SSH keys, .env files, session tokens. Drop a keylogger, plant persistence, exfiltrate and move on. The machine that holds your production access is the same machine you use to skim a stranger's git history.

The pattern is bigger than one flaw

This lands in the middle of a bad stretch for AI editors. Cato Networks' "DuneSlide" pair (CVE-2026-50548 and CVE-2026-50549, both CVSS 9.8) escaped Cursor's sandbox via zero-click prompt injection and was patched in Cursor 3.0. Separate sandbox-bypass work has hammered Cursor, Antigravity, and agent CLIs over the same months. Those are prompt-injection bugs — the agent gets talked into doing something. The AISLE flaw is arguably scarier because it needs no agent at all. It's a plain UI bug in the editor chrome, the boring part everyone stopped auditing while attention moved to the LLM.

Put together, the message is clear: the agentic IDE has quietly become one of the fattest attack surfaces a developer runs. It renders untrusted content like a browser, it holds credentials like a password manager, and — increasingly — it executes commands on your behalf like a shell. Three threat models in one process, and until recently only the shell part was taken seriously.

Who moved, and what you do Monday

The vendor response is the one genuinely reassuring part, and it's also a scoreboard. Google patched Antigravity within days. Cursor moved fast. Microsoft's fix for VS Code arrived later — which is the structurally worrying detail, because a fork can't fully outrun a bug that lives upstream. Downstream editors that patched their own copy still depend on Microsoft to fix the source of truth, and forks routinely lag upstream by weeks. The fork model is fantastic for shipping features and quietly terrible for distributing security debt.

All three are patched now, so step one is boring and non-negotiable: update every editor on every machine, today. Auto-update is not a strategy when the update cadence is what saves you.

Beyond that, adjust your mental model. Your editor is a browser that happens to run your code — so give it a browser's suspicion:

  • Live in Workspace Trust / Restricted Mode. Opening an unfamiliar repo in Restricted Mode disables terminal, tasks, debugging, and agent execution by default. When in doubt, don't trust the folder.
  • Review hostile code in a throwaway. A container or VM with no real credentials turns "click-to-RCE" into "click-to-nothing."
  • Dial back agent autonomy. Auto-run, auto-approve, and broad allowlists are the same class of risk with a friendlier UI. Keep a human in the loop on command execution.
  • Rotate what a compromised box would leak — API keys, tokens, SSH keys — if you were running an unpatched build against untrusted repos.

The one-click bug will be forgotten in a month. The lesson underneath it shouldn't be: the tools we trust most now share a spine, and when that spine cracks, it cracks everywhere at once.

Sources & further reading

  1. Critical One-Click RCE Flaw Exposes VS Code and Cursor Users to Remote Code Execution — dev.to
  2. 1-Click RCE Vulnerability in Cursor, VS Code, and Google Antigravity Exposes 50M Developers — cybersecuritynews.com
  3. Critical Cursor AI IDE Flaws Could Lead to OS-Level Remote Code Execution — securityweek.com
  4. DuneSlide: Two Critical RCE Vulnerabilities via Zero-Click Prompt Injection in Cursor IDE — catonetworks.com
  5. Workspace Trust — code.visualstudio.com
Ji-ho Choi
Written by
Ji-ho Choi · Security & Cloud Editor

Ji-ho covers the increasingly tangled overlap between cloud architecture and security, drawing on a background as a penetration tester to keep his reporting grounded in real-world attack paths. He never lets a vendor claim go unquestioned and insists that every buzzword come with a proof of concept.

Discussion 1

Join the discussion

Sign in or create an account to comment and vote.

Tobias Lindqvist @securepaws · 1 hour ago

the fact that this was in three separate codebases is bad. the fact that it took external research to surface it is worse.

Related Reading