37 Vulnerabilities in AI Coding Tools — Zero-Click RCE in Your IDE

37 Vulnerabilities, 15+ Vendors

Security researchers have uncovered 37 distinct vulnerabilities across more than 15 AI-powered IDE vendors, including GitHub Copilot, Cursor, Claude Code, Windsurf, Continue, and several others. The findings span the full severity spectrum, but the most alarming class involves zero-click remote code execution through a mechanism most developers have never audited: the Model Context Protocol (MCP) tool autoload system.

This is not a theoretical exercise. The research, published in early 2026 as part of the [un]prompted security initiative, includes working proof-of-concept exploits that demonstrate full developer machine compromise without any user interaction beyond opening a project directory. No clicking "approve." No running a suspicious command. Just opening a folder in your AI-enabled IDE.

The affected tools include both commercial products and open-source projects. Some vendors patched within days of disclosure. Others took weeks. A handful of the vulnerabilities remain unpatched at the time of writing, which is why this article focuses on the attack patterns and defenses rather than specific exploit chains.

What makes this research significant is not just the vulnerability count. It is the realization that an entirely new attack surface has emerged in developer tooling, and most organizations have zero visibility into it.

The MCP Attack Surface

To understand why these vulnerabilities are so dangerous, you need to understand what the Model Context Protocol is and how AI IDEs use it.

MCP is an open protocol that allows AI coding assistants to connect to external tools and data sources. Think of it as a plugin system for AI agents. An MCP server exposes capabilities — reading databases, querying APIs, running shell commands, accessing file systems — and the AI agent calls those capabilities as needed to complete tasks.

The protocol itself is straightforward: JSON-RPC over stdio or HTTP. The problem is not the protocol. The problem is how AI IDEs discover and load MCP servers.

Autoload: The Silent Killer

Many AI IDEs support MCP configuration files that live inside a project directory. When you open a project, the IDE reads these configuration files and automatically connects to the MCP servers they define. In some implementations, this happens before the user sees any prompt or approval dialog. The tools become available to the AI agent immediately.

Here is where it gets dangerous. An attacker who can place or modify an MCP configuration file in a project repository gains the ability to:

• Register a malicious MCP server that the IDE connects to automatically on project open
• Expose tools to the AI agent that execute arbitrary commands on the developer's machine
• Inject instructions through tool descriptions that manipulate the AI agent's behavior
• Exfiltrate data by having the AI agent read files, environment variables, or credentials and send them to an attacker-controlled endpoint

The zero-click RCE variant works like this: a malicious .mcp.json or equivalent configuration file is committed to a repository. A developer clones the repo and opens it in their AI IDE. The IDE autoloads the MCP configuration, connects to the attacker's server (or a local server spawned from the config), and the AI agent now has access to tools that execute shell commands. If the tool descriptions contain crafted instructions — a form of prompt injection — the agent may execute those commands without any user-visible confirmation.

The result: a reverse shell on the developer's machine, triggered by nothing more than opening a project.

Tool Description Injection

A subtler variant exploits how AI agents interpret tool descriptions. MCP tool definitions include a human-readable description field that tells the AI agent what the tool does and when to use it. Attackers can embed hidden instructions in these descriptions — telling the agent to always call the tool first, to pass specific arguments, or to ignore user instructions.

This is prompt injection applied to the tool layer. The AI agent trusts the tool descriptions it receives over MCP because they are treated as system-level context, not user input. That trust boundary violation is the root cause of multiple vulnerabilities in the research.

Why This Matters More Than Typical Software Vulns

A vulnerability in a text editor is concerning. A vulnerability in an AI-powered IDE is catastrophic. The difference comes down to what these tools can access and do.

Traditional IDEs display code. AI-powered IDEs execute it. They read and write files across your entire project (and sometimes beyond). They run terminal commands. They access environment variables, which often contain API keys, database credentials, and cloud provider tokens. They interact with version control systems. Some can make HTTP requests, query databases, and interact with cloud services directly.

A compromised AI IDE gives an attacker the same access as the developer sitting at the keyboard. That typically includes:

• Source code for every project on the machine
• Git credentials (SSH keys, personal access tokens) that provide write access to repositories
• Cloud credentials (AWS keys, GCP service accounts, Azure tokens) stored in environment variables or config files
• Database connection strings with production credentials
• Internal network access if the developer is on a VPN
• Package signing keys used to publish libraries
• CI/CD tokens that can trigger deployments

This is not hypothetical escalation. Developers routinely have the keys to the kingdom. Compromising a single developer machine through their AI coding assistant can provide initial access to an organization's entire software supply chain.

Compare this to a typical web application vulnerability. An XSS bug might steal a session cookie. An SSRF might read cloud metadata. Those are serious. But a zero-click RCE in a developer's IDE can compromise every system that developer has access to — which in many organizations includes production infrastructure, customer data, and proprietary source code.

The Supply Chain Angle

The MCP autoload attack vector is fundamentally a supply chain problem, and it follows patterns that security teams should recognize from previous supply chain incidents.

Malicious MCP Servers

MCP servers can be distributed as npm packages, Python packages, or standalone binaries. The same supply chain risks that apply to any dependency apply here — typosquatting, account takeover of popular packages, and compromised maintainers. The difference is that an MCP server has explicit permission to execute commands and access the file system. A malicious npm package has to find a way to run code during installation. A malicious MCP server is invited to run code by the AI agent.

Poisoned Project Configurations

MCP configuration files in project repositories create a new vector for repository poisoning. A compromised contributor, a malicious pull request, or even a poorly reviewed merge can introduce an MCP configuration that targets every developer who clones the repository. Unlike a malicious build script that might be caught by CI/CD security scanning, MCP configuration files are JSON — they look benign to most static analysis tools.

Compromised Extensions and Plugins

AI IDE extensions that add MCP integrations represent another supply chain surface. Extension marketplaces for VS Code, JetBrains, and other platforms have their own trust models, but those models were not designed for extensions that grant AI agents the ability to execute arbitrary code. An extension that adds a "helpful" MCP integration could silently register additional tools that exfiltrate data or establish persistence.

The pattern here mirrors what we saw with the OWASP LLM Top 10: traditional security controls were not designed for the trust relationships that AI systems create. When your IDE's AI agent trusts a tool definition it loaded from a config file in a git repository, you have an implicit trust chain from "random code on the internet" to "execute commands on my machine." That trust chain needs to be broken.

How to Protect Yourself

Whether you are an individual developer or part of a team, there are concrete steps you can take right now to reduce your exposure to MCP-based attacks.

1. Audit Your MCP Configurations

Check every project you work on for MCP configuration files. Common filenames include .mcp.json, mcp.config.json, .cursor/mcp.json, and .claude/mcp_servers.json. Know what MCP servers are configured, where they connect to, and what capabilities they expose. If you did not add a configuration file, treat it as suspicious.

2. Disable MCP Autoload

If your AI IDE supports it, disable automatic loading of project-level MCP configurations. Require explicit approval before any MCP server is connected. Some tools now default to requiring user confirmation — make sure you are on a version that does.

3. Review Tool Permissions

When you do approve an MCP server, review the tools it exposes. Be especially cautious of tools that can execute shell commands, read arbitrary files, make network requests, or access environment variables. A legitimate code formatting tool should not need shell access.

4. Use Sandboxed Environments

Run your AI IDE in a sandboxed environment when working with untrusted code. Containers, virtual machines, or tools like macOS Sandbox and Linux namespaces can limit what a compromised AI agent can access. At minimum, avoid having production credentials in environment variables on machines where you open untrusted repositories.

5. Keep Your Tools Updated

Most vendors patched their MCP autoload vulnerabilities quickly after disclosure. If you are running an older version of your AI coding assistant, you may still be vulnerable. Update aggressively.

6. Treat MCP Configs Like Executable Code

Add MCP configuration files to your code review checklist. Any PR that adds or modifies an MCP configuration should receive the same scrutiny as a change to a CI/CD pipeline or a Dockerfile. These files control what code runs on developer machines — they deserve that level of attention.

Developer Security Checklist

• Audit all MCP configuration files in your projects today
• Update your AI IDE to the latest version
• Disable autoload for project-level MCP servers
• Remove production credentials from your development environment variables
• Use a dedicated machine or VM for working with untrusted repositories
• Add .mcp.json and equivalent files to your .gitignore for projects that do not need them
• Review MCP tool descriptions for suspicious instructions before approving

What Security Teams Should Do

If your organization allows developers to use AI coding tools — and most do, whether officially or not — this research demands a policy response. Here is a practical framework.

1. Build an AI Tool Inventory

You cannot secure what you cannot see. Survey your development teams to understand which AI coding tools are in use. Include IDE extensions, CLI tools, and any MCP server configurations. Many organizations will be surprised by the breadth of AI tool adoption — developers adopt these tools faster than security teams can evaluate them.

2. Establish an Approved Tool List

Publish a list of AI coding tools that your security team has evaluated and approved. Include specific version requirements and configuration guidance. For each approved tool, document which MCP capabilities are permitted and which are restricted. This gives developers a clear path to using AI tools safely rather than forcing them to use unapproved tools in the shadows.

3. Monitor for Unauthorized MCP Connections

MCP servers communicate over stdio or HTTP. Endpoint detection and response (EDR) tools can be configured to alert on unexpected outbound connections from IDE processes, or on IDE processes spawning unexpected child processes. Network monitoring can detect connections to unknown MCP server endpoints.

4. Scan Repositories for MCP Configurations

Add scanning rules to your CI/CD pipeline that flag MCP configuration files in pull requests. Treat any new MCP configuration as a security-relevant change that requires approval from the security team or a designated reviewer. This is similar to how many organizations already gate changes to .github/workflows/ or Dockerfile files.

5. Train Developers on MCP Risks

Most developers do not know what MCP is, let alone that it can be exploited for remote code execution. Include MCP security in your security awareness training. Focus on practical scenarios: what happens when you clone a repo with a malicious MCP config, how to recognize suspicious tool descriptions, and how to report potential MCP-based attacks.

6. Update Your Incident Response Plan

Your IR playbooks should account for developer machine compromise via AI tooling. Key questions to answer: How do you detect if an MCP-based attack has occurred? What is the blast radius of a compromised developer workstation? How do you rotate credentials that may have been exposed through environment variables? If you have an existing incident response framework, extend it to cover this attack surface.

Security Team Policy Checklist

• Complete AI coding tool inventory across all development teams
• Publish approved tool list with version and configuration requirements
• Add MCP configuration file scanning to CI/CD pipelines
• Configure EDR alerts for unexpected IDE child processes and outbound connections
• Include MCP security in developer security awareness training
• Update incident response playbooks for AI tool compromise scenarios
• Establish a review and approval process for new MCP server integrations
• Conduct quarterly audits of MCP configurations across all repositories

The Bigger Picture

The 37 vulnerabilities disclosed in this research are early findings in what will be an ongoing area of security research. AI coding tools are evolving rapidly. New capabilities are being added monthly — deeper file system access, cloud service integrations, autonomous code review, automated deployment. Each new capability expands the attack surface.

The security community is catching up. Vendors are adding permission models, sandboxing, and explicit consent requirements. But the fundamental tension remains: AI coding tools are powerful precisely because they have broad access to developer environments. Restricting that access reduces their utility. Finding the right balance between capability and security will define this tool category for years to come.

For now, the actionable takeaway is simple. Treat your AI coding tools as privileged software that has access to your most sensitive assets. Audit their configurations. Restrict their permissions. Monitor their behavior. And update them relentlessly.

The developers who do this will be fine. The ones who ignore it are running a reverse shell they do not know about.

For more on how AI systems can be manipulated, read our guide on prompt injection attacks and the OWASP LLM Top 10.