IDEsaster: Why 100% of AI Coding Tools Have Critical Security Flaws (And What You Must Do Now)

On December 6, 2025, security researcher Ari Marzouk dropped a bombshell that sent shockwaves through the developer community:

100% of AI-powered IDEs and coding assistants tested contain critical security vulnerabilities that enable data theft and remote code execution.

Not 50%. Not 80%. Every single one.

The research, ominously named "IDEsaster," exposes over 30 separate security flaws across the tools millions of developers use daily: Cursor, GitHub Copilot, Windsurf, Claude Code, Zed, Roo Code, Junie, Cline, and more. At least 24 CVEs have been assigned, with AWS and Anthropic issuing security advisories.

This isn't a theoretical vulnerability. Attackers can:

The scariest part? The vulnerability exists in the architecture itself—not just individual bugs.

IDEs were never designed for autonomous AI agents. When these agents interact with long-standing IDE features—features that have existed for years and seemed safe—they create a new attack surface. Features like workspace configuration files, settings management, and multi-root workspaces become weapons in the wrong hands.

As Marzouk told The Hacker News: "All AI IDEs effectively ignore the base software in their threat model. They treat their features as inherently safe because they've been there for years. However, once you add AI agents that can act autonomously, the same features can be weaponized."

If you're using AI coding tools, you're affected. Here's everything you need to know about IDEsaster—and how to protect yourself.

IDEsaster isn't one vulnerability. It's a vulnerability class—a fundamental design flaw that affects every AI IDE built on top of traditional development environments like VS Code, JetBrains, and Zed.

The exploit follows a three-step pattern:

Step 1: Prompt Injection (Context Hijacking)
Attackers plant malicious instructions in places the AI reads:

When your AI assistant reads these files to understand your project, it unknowingly ingests attacker-controlled instructions.

Step 2: AI Agent Execution
The compromised AI follows the malicious instructions, believing they're legitimate commands from you. Since many AI agents are configured to auto-approve file writes within the workspace, they execute these commands without asking permission.

Step 3: IDE Feature Weaponization
The AI uses legitimate IDE features to complete the attack:

The result? Data exfiltration, credential theft, or remote code execution—without any warning or user interaction.

Earlier AI security flaws targeted individual components: a vulnerable tool, a writable configuration file, or a specific agent feature. Fix one, move on.

IDEsaster is different. It leverages the base IDE layer itself—the foundation that all AI assistants are built on. This means:

As one security researcher noted: "This is an IDE-agnostic attack chain. It works everywhere."

Here are the confirmed vulnerabilities (with CVE identifiers where assigned):

CVE-2025-49150 (Cursor)
Attackers use prompt injection to read sensitive files, then write a JSON file with a remote schema URL. When the IDE validates the JSON, it sends your data to the attacker's server.

CVE-2025-53097 (Roo Code)
Similar exfiltration through JSON schema validation.

CVE-2025-58335 (JetBrains Junie)
Reads sensitive project files and exfiltrates via external schema requests.

GitHub Copilot (no CVE assigned yet)
Same attack vector—prompt injection leads to data leakage through JSON schema requests.

Kiro.dev (no CVE assigned yet)
Vulnerable to the same exfiltration technique.

Claude Code (acknowledged with security warning)
Anthropic acknowledged the vulnerability and added warnings but hasn't fully patched it yet.

CVE-2025-53773 (GitHub Copilot)
Prompt injection edits IDE settings files to change executable paths (like php.validate.executablePath or PATH_TO_GIT) to attacker-controlled binaries.

CVE-2025-54130 (Cursor)
Modifies .vscode/settings.json to execute malicious code when the IDE launches features.

CVE-2025-53536 (Roo Code)
Changes workspace settings to redirect to attacker executables.

CVE-2025-55012 (Zed.dev)
Similar settings manipulation leading to code execution.

Claude Code (security warning issued)
Same vulnerability pattern confirmed.

CVE-2025-64660 (GitHub Copilot)
Edits multi-root workspace configuration files (.code-workspace) to override settings and achieve code execution.

CVE-2025-61590 (Cursor)
Exploits workspace settings to run arbitrary commands without user interaction.

CVE-2025-58372 (Roo Code)
Uses workspace file manipulation for remote code execution.

CVE-2025-61260 (OpenAI Codex CLI)
Command injection through MCP server entries that execute at startup without permission.

Google Antigravity (no CVE)
Indirect prompt injection using poisoned web sources to harvest credentials and exfiltrate code through browser agents.

PromptPwnd (New Vulnerability Class)
Targets AI agents connected to GitHub Actions or GitLab CI/CD pipelines, leading to repository compromise and supply chain attacks.

Attackers embed malicious prompts in files your AI reads automatically:

markdown

Your AI assistant reads this README, follows the hidden instruction (believing it's part of the project documentation), and exfiltrates your .env file containing API keys and database credentials.

You never see the hidden instruction. The AI just seems to be "understanding your project."

Model Context Protocol (MCP) servers extend AI capabilities by providing additional tools and data sources. Attackers can create malicious MCP servers that:

When your AI queries these servers for information, it receives compromised data that includes attack instructions.

Many AI assistants are configured to automatically approve file writes within your workspace without asking for permission. This is a convenience feature—you don't want to click "approve" for every small change.

But it becomes a security hole when combined with prompt injection. The AI can:

The AI thinks it's helping you. You think the AI is just working. The attacker is stealing your data.

You clone a popular open-source repository with 5,000 stars. It seems legitimate.

Hidden in a deep subdirectory is a configuration file with embedded prompt injection. You open the project in Cursor and ask the AI to "help me understand this codebase."

The AI reads the poisoned file, extracts your AWS credentials from .env, and writes them to a JSON file with a remote schema. Your credentials are now on an attacker's server.

You never knew anything happened.

You install an NPM package that includes a malicious .cursorrules file. When your AI reads project rules (which it does automatically to understand coding standards), it ingests the attack instructions.

The compromised AI modifies your .vscode/settings.json to change the Git executable path to a malicious script. Every time you commit code, the script runs, creating a persistent backdoor.

Git commands still work. You don't notice anything wrong. The backdoor remains active for months.

Your team uses AI agents for automated code review and PR labeling. An attacker submits a PR with prompt injection in the commit message or code comments.

When the AI agent analyzes the PR, it follows the malicious instructions: exfiltrating repository secrets, modifying CI/CD configuration, or creating unauthorized admin access.

The PR looks normal. The AI's suggestions seem helpful. Your entire repository is compromised.

IDEsaster exposes a fundamental truth: AI coding tools expand your attack surface in ways traditional security practices don't cover.

You need more than antivirus software. You need:

The Lovable Directory provides:

✅ Security frameworks specifically designed for AI coding tools
✅ Verified, trusted MCPs that won't compromise your environment
✅ Configuration templates with security best practices built-in
✅ Expert consultants who specialize in AI IDE security
✅ Monitoring and auditing tools for AI-generated code
✅ Community-vetted resources for secure AI development

Don't wait for a breach to take security seriously.

Secure Your AI Workflow Now →

Don't open untrusted repositories with AI assistants enabled. If you must examine suspicious code:

Treat every new repository as potentially compromised until proven otherwise.

Review every MCP server and AI extension you've installed:

Use only verified, community-trusted MCP servers. If a server's source code isn't public and auditable, don't use it.

Change your AI assistant settings to require manual approval for:

Yes, this adds friction. But that friction prevents silent attacks.

Check these files for unexpected changes:

Look for:

If you find anything unexpected, assume compromise and investigate immediately.

Use tools that:

Consider sandboxing AI agent execution so that even if compromised, the AI can't access sensitive data or execute privileged operations.

GitHub Copilot: Acknowledged vulnerabilities, patches in progress Cursor: CVEs assigned, working on fixes Anthropic (Claude Code): Security warnings issued, architectural changes planned AWS: Security advisory published for affected services Roo Code: Patches released for some vulnerabilities

These patches address specific vulnerabilities, not the underlying vulnerability class.

As Marzouk's research concludes: "This vulnerability class cannot be eliminated in the short term because current IDEs were not built under the 'Secure for AI' principle."

IDEs need to be fundamentally redesigned to safely support autonomous AI agents. Features that were safe when human-controlled become dangerous when AI-controlled.

The long-term fix requires:

These changes take years to implement across the entire IDE ecosystem.

Until then, developers must assume all AI coding tools are vulnerable.

IDEsaster isn't just about patching bugs. It's a wake-up call about how we integrate AI into critical workflows without rethinking security.

Developers trust their IDE. They've used VS Code or JetBrains for years without security incidents. Adding AI feels like adding a helpful assistant—not introducing a massive attack surface.

But AI agents fundamentally change the security model. Features designed for human control become exploitable when AI can use them autonomously.

The more autonomous AI coding tools become, the more security risks they introduce:

We wanted AI assistants that "just work" without constant approval prompts. IDEsaster shows the cost of that convenience.

AI coding tools are now part of the software supply chain. Compromising them doesn't just affect one developer—it affects:

A single compromised AI assistant becomes a supply chain attack vector affecting downstream users and customers.

IDEsaster revealed that security fundamentals don't transfer automatically to AI-augmented workflows. The tools that make developers more productive also make them more vulnerable—unless security is built in from the start.

You have two choices:

The Lovable Directory is your resource hub for secure AI coding:

🔒 Security-first AI tools vetted for production use
🛡️ Hardened configuration templates that minimize attack surface
👥 Expert security consultants specializing in AI IDE protection
📋 Compliance frameworks for enterprise AI development
🚨 Monitoring and alerting tools for AI agent behavior
✅ Verified MCP servers with transparent security audits

The IDEsaster research proves that "convenient" and "secure" aren't the same thing. Choose tools and practices that prioritize both.

Protect Your Workflow →

The IDEsaster research is a defining moment for AI-assisted development. It forces us to confront an uncomfortable truth: we deployed AI agents into critical workflows before understanding the security implications.

This isn't about fearmongering or rejecting AI coding tools. They're genuinely transformative. But transformation without security is just risk.

The developers and teams that thrive in the AI era won't be those who adopt the fastest tools—they'll be those who adopt the most secure tools and practices.

IDEsaster showed us the vulnerabilities. Now we must build the defenses.

The choice is yours: continue with vulnerable tools and hope for the best, or implement security-first AI development practices today.

Which side of that choice will you be on when the next security researcher publishes their findings?