Critical one-click RCE flaw exposes VS Code and Cursor users to remote code execution

If you clicked a link inside a Git commit message in Cursor, Visual Studio Code, or Google Antigravity, the practical first step is to update the editor you use. AISLE, the security research team that reported the issue, says the vulnerability has been fixed in all three products and recommends moving to the latest version. Its public write-up does not list fixed version numbers, so this guide does not guess at them.

This matters to developers who review unfamiliar repositories or browse commit history inside an editor. A link in a commit message can look like ordinary project context. In this reported issue, clicking a malicious link could trigger code execution without a confirmation prompt. Updating addresses the known issue; it does not make every link, extension, repository, or editor feature safe.

What AISLE reported

AISLE researcher Stanislav Fort published the disclosure on 31 July 2026. AISLE says its researchers found the vulnerability in Visual Studio Code first, then reported it to Microsoft and Cursor; the report says the issue later appeared in Google Antigravity as well. In the affected behavior, a malicious command could be hidden in a link inside a commit message. Clicking the link could execute arbitrary code on the developer’s machine.

AISLE says Google and Cursor fixed the issue after receiving reports, Microsoft remediated it later, and the vulnerability is not present in the current versions of the three products. The report recommends updating to the latest release. It does not give the affected-version ranges or exact fixed versions, and the available public write-up does not name a CVE. Do not use a guessed version cutoff or CVE as a release gate.

The distinction between “reported and patched” and “safe to click anything” is important. This disclosure covers a particular link-handling flaw. It is not a blanket security assessment of the editors, their extensions, or every action an agent can take.

Update the editor you actually run

Start with each editor installed on your workstation, not just the one you opened today. Check the version in the app’s About screen or use its built-in update command, then install the newest release available from the vendor. If the product is managed by an organization, confirm that the managed installation has received its update; an up-to-date personal copy does not tell you the state of a shared build machine.

For Visual Studio Code, Microsoft’s release notes provide the current release and update instructions. The 1.132 release page, for example, directs users to use Check for Updates to get the latest version immediately and notes a 1.132.1 security update. That page does not identify the AISLE issue by name, so use it as the official update path rather than as evidence for an exact fix version.

For Cursor and Antigravity, use their own in-app update mechanism or official release channel. AISLE’s disclosure is the source for the statement that the current versions have the reported issue fixed. If your organization pins versions, ask the editor administrator which released build is approved and when the fleet will move. Record the installed version and the date you checked it so the review has evidence.

Do not infer that a product is patched just because its base editor, another editor, or a teammate’s laptop is patched. Cursor and VS Code may share upstream code, but their releases are separate; Antigravity has its own release path too. Verify each installed product independently.

If someone clicked a suspicious commit link

First establish what happened. Identify the repository, the commit, the link target, which editor opened it, the editor version at the time, and the time of the click. Preserve relevant logs and report the event through your organization’s incident process. Do not click the link again to “test” it.

AISLE describes the issue as code execution that could allow data theft, malware installation, or file deletion. That describes potential impact, not proof that every click led to compromise. Treat a click on an untrusted link from an outdated build as a possible security incident and investigate using your team’s endpoint and identity logs. Rotate or revoke credentials when the investigation indicates they may have been exposed; a blanket rotation without checking scope can create disruption while missing the actual access path.

If you cannot determine whether the installed build was current at the time, keep that uncertainty visible in the incident record. The disclosure does not provide public affected-version ranges, so a precise version comparison may require confirmation from the vendor or your administrator. Do not label a machine “clean” based only on the absence of an obvious pop-up.

Make commit messages part of the review boundary

A commit message is content supplied by whoever created the commit. Read it as data, even when it appears in a familiar editor or repository. Before opening a link from an unfamiliar contributor, inspect its destination and ask whether the link is needed for the review. If the destination is unexpected, use your organization’s reporting path instead of opening it.

This is a useful review habit, but it is not a patch. Avoid replacing the update with a blanket instruction to disable unrelated editor features or network access: the disclosure does not say those steps remediate the vulnerability. Use only mitigations that the vendor or your security team has tied to the actual affected behavior.

Teams can make the process repeatable with a short checklist:

1. Inventory the editor products used for code review, including managed and remote development environments.
2. Check and update each product through its official release channel.
3. Confirm the installed version on machines that review repositories or run coding agents.
4. Treat links in commit messages and other repository-supplied text as untrusted until reviewed.
5. If a suspicious link was opened on a potentially affected build, preserve evidence and follow incident response rather than rerunning the link.

For an AI coding workflow, include the same boundary in review guidance: repository content can be useful context without being trusted instructions. This is relevant to commit messages, issue descriptions, generated files, and links surfaced by tools. Keep the rule narrow enough that reviewers can apply it consistently.

What this does and does not mean for app teams

The reported vulnerability is in editor link handling. It is not evidence that an app built with a particular framework or UI kit is affected, and changing application components does not remediate a workstation-level remote-code-execution flaw. Keep endpoint security, editor updates, repository review, and application security as separate controls.

If you are also reviewing the application your team is building, use the AI app security checklist for that separate task. It does not replace updating Cursor, VS Code, or Antigravity. For this disclosure, the immediate action is simpler: identify the editor installed on each relevant machine, update it through the vendor’s official channel, and verify the result.

Sources

• AISLE, A 1-Click RCE Issue in Cursor, VS Code, and Antigravity — original researcher disclosure, published 31 July 2026; reports the commit-message link vector and states the issue is fixed in current versions of all three products.
• Microsoft, Visual Studio Code 1.132 release notes — official update path and release notes; cited for how to check for the latest update, not as confirmation of an exact AISLE fix version.

Related guides

• See the AI app security checklist for application-level review after editor updates.

Free starter

Ship your first screen tonight — free starter in your inbox

The quickstart, the SDK repo and the live kit demos, on this screen and in your inbox.

Send the starter

No spam. Unsubscribe any time.