Three of the most popular code editors on the planet shared a single, dangerous flaw: click one booby-trapped link, and an attacker could seize full control of your machine without so much as a pop-up warning. Researchers at AISLE traced the bug through Cursor, Microsoft’s Visual Studio Code, and Google’s newly launched Antigravity IDE, an exposure the firm estimates touched roughly 50 million developers before patches landed.
A Commit Message Was All It Took
The attack chain was strikingly simple. An attacker could plant a malicious link inside an ordinary-looking Git commit message. When a developer opened that commit inside the editor and clicked the link, the application quietly executed arbitrary code with full terminal privileges. No confirmation dialog appeared, no warning banner flashed, and nothing on screen hinted that anything unusual had happened. From the developer’s point of view, it looked like nothing at all.
That silence is what made the bug so dangerous. Because there was no visible trigger, victims had no real-time way to know they had been compromised. Once the code executed, attackers effectively inherited whatever access the developer already had on their own laptop.
What Was At Stake
The consequences of that access were severe. According to AISLE’s research, a successful exploit could let an attacker:
- Pull sensitive API keys for services like OpenAI, Anthropic, and Stripe directly out of the local environment
- Drop persistent malware, including keyloggers that quietly stream every keystroke to an external server
- Browse and delete files anywhere on the local file system
Because the implanted malware could survive even after the editor was closed, a single careless click risked turning into long-running, undetected surveillance of a developer’s entire workflow, including source code, credentials, and internal communications.
One Bug, Three Products
The root cause traces back to shared lineage. AISLE’s automated vulnerability scanning first flagged the issue inside VS Code in the fall of 2025. Cursor, which is built directly on top of the VS Code codebase, inherited the identical weakness, meaning two of the most widely used AI-assisted coding environments were vulnerable at the same time through no fault of their own separate engineering teams.
The story didn’t end there. Early in 2026, the same flaw resurfaced in Google Antigravity, Google’s freshly launched AI-assisted development environment, which also traces its architecture back to VS Code. AISLE reported the issue to Google, which moved quickly and closed the gap within days. Cursor’s team likewise patched fast, while Microsoft’s fix for VS Code itself took somewhat longer to ship. As of now, current releases of all three editors are clean.
A Pattern Worth Watching
The bigger lesson here isn’t really about any one vendor’s mistake. It’s about how the AI-native IDE ecosystem is structured. A growing number of coding tools fork from a shared codebase like VS Code to move fast and bolt on AI features. That convenience comes with a hidden cost: a single vulnerability discovered in the base project can silently propagate across every downstream product built on it, reaching tens of millions of users before anyone notices.
For security teams, that argues for treating IDE supply chains the same way they’d treat any other software dependency chain, tracking upstream codebases, watching disclosure feeds for the projects an internal tool is forked from, and pushing editor updates out as urgently as any other critical patch.
What Developers Should Do
The practical advice is straightforward but easy to overlook in the day-to-day rush of reviewing pull requests and commits:
- Update Cursor, VS Code, and Google Antigravity to their latest versions immediately if this hasn’t already happened automatically
- Treat links embedded in commit messages, pull request descriptions, and code comments with the same suspicion applied to links in email
- Rotate any API keys or credentials that were accessible from a machine running an unpatched version of these editors during the exposure window
- Consider running development environments with reduced local privileges where practical, so a single exploited click can’t reach an entire system
The fix is already out, but the episode is a reminder that the tools developers trust most, the editors they live in for eight hours a day, are themselves attractive and increasingly interconnected targets.
Leave a Reply