I. Background and problem description
1.1 State of the AI IDE Ecosystem
Over the past 12 months, large-scale language model (LLM)-driven code generation tools have been rapidly integrated into developer workflows, and a new generation of AI IDEs such as Cursor, Windsurf, and Google Antigravity are built on Microsoft's VSCode, offering code completion, multi-tasking, and multi-document editing capabilities by integrating models such as Claude, GPT-4, and Gemini. These platforms offer code completion, multi-file editing, and autonomous task execution capabilities by integrating models such as Claude, GPT-4, and Gemini. These platforms have gained rapid adoption due to their ease of use and improved development efficiency, with more than 1 million cumulative users.
However, these IDEs are not developed from scratch, but are implemented by forking the VSCode source code. While the forked model speeds up the development cycle, it also inherits the core design decisions of the original project - including extending the recommendation logic.
1.2 Core Vulnerability Mechanisms
Configuration inheritance issues: VSCode's recommended configuration for extensions hardcodes a pointer to Microsoft's official Visual Studio Marketplace. However, Cursor, Windsurf, and Google Antigravity were unable to use Microsoft's Extension Marketplace directly due to legal and licensing restrictions, and instead relied on OpenVSX, an open source alternative operated by the Eclipse Foundation; nonetheless, these IDEs retained their original configurations during the forking process without appropriate adjustments.
Recommended trigger mechanism: Extended recommendations for AI IDEs such as n8n fall into two categories:
File-based recommendations:Automatically suggests extensions when it detects that a user has opened a specific file type (e.g. azure-pipelines.yaml)
Software-based recommendations:Triggers a recommendation when it detects that a specific application (such as PostgreSQL) is installed on the system.
Namespace hijacking risk: The key problem is that these recommended extensions (e.g., ms-ossdata.vscode-postgresql, ms-azure-devops.azure-pipelines) usually have no entity in OpenVSX, which means that the publisher namespace is in an ”undeclared This means that publisher namespaces are in an ”undeclared" state. Any attacker can register these namespaces, upload malicious extensions, and the IDE's recommendation mechanism will automatically show these malicious versions to users as if they were official products.
1.3 Proof of concept and practical implications
Koi Security researchers verified the feasibility of the attack through a proof of concept (PoC). They claimed multiple undeclared namespaces including the following:
ms-ossdata.vscode-postgresql
ms-azure-devops.azure-pipelines
msazurermtools.azurerm-vscode-tools
usqlextpublisher.usql-vscode-ext
cake-build.cake-vscode
Even though the researchers uploaded extensions that were clearly labeled as placeholders and contained no functionality, more than 1,000 developers installed them, with more than 500 installations occurring when the extensions completely lacked icons and clear labeling. This data demonstrates the high level of trust developers place in IDE recommendations and the practicality of the attack.
II. Technical analysis
2.1 Complete Attack Chain for Supply Chain Attacks
The vulnerability falls into the second category of supply chain attacks - i.e., large-scale downstream impact by contaminating tools trusted by developers. Unlike traditional attacks against software packages, such as the Shai-Hulud 2.0 npm worm, the attack vectors of this vulnerability are more direct and difficult to defend against:
Initial Entry:Attacker detects undeclared namespaces in OpenVSX (identified by scanning IDE configuration file)
Namespace registration:Register the namespace recommended by the target IDE in OpenVSX.
Malicious extension uploads:Write malicious extensions that include backdoor, credential theft or data exfiltration logic
Automatically recommend triggers:The IDE automatically recommends malicious extensions when the user opens a specific file or when the system detects a related application.
User installation and activation:Due to the credibility of the recommendation, most users install the extension without additional validation
Code execution and persistence:Malicious extension gains full access to IDE processes, filesystems and user credentials
2.2 Information security impact assessment
The impact of the vulnerability spans multiple critical assets in the developer ecosystem:
| Type of impact | Specific risks | threat level |
|---|---|---|
| code integrity | Malicious extensions can directly modify the source code during development to inject backdoors or vulnerabilities | severity |
| voucher leakage | Access to SSH keys, AWS credentials, API tokens, database passwords in environment variables | severity |
| source code theft | Uploading project code to an attacker-controlled server leads to intellectual property leakage | severity |
| Toxification of the supply chain | Developers passively spread malicious code to their compiled products, affecting downstream users | severity |
| persistent access | Create backdoors in development environments for long-term monitoring and lateral movement | severity |
| covert | Extended code is often executed in areas of low user interest and is difficult to detect | moderate |
2.3 Open Source Ecosystem Vulnerability Correlation
This event forms a systemic risk pattern with multiple major supply chain events in 2025:
OpenVSX Vulnerability (June 2025)Koi Security discovered a CI/CD flaw in OpenVSX's release process that allowed an attacker to hijack the OVSX_PAT environment variable to gain write access to the entire marketplace. The vulnerability is classified as a ”one-click marketplace-wide takeover” and affects over 8 million developers.
Shai-Hulud npm worm (2025):The self-propagating malware automatically hijacked developers' npm tokens by injecting code into compromised npm packages and used them to contaminate other packages. The attack eventually affected 500+ package versions.
GitHub Actions Supply Chain Events (March 2025)The widely used tj-actions/changed-files Action was modified by an attacker, resulting in the CI/CD secret key being leaked in public logs.
Together, these incidents point to the fact that the developer toolchain has become the highest-value attack target, as a single intrusion can impact hundreds or thousands of downstream projects.
III. Vendor Response and Repair
3.1 Disclosure Timeline vs. Vendor Attitudes
| company | Date of report | Initial response | restoration status | Repair speed ratings |
|---|---|---|---|---|
| Cursor | 2025/11/23-24 | speedy confirmation | 2025/12/1 Rehabilitation completed | ✅ Excellent (8 days) |
| 2025/11/23-24 | Acceptance after two rejections | 2025/12/26 partially fixed; 2026/1/1 fully fixed | ⚠️ slow (39 days) | |
| Windsurf | 2025/11/23-24 | No response at all | unrestored | ❌ No response |
Analyze the key points:
Cursor's quick response demonstrates the maturity of its security team, and the fact that the fix was completed within eight days shows the importance the company places on its vulnerability management process.
Google initially adopted a ”Won't Fix” attitude, suggesting that its initial assessment of the severity of the vulnerability was inadequate. Under pressure from the community and the media, Google phased in the fix: first removing 13 recommendations on December 26th, and then confirming the full fix on January 1st. This phased response may reflect the complexity of internal rollout and prioritization.
Windsurf's unresponsive status is most concerning because the platform has a broad base of enterprise users, and long delays in fixes mean those users are continually exposed to risk.
3.2 Rehabilitation Program
The Cursor and Google fixes are based on the following principles:
Recommended list cleanup:Remove referral entries pointing to non-existent extensions
Configure the calibration:Verify at build time that the recommended extensions do exist in OpenVSX
Namespace validation:Ensure that the recommended publisher is an official certified identity
Version Lock:Hardcoding to point to a specific version of an extension rather than relying on dynamic parsing
IV. Ecological defenses and long-term challenges
4.1 Eclipse Foundation Risk Response
As the operator of OpenVSX, the Eclipse Foundation has taken systematic defense measures:
Namespace validation enhancement:Implement a stricter publisher authentication process to prevent unauthorized parties from claiming official namespaces
Extended Signature Mechanism:Promote the introduction of digital signatures for extensions, enabling users to verify the true origin of extensions
Security Audit:Full audit of declared namespaces in OpenVSX, identifying and removing suspicious entries in collaboration with Koi Security
Post workflow enhancements:Improve credential management in CI/CD pipelines to prevent environment variable leakage
4.2 Systemic Risk and the MITRE ATT&CK Framework Update
MITRE officially added ”IDE Extensions” to the ATT&CK framework in April 2025, marking the upgrade of this type of attack to an actionable threat technique. The code for this new technique is Txxxx, covering the following sub-technologies:
Malicious extension recommendations:Distribute malicious extensions through the IDE's recommendation mechanism
Extended namespace hijacking:Register and impersonate the official extension namespace
Back-loading malicious code:Injecting malicious code into legitimate extensions through the extension update process
This update reflects the fact that the industry has generally recognized the systemic risk of IDE extensions as attack vectors.
4.3 Developer Security Recommendations
Given the trust base of the extended recommendation mechanism, individual developers should take the following defensive measures:
Manual validation:Before installing the recommended extension, manually visit the official OpenVSX website to verify that the extension is indeed from the labeled publisher
The principle of least privilege:Audit installed extensions regularly, keep only essential extensions and disable inactive extensions
Voucher Management:Avoid storing sensitive credentials in plaintext in IDEs; use key management systems (e.g. 1Password, HashiCorp Vault)
Environmental isolation:Isolating IDE environments with containerization or VMs on critical projects
Extended monitoring:Deployment of an endpoint monitoring tool (EDR) to track network behavior and file access for extended processes
4.4 Enterprise-level governance recommendations
For organizations adopting AI IDE, the following governance framework is recommended for implementation:
| Governance dimension | Specific measures |
|---|---|
| List of resources | Maintain a real-time inventory of all deployed IDE versions, including users, deployment locations, and sensitive project associations |
| Extended Whitelisting | Enforce extended whitelisting via IDE configuration, EDR rules, or network isolation |
| Code Signing Verification | The implementation process ensures that all code is signed and scanned before it is pushed, detecting extended modified code |
| log aggregation | Aggregate IDE process logs to track events such as extension installations, activations, network calls, etc. |
| Supplier evaluation | Require IDE vendors to provide security assessment reports, vulnerability response SLAs, extended market governance policies |
| Training Awareness | Regular security training for the development team, with a focus on social engineering and extended risks |
V. Systemic attack surface risk
5.1 Vulnerability of the VSCode Ecology
There are deep structural problems in the current IDE development paradigm:
Although VSCode is open source, its monopoly in enterprise environments has led to emerging vendors having to fork it to enter the market quickly. However the forked model inherits all the configurations, dependencies and implicit assumptions of the original project, and the proliferation of security updates is challenged by fragmentation. This poses a long-term risk in terms of technical debt.
5.2 AI IDE's Expanding Threat Landscape
AI IDEs introduce a new attack surface compared to traditional IDEs:
LLM model poisoning:Malicious entry of prompt words may cause models to generate code containing backdoors
Context Leaks:AI models may send sensitive information to the cloud when processing code
Elevation of Privilege:AI agent modes may cross the boundaries of user-set permissions when performing tasks autonomously
5.3 Industry and Regulatory Expectations
Regulatory focus on supply chain security is at an all-time high in 2025. U.S. Cybersecurity Executive Order 14144 and the European Union's Cyber Resilience Act both impose clear requirements on the software supply chain. Against this backdrop, IDE vendors face the following pressures:
Implementation of SBOM (Software Bill of Materials) Publication Extension Dependency
Provide time-to-fix commitments (SLAs) and publicly disclose responses
Proving the security of extended markets through tripartite audits
vi. conclusions and recommendations
The breach reflects the fundamental tension between rapid innovation and security defenses for emerging AI development tools. the rapid response of Cursor set the standard for the industry, while the delays of Google and Windsurf exposed the differences in security priorities among organizations.
Key recommendations:
- Immediate action: all AI IDE users should update to the latest version (Cursor ≥ fixed version, Google Antigravity ≥ January 1 version), and Windsurf users should consider migrating to a fixed alternative or proactively limiting extensions
- Eco-Governance: The Eclipse Foundation should continue to strengthen the security mechanisms of OpenVSX and establish regular security agreements with all downstream IDE vendors.
- Technical Standards: Proposes that the OWASP and CWE communities establish a standardized detection and mitigation framework for IDE extension attacks
- Long-term investment: encouraging the integration of generative AI with development tools while establishing a corresponding security assessment system
The incident also reminded the developer community that trust should not be built on a single automated recommendation mechanism. In an era where AI-enabled tools are increasingly embedded in the development process, manual verification and multiple layers of defense remain essential.
Reference source:
BleepingComputer. “VSCode IDE forks expose users to ‘recommended extension’ attacks.” 2026/1. /5.
https://www.bleepingcomputer.com/news/security/vscode-ide-forks-expose-users-to-recommended-extension-attacks/
Codecademy. “Agentic IDE Comparison: Cursor vs Windsurf vs Antigravity.” 2025/12/29.
https://www.codecademy.com/article/agentic-ide-comparison-cursor-vs-windsurf-vs-antigravity
Veracode. “Software Supply Chain Attacks in 2025.” 2025/9/23.
Software Supply Chain Attacks in 2025: What We Learned from Gartner®
The Hacker News. “Critical Open VSX Registry Flaw Exposes Millions of Developers.” 2025/6/26.
https://thehackernews.com/2025/06/critical-open-vsx-registry-flaw-exposes.html
Silobreaker. “12 Months That Changed Supply Chain Security.” 2025/12/16.
https://www.silobreaker.com/blog/cyber-threats/supply-chain-attacks-in-2025-a-month-by-month-summary/
Security Affairs. “Taking over millions of developers exploiting an Open VSX Registry flaw.” 2025/6/26.
https://securityaffairs.com/179398/hacking/taking-over-millions-of-developers-exploiting-an-open-vsx-registry-flaw.html
OWASP. “A03 Software Supply Chain Failures - OWASP Top 10:2025.”
https://owasp.org/Top10/2025/A03_2025-Software_Supply_Chain_Failures/
Koi Security. “How We Could've Taken Over Every Developer Using a VSCode Fork.” 2025/6/25.
https://www.koi.ai/blog/marketplace-takeover-how-we-couldve-taken-over-every-developer-using-a-vscode-fork-putting-millions-at-risk
Microsoft. “Shai-Hulud 2.0: Guidance for detecting, investigating, and defending.” 2025/12/8. https://www.microsoft. com/en-us/security/blog/2025/12/09/shai-hulud-2-0-guidance-for-detecting-investigating-and-defending
Koi Security. “How We Prevented Cursor, Windsurf & Google Antigravity from Recommending Malware.” 2026/1/5.
https://www.koi.ai/blog/how-we-prevented-cursor-windsurf-google-antigravity-from-recommending-malware
Eclipse Foundation. “Vulnerability in Eclipse Open VSX Registry extension publication process.” 2025/6/26.
https://newsroom.eclipse.org/news/announcements/vulnerability-eclipse-open-vsx-marketplace-extension-publication-process
Original article by Chief Security Officer, if reproduced, please credit https://www.cncso.com/en/ai-ide-cursor-windsurf-google-antigravity-report.html



