Critical One-Click RCE Flaw Exposes VS Code and Cursor Users to Remote Code Execution

Cursor, VS Code, and Antigravity are the best AI editors most of us have ever used. Here's the new 1-click RCE bug, and what to do about it today.

The three editors developers are leaning on hardest right now — Cursor, Microsoft Visual Studio Code, and Google Antigravity — just got hit with a disclosure worth taking seriously: a one-click remote code execution flaw where the trigger is a link inside a commit message. Click the link, and your endpoint belongs to whoever embedded the command.

This is the kind of bug that reads as theoretical until it isn't. Most teams using these tools are flying through AI-assisted edits, trusting the editor to be on their side. It isn't always.

What the disclosure actually says

Per the IT Security News write-up of the 2026-08-05 disclosure, the flaw lets an attacker hide malicious commands inside links placed in commit messages. The victim clicks the link — a routine action — and arbitrary code runs on the developer's machine. The "1-click" in the name isn't marketing; it's the whole attack. One click, full endpoint compromise.

Two things make this different from a normal phishing bug:

1. The link lives in your editor, not your inbox. You're already in a trusted context. The link looks like any other commit-message link. There's no external pretext to evaluate.
2. The editor is the executor. AI-assisted coding environments do more interpretation and automation on user content than a normal text editor ever did. A link is no longer just text; it's potentially an instruction.

[[CONCEPT: editor as execution environment — links are instructions, not data; the trust boundary moved from "the network" to "the editor itself"]]

That's the part that should change how every team thinks about editor trust boundaries — and it's the part that isn't getting fixed by patching any single editor.

What the source actually tells us — and what it doesn't

I want to be precise about what is confirmed versus what is unconfirmed, because security posts are full of confident-sounding specifics that turn out to be invented.

Confirmed from the source article:

• A 1-click RCE has been disclosed affecting Cursor, VS Code, and Google Antigravity.
• The attack vector is malicious commands embedded in links inside commit messages.
• The consequence is arbitrary code execution on the developer's machine.
• Disclosure date: 2026-08-05.

Not in the source — and therefore not something I'll state:

• Specific affected version numbers for any of the three tools.
• A CVE id.
• Patch availability or the version that fixes it.
• The exact mechanism the editor uses to interpret the link (custom protocol handler, websocket, child process, etc.).
• Any quoted advisory text.

When version numbers, CVEs, and patch advisories are published by the respective vendors, treat those as ground truth. Until then, "your version is potentially affected" is the only honest thing to tell your team. Anyone publishing a fixed version number for one of these three tools without citing the vendor advisory is guessing.

How a link-in-commit-message RCE typically plays out

Even without the vendor's technical write-up, the shape of this class of bug is well-understood, and the mitigations don't depend on knowing which parser is being abused.

The pattern:

attacker crafts a commit message with a link
   │
   ▼
link uses a scheme the editor treats as executable
   │  (vscode://, cursor://, antigravity://, file://, javascript:, ...)
   ▼
preview / hover / click triggers the editor's URL handler
   │
   ▼
handler spawns a process, opens a child, or invokes the agent loop
   │
   ▼
arbitrary commands reach the developer's shell

The fix isn't "stop clicking links." The fix is that the editor should treat arbitrary schemes from arbitrary sources as data, not instructions. Until that is the default everywhere, you enforce the boundary yourself.

What to do today, before you have a CVE to point at

You don't need a patch number to harden your environment. You can do most of this in an afternoon.

1. Audit what your editors actually execute on click

# macOS — see which URL schemes your editors have registered
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -dump \
  | grep -E 'vscode|cursor|antigravity' \
  | grep -i 'scheme'

# Linux — check xdg-mime for editor handlers
xdg-mime query default x-scheme-handler/vscode
xdg-mime query default x-scheme-handler/cursor
xdg-mime query default x-scheme-handler/antigravity

If a tool is registered as a handler for a scheme and you didn't intentionally install it, that's the surface to lock down or remove.

2. Treat commit messages as untrusted input

Most teams apply least-trust to code, dependencies, and CI logs. Commit messages are usually exempt. Stop treating them as exempt.

Concrete policy to ship to your team today:

• Never click a link in a commit message from an unfamiliar contributor.
• For unfamiliar links, copy and inspect the URL before opening — don't middle-click.
• Run git log --format=%B -n 1 <sha> and review the raw body before any link is rendered by the editor.
• For PRs from forks or first-time contributors, scrub the body for vscode://, cursor://, antigravity://, file://, or any javascript: prefix.

3. Sandbox the editors

Even with mitigations, the editor is a high-privilege process. Run it under a sandbox.

# Example: bubblewrap on Linux, deny network by default
bwrap --ro-bind /usr /usr \
      --bind "$HOME" "$HOME" \
      --dev /dev \
      --proc /proc \
      --tmpfs /tmp \
      --unshare-net-try \
      -- \
      cursor .

macOS users: a per-app sandbox profile plus an outbound-network deny-by-default rule for the editor is the minimum. Don't let the editor reach the open internet from your dev account.

4. Reduce blast radius

If your editor does get popped, what can it touch?

• Separate browser profiles for "logged-in to everything" and "this is the dev sandbox."
• SSH keys on a hardware token (FIDO2), not on disk.
• Secrets in a vault, not in ~/.aws/credentials.
• A non-root daily-driver account; admin only when you actually need it.

None of this is glamorous. All of it shrinks the blast radius from "lost my laptop" to "had to rotate a token."

5. Watch for the real advisories

Track vendor security feeds directly:

• Cursor: the vendor's security / changelog page
• VS Code: Microsoft's Security Update Guide and the VS Code release notes
• Google Antigravity: Google's security bulletin feed

When the patches land, apply them same-day. Don't wait for the next sprint.

The bit that doesn't change when the patch lands

Here's the uncomfortable part. This specific bug gets patched. The pattern doesn't. AI-assisted editors are increasingly the place where trust decisions happen on your behalf — link rendering, agent actions, file reads, terminal commands. Each new capability is a new instruction channel. Every editor in this class will keep trading off "smart interpretation of user content" against "secure handling of untrusted content," and that tradeoff will keep producing bugs of this shape.

The durable layer underneath the editor churn is the codebase shape itself — the parts that don't change when the editor changes. Components, routing, type boundaries, build config. When the editor is doing more on your behalf, the surface you can trust has to get smaller, not larger. Tight component APIs, generated types end-to-end, and a single cross-platform UI layer mean the editor has fewer ways to surprise you, because there's less ambiguity about what each piece is for.

This is where a unified cross-platform component API earns its keep: the same Card, Form, Dialog, and Sheet from web to iOS to Android, with one type signature and one behavior. One component, three platforms, one API. That's not a security feature — but it is fewer places where the editor's agent can be clever on your behalf, and that's adjacent to one.

(For context: that kit is OTF — web and native components that look and behave identically across platforms, with generated types end-to-end and a single API across web, iOS, and Android. Use Cursor, use VS Code, use Antigravity — and put a layer underneath the agent that the agent can't quietly reinterpret.)

What this gets us

If you take one thing from this disclosure: the editor is no longer a dumb text renderer. It's an execution environment that happens to have a file tree. Treat it like one. Sandbox it. Watch the URL schemes it handles. Audit commit messages before the editor renders them. Wait for vendor advisories and patch same-day.

The AI coding tools themselves are the most productive editors most developers have ever used. The bug is real, the fix is coming, and the durable answer is the same as it has been for a decade: smaller trusted surface, fewer clever interpretations, and a code layer the editor can't quietly rewrite.