Critical One-Click RCE Flaw Exposes VS Code and Cursor Users to Remote Code Execution A one-click remote code execution vulnerability has been disclosed affecting Cursor, Microsoft Visual Studio Code, and Google Antigravity, where malicious links in commit messages can execute arbitrary code on a developer's machine. The flaw exploits the editor's handling of URL schemes, and mitigations include reviewing raw commit messages and sandboxing the editor. 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. Per the IT Security News write-up of the 2026-08-05 disclosure https://www.itsecuritynews.info/1-click-rce-vulnerability-in-cursor-vs-code-and-google-antigravity-lets-attackers-execute-arbitrary-code/ , 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: 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. 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: Not in the source — and therefore not something I'll state : 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. 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. You don't need a patch number to harden your environment. You can do most of this in an afternoon. 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. 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: git log --format=%B -n 1