Cursor attacks expose the gap between CVEs and real damage

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Adversa AI's blog post: Cursor security incidents split into CVE-tracked defects and real harm that arrived through trusted extensions, repository content and agent inputs, leaving a governance gap that scanners alone do not cover.

Why it matters: IAM, PAM and NHI teams need to treat coding agents as privileged execution surfaces, because the most damaging paths often sit outside traditional vulnerability tracking and inside the trust boundary around the agent.

By the numbers:

• Adversa AI says 10 documented attacks on Cursor occurred between August 2025 and October 2026.
• Adversa AI says the trojanized Claude Code extension was served for about 11 hours on October 29, 2026.
• Adversa AI says the Agentjacking research reported an 85% success rate across Claude Code, Cursor and Codex.

Context

Cursor-style coding agents fail when teams assume the editor boundary is a security boundary. In practice, the agent trusts extensions, repository files, MCP output and links that a developer would normally treat as untrusted input, so the governance problem is not only code defects but also the policy around what the agent may execute.

That makes this a non-human identity problem as much as an application security problem. The agent behaves like a privileged runtime actor, yet its permissions are often inherited from the human developer or the surrounding workspace, which creates a wide gap between nominal control and actual blast radius.

The result is a control-plane issue: if the surrounding harness can be manipulated, the agent can be made to act on malicious instructions even when the underlying binary is patched.

Key questions

Q: How should teams govern third-party extensions in AI-enabled developer environments?

A: Use the same discipline applied to other third-party access paths: inventory what is installed, restrict what each component can do, review updates before rollout, and revoke anything that expands scope without a clear business need. The goal is to keep extension authority narrow and observable.

Q: Why do coding agents amplify workspace security risks?

A: Coding agents amplify workspace security risks because they can read files, follow instructions buried in content, and act on that content with tool or shell access across the control boundary between untrusted workspace data and privileged execution. That can turn a malicious prompt, script, or dependency into code execution, secret exposure, or unintended commits if command authority is not tightly constrained.

Q: What should teams do first when a coding agent can run commands from workspace content?

A: Teams should first separate untrusted workspace content from execution paths, then require a review from execution before any command runs. That means using allowlists, human approval gates for high-risk actions, and sandboxed environments with no direct access to secrets, so files and prompts cannot trigger arbitrary shell commands or state-changing tools automatically.

Q: How do you reduce the blast radius of a compromised developer token?

A: Reduce the blast radius by issuing the developer token with the narrowest possible scope, short expiry, audience restriction, and environment binding. Prefer per-service or per-workload tokens over shared developer tokens, and revoke or rotate immediately after exposure. Map token ownership to a named person or team so access can be removed fast.

Technical breakdown

Why trusted editor surfaces become an attack path

Cursor accepts content from several sources that are not inherently trustworthy: marketplace extensions, project files, MCP responses, repository rules and deeplinks. The technical issue is not just that these inputs exist, but that they are often executed or interpreted in a context with broad developer permissions. That collapses the usual separation between data and instruction. Once the agent is willing to act on repository content or extension code without a strong trust boundary, the attack surface shifts from the application binary to everything the workspace can import, read or render. See the AI Coding Agents Security Guide.

Practical implication: Treat workspace content, extension payloads and MCP inputs as untrusted until explicitly governed.

How sandbox and prompt-path weaknesses turn into execution

Several Cursor cases show the same mechanism: a benign-looking prompt, task file or dialog becomes a command execution path because the agent or its helper accepts attacker-controlled text as if it were intended instruction. In those cases, the problem is not simple malware delivery. It is the failure to preserve a reliable boundary between review, approval and execution. If a task file runs on folder open, or an install dialog hides the real command, the user is no longer evaluating the actual action that will happen. See the AI IDE and Coding Agent Security Guide.

Practical implication: Inspect agent approval flows for hidden arguments, auto-run behaviour and any path that converts text into execution.

Why the marketplace compromise mattered more than the CVE count

A trojanized extension distributed through a curated marketplace demonstrates that publisher identity and channel reputation are not enough on their own. The malicious build used the correct name and an expected distribution path, so ordinary trust checks passed while the payload still loaded with editor permissions. That is a software supply chain problem, but in agent environments it also becomes an identity problem, because the extension inherits the trust of the developer session and the workspace. A compromised package can therefore act with more privilege than its apparent provenance deserves.

Practical implication: Control extension provenance, versioning and installation policy as part of software supply chain governance.

Threat narrative

Attacker objective: The attacker aims to turn the coding agent’s trusted execution context into a launch point for command execution, persistence, credential theft or destructive actions.

1. Entry occurred through trusted channels such as a marketplace extension, repository file, deeplink or MCP response rather than through a traditional exploit of the editor core.
2. Credential and command exposure followed when the agent accepted attacker-controlled content as trusted workspace input or executable instruction.
3. Escalation happened when that content inherited the developer session or workspace permissions and triggered commands, persistence or destructive actions without a separate security gate.
4. Impact ranged from data deletion and credential theft to persistence, hidden shells and malicious code execution on developer machines.

Breaches seen in the wild

• Anthropic GTG-1002 AI espionage campaign: A state-sponsored group ran Claude Code agents to attack about 30 organisations, harvesting and reusing credentials at machine speed.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Trust boundaries around coding agents are now the real control surface: The decisive failure is not just a vulnerable binary, but the assumption that marketplace content, repository files and MCP output can be safely interpreted inside the agent runtime. That assumption breaks when attacker-controlled text is allowed to become instruction. Governance has to move from patch-only thinking to boundary control over what the agent may consume and execute.

Workspace trust is an identity control, not a convenience setting: When a project opens with trust disabled by default, or when repository content can trigger actions without a durable trust decision, the workspace itself is effectively acting as an identity broker. That means the access decision is being made too late, after content has already entered the execution path. Practitioners should treat this as a governance gap in the trust chain, not just a user preference issue.

Software supply chain controls now extend to agent behaviour: A malicious extension is not only a bad package, it is a privileged behavioural implant inside the developer session. AI coding agents security becomes the right framing because the risk spans extension provenance, rule files, MCP installs and runtime actions. The practitioner conclusion is simple: if the agent can be made to trust the wrong thing, every downstream control is operating after the fact.

Runtime containment has to sit between instruction and action: The damaged cases in this set are not all exploitation of the same defect, but they do share one pattern: the agent is allowed to act before a human or policy layer can inspect the consequences. That creates identity blast radius inside the workspace. The right governing question is where action can still be blocked, not whether the input was eventually detected as bad.

Confirmed harm without a CVE is a governance signal, not an anomaly: The clean split between published defects and real-world damage shows that vulnerability management alone will undercount the operational risk. A control programme that waits for a CVE to appear will miss marketplace compromise, rule poisoning and over-scoped tokens. The practitioner implication is to govern the trust domain around the agent as an asset in its own right.

From our research library:

• Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
• Read next: AI Coding Agents Security Guide

What this signals

Identity blast radius is now a workspace design issue: When an AI coding agent can inherit the wrong trust relationship, the surrounding repository and extension layer become part of the identity problem. Security teams should watch for policy decisions that still assume a developer session is the smallest meaningful trust unit, because these incidents show that the workspace itself is now an execution principal.

Agent governance has to move from defect response to boundary enforcement: The next phase of control maturity is not another vulnerability feed. It is enforcing policy at the moment content becomes action, especially for extensions, task files, MCP installs and deeplinks. That is where the safest teams will distinguish harmless data from executable instruction.

For practitioners

• Turn on workspace trust across managed devices Disable automatic trust for unvetted repositories so folder-open behaviour cannot trigger tasks or helper processes before review.
• Govern extensions as software supply chain assets Inventory installed extensions, pin versions, restrict marketplace installs and treat signed publisher names as insufficient proof of safety.
• Block agent actions until runtime policy approves them Place a policy layer between agent instruction and command execution so destructive file operations, persistence steps and network calls can be stopped before they run.
• Review repository rules and task files as executable content Scan .cursor, .vscode, hooks and workspace configuration for always-on rules, auto-run tasks and command strings that an attacker could plant or alter.
• Scope tokens and connector access to the narrowest job Remove broad API tokens from workspaces and separate short-lived job credentials from accounts that can delete data or reach production systems.

Key takeaways

• Cursor incidents show that harmful behaviour often enters through trusted workspace channels rather than through a classic product vulnerability.
• The evidence splits between CVE-tracked defects and confirmed harm without CVEs, which means scanner coverage alone will miss part of the risk.
• The strongest controls are workspace trust, extension governance and a runtime policy layer that can stop agent actions before they execute.

Related NHI Mgmt Group resources: AI Coding Agents Security Guide · Zero Trust for AI Agents · Agentic AI Security Guide

Key terms

• Workspace Trust: Workspace Trust is a policy boundary that decides whether a project folder is treated as safe enough to run tasks, helpers and other active content. In coding-agent environments, it is less a convenience feature than a control on whether untrusted repository content can influence execution.
• MCP: Model Context Protocol, an open way for AI agents to connect to tools and data sources. It improves interoperability, but it also introduces a shared integration layer that must be governed carefully because the protocol can widen access across many systems at once.
• Software Supply Chain: A software supply chain is the set of tools, identities, dependencies, and processes that turn source code into deployed software. Because it relies on automation and privileged machine identities, it becomes a governance problem when access, signing, and deployment controls are too broad.
• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.