All posts
Runtime Governance

The IDEsaster Incident: What 30+ CVEs Tell Us About Agent Environment Risk

30+ CVEs across every major AI coding assistant exposed the authorization gap at the core of autonomous agent environments. Here is what the incident tells us about runtime governance.

5 min read By DeepSweep Team

In December 2025, security researchers coordinated the disclosure of over 30 CVEs affecting every major AI coding assistant — Cursor, Claude Code, GitHub Copilot, Windsurf. One hundred percent of tested AI IDEs had critical findings.

The incident was quickly labeled "IDEsaster." The coverage focused on CVE numbers and CVSS scores. That framing missed the more important finding.

What the CVEs Actually Show

The findings fell into three classes. Rules file injection (CVE-2025-43570, CVSS 9.1): hidden instructions in .cursorrules could hijack the AI's output without any visible indication — exfiltrate credentials, inject backdoors, modify build configurations. The agent had no awareness of what it was being instructed to do.

Daemon authentication bypass (CVE-2025-52882, CVSS 9.3): Claude Code runs a local daemon that accepts unauthenticated WebSocket connections from any local process. Any application on the developer's machine could inject commands into an active session. No authentication boundary, no audit trail.

MCP server poisoning (CVE-2025-54135, CVE-2025-53109): 43% of MCP servers analyzed contained injection flaws allowing arbitrary tool execution. The Model Context Protocol gave agents the ability to reach external tools and data sources — but without authorization controls on what those tools could do or who could instruct them.

The Gap the CVEs Expose

Each finding maps to the same underlying condition: the agent had a capability — write to the filesystem, execute a shell command, call an MCP tool — but no authorization boundary governed when that capability could be exercised, by whom, and under what conditions.

The CVE framing treats this as a patching problem. It is not. Patching the specific WebSocket authentication issue does not eliminate the underlying authorization gap. A patched daemon with no authorization policy still has no boundary on what an agent can be instructed to do once it connects.

What the incident disclosed is the absence of a capability profile for agent environments — a clear record of what each agent can do, what it has been authorized to do, and what the gap between those two sets is.

What a Governed Agent Environment Looks Like

The gap is closed by four properties, applied in order. Capability detection: enumerate what the agent can actually do — repository write, shell execution, MCP tool access, secret access, deploy. Authorization scope: define what the agent is authorized to do per principal, per action, per resource. The gap between capability and authorization is the authorization gap — a finding, not a vulnerability. Runtime enforcement: enforce authorization boundaries before the action crosses the boundary. Audit trail: record every enforcement decision in a tamper-evident, hash-linked audit log.

For Teams Using AI Coding Assistants

Cursor's response to the disclosure acknowledged the CVEs and stated: "This risk falls under users' responsibility to review and validate code and configuration from untrusted sources." That is the correct position for a tool vendor to take. Your agent environment is your responsibility. The question is whether you have the tooling to understand it.

Start with the free tooling. Validate the configuration files that steer your coding agents with: pip install deepsweep-ai && deepsweep validate . — or run the free Agent Environment Review at https://deepsweep.ai/review

The review's output is a capability profile, authorization gaps, recommended controls. Not a vulnerability report — a governance artifact that answers the question every team running AI coding assistants should be able to answer: what can this agent do, what has it been authorized to do, and where are the gaps?

The Forward View

The IDEsaster CVEs are patched. The authorization gap they exposed is not — it is structural to how agent environments are built today. As agents acquire more capabilities, the gap widens unless authorization governance keeps pace.

The regulatory direction is the same. The EU AI Act and NIST AI RMF both treat authorization and audit as baseline requirements for autonomous systems in high-risk contexts. The question is not whether to implement authorization governance — it is whether to do it before or after an incident.

DeepSweep exists to make before the easier choice. Review your agent environment at deepsweep.ai/review

See where your AI-generated code stands.

Run a free Agent Environment Review — local, no code upload. Catch what your AI agent got wrong before it reaches a pull request.

Review my agent environment — free