TL;DR: Repello AI documents 11+ Cursor CVEs and named vulnerabilities across 2025 and 2026, spanning sandbox escape, indirect prompt injection into file writes, MCP trust bypasses, and supply-chain exposure through OpenVSX and Chromium lag. The record shows that enterprise deployment depends on version pinning, MCP governance, and auditability that reconstructs agent activity, not just tenant admin events.
At a glance
What this is: Repello AI’s analysis says Cursor’s security history spans 11+ CVEs and named issues that cluster around pre-trust execution, prompt injection into file writes, sandbox escape, and supply-chain exposure.
Why it matters: For IAM and security teams, the lesson is that workstation agents need identity and execution controls as much as they need patching, because trust-on-first-use and weak observability create governance blind spots.
By the numbers:
- Cursor crossed one million daily active developers in 2025 and has continued to grow through 2026.
Context
Cursor’s security record is best understood as a governance problem, not just a patching problem. The issue is that a workstation agent can write to security-critical files, ingest untrusted content, and then use those actions to cross trust boundaries inside the developer environment.
The central control gap is auditability. If an organisation cannot reconstruct which prompts ran, which files the agent read, or which MCP tools were invoked, then incident response and access governance both lose the evidence they need to work.
Key questions
Q: What breaks when a workstation agent can write to trusted config files?
A: The trust model breaks because a file that was approved as benign can later become an execution path. That lets prompt injection or local manipulation turn into code execution, token exposure, or persistent privilege changes. Security teams should assume any agent-writable security file is a privileged control surface, not ordinary workspace data.
Q: Why do workstation agents create audit and accountability gaps for IAM teams?
A: Because the platform often logs admin actions but not the underlying AI actions that produced them. Without prompt, tool, and file-access evidence, teams cannot tie a result to a user, an agent step, or a specific trust decision. That weakens investigation, recertification, and blast-radius assessment.
Technical breakdown
How pre-trust execution turns folder trust into lasting risk
Cursor’s repeated weakness is not any single bug, but the Trust-On-First-Use pattern behind folder trust, extension trust, and project-local configuration. Once a folder, namespace, or file path is trusted, later actions can inherit that trust without fresh scrutiny. That makes the approval boundary persistent even when the content behind it changes. In identity terms, the agent’s execution context is being authorised by name and location rather than by the content or command body actually being executed. See the Agentic AI Security Guide.
Practical implication: Treat trust-on-first-use as an attack surface and remove persistent approval where the underlying object can change after approval.
Why indirect prompt injection becomes file-write execution
The CurXecute class shows a common agentic pattern: untrusted text enters the model context, the agent decides to write a security-sensitive file, and the next runtime step turns that file write into execution or privilege change. The dangerous part is the boundary crossing, not the prompt itself. Files such as .cursor/mcp.json, .git/config, and .cursorignore are not ordinary workspace artefacts when the agent can use them to change later execution paths. That makes them privileged surfaces, even if they look like local config. See the Prompt Injection Guide.
Practical implication: Protect any file path that can alter future execution, because the write step is where prompt injection becomes operational compromise.
What supply-chain exposure looks like in an AI developer stack
Cursor’s OpenVSX namespace squatting and Chromium lag show that workstation-agent risk extends beyond the agent binary itself. The extension registry, bundled browser components, and other upstream dependencies all create a chain of trust that can be attacked or simply decay over time. In practice, the issue is not only malicious packages, but also delay, drift, and unverified recommendations entering the developer workflow as if they were safe defaults. See the AI Supply Chain Security and AI-BOM Guide.
Practical implication: Govern the full software and extension supply chain around the agent, not just the agent process itself.
Threat narrative
Attacker objective: The attacker wants to convert a benign-looking developer interaction into persistent execution, credential exposure, or code execution inside the workstation agent environment.
- Entry begins when an attacker reaches the agent through untrusted workspace content, a spoofed extension flow, or a trusted-once configuration path that can later change.
- Credential and execution access follow when the agent writes to privileged files such as .cursor/mcp.json, .git/config, or .cursorignore, or when a malicious extension gains execution inside the developer workflow.
- Escalation occurs when those writes trigger out-of-sandbox actions, automatic MCP execution, or code execution through a browser or desktop side channel.
- Impact is full workstation-agent compromise, including arbitrary file access, command execution, credential exposure, or supply-chain persistence through trusted extensions and bundled dependencies.
Breaches seen in the wild
- EchoLeak (Microsoft 365 Copilot) 2025: A crafted email could make Microsoft 365 Copilot leak data from its context with no click, a zero-click prompt injection fixed as CVE-2025-32711.
- ForcedLeak (Salesforce Agentforce) 2025: A critical Agentforce flaw let attackers steer an AI agent through a Web-to-Lead form to leak CRM data via an expired allowlisted domain.
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
Cursor’s record shows that trust-on-first-use is no longer a safe governance assumption for workstation agents: once a folder, namespace, or project file is approved, later content can change underneath the approval. That assumption was designed for static software packaging and stable admin-reviewed artefacts. It fails when the agent can rewrite the trusted object after approval, so the implication is not just stronger approval steps but a rethink of what trust is actually bound to.
AI-activity audit gaps are now an identity problem, not just an observability problem: tenant admin logs do not tell a security team which prompts ran, which files were read, or which tools were invoked. That means the organisation can have a controlled admin plane and still have an ungoverned action plane. The practitioner conclusion is that agent identity must be paired with action evidence, or incident reconstruction will remain incomplete.
The named concept here is identity blast radius: a workstation agent can expand one accepted trust decision into file writes, tool execution, and side-channel access across multiple surfaces. The practical significance is that a single trust boundary now governs code, configuration, and identity flows at once. Teams should treat every agent approval as a blast-radius decision, not a convenience setting.
Supply-chain control for agents has to include the registries and runtimes around the model, not only the model itself: OpenVSX, Chromium, MCP installers, and recommended-extension lists all sit inside the same trust chain. That chain is only as strong as the least-governed upstream dependency. Practitioners should assume the agent runtime will be targeted through adjacent software surfaces first.
Cursor also shows why NHI governance is expanding into AI-adjacent developer tooling: the practical control question is no longer whether the agent is productive, but whether its identities, tokens, and execution paths are separately governable from the developer’s own session. When those boundaries blur, entitlement review and incident response both lose precision. The right response is to govern the agent as its own access domain.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Read next: Agentic AI Security Guide
What this signals
Identity blast radius: workstation agents collapse approval, execution, and file access into one workflow boundary. That changes how teams should think about least privilege, because the dangerous unit is no longer the user session alone but the agent plus its writable surfaces and inherited trust.
The next governance step is to treat agent deployments as a separate access domain with their own logging, token scoping, and trust rules. Without that separation, the organisation may believe it has controlled the IDE while leaving the agent’s runtime effectively unmanaged.
Teams that already govern secrets, workload identity, and third-party access can reuse the same discipline here, but only if they move from admin logging to action-level evidence. That is what turns agent oversight from policy into something operationally defensible.
For practitioners
- Pin the fleet to a known-safe Cursor version Force-update to Cursor 2.5 or later through MDM so the known sandbox-escape and MCP classes are removed from the estate.
- Disable project-local MCP trust by default Block or auto-deny changes to project-scoped MCP configuration and route any approved MCP use through centrally managed allowlists.
- Force Workspace Trust and lock extension sources Require Workspace Trust, allowlist OpenVSX publishers, and reject unpinned recommended extensions so the agent cannot inherit trust from a mutable namespace.
- Scope agent tokens to the narrowest possible workflow Separate triage, review, and build identities so a prompt-driven agent never holds a high-scope token that can alter code, branches, or release artefacts.
- Add endpoint-level telemetry for agent actions Use host and process monitoring to capture prompt execution, file reads, and MCP invocation because the platform logs do not provide that detail.
Key takeaways
- Cursor’s CVE history shows that workstation agents can fail through trust decisions, config writes, and upstream dependencies, not only through the model itself.
- The most important evidence in the article is the audit gap: admin logs exist, but detailed AI activity logs do not, which weakens reconstruction and accountability.
- Enterprise teams need version pinning, MCP governance, and host-level telemetry if they want to deploy agentic developer tools without losing control of execution paths.
Related NHI Mgmt Group resources: Agentic AI Security Guide · AI Supply Chain Security and AI-BOM Guide · Prompt Injection Guide · CI/CD Pipeline Identity Security Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATT&CK define the specific risk controls and attack patterns relevant to this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | The article centres on agent-driven file writes and execution through attacker-influenced tools and config paths. |
| ASI03 — Identity & Privilege Abuse | The trust boundary failures let agent actions inherit more privilege than the user intended. | |
| Recommendation — Constrain agent tool use to approved actions and isolate writable execution surfaces from prompt-influenced flows. Separate agent identities from user identities and limit privilege inheritance across agent workflows. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article explicitly discusses reads of credentials and API keys that should have been excluded by ignore rules. |
| NHI-05 — Overprivileged NHI | The main risk is that the agent can execute with broader access than the workflow actually needs. | |
| NHI-08 — Environment Isolation | The workstation agent shares trust and execution paths across workspace, extensions, and runtime surfaces. | |
| Recommendation — Scan agent-writable paths for exposed secrets and prevent the agent from reaching ignored credential files. Review agent permissions against task scope and remove any standing access that exceeds the workflow boundary. Isolate trusted execution contexts so one workspace or extension cannot influence another agent boundary. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | Several issues lead from file access or prompt injection to credential exposure and broader execution movement. |
| Recommendation — Map the agent attack path to credential-access and lateral-movement tactics to prioritise detection and containment. | ||
Key terms
- Trust On First Use: Trust On First Use is a model where an initial connection or enrollment step is accepted first, then future trust is anchored to what was established during that setup. In identity and network controls, it reduces setup friction while making later verification dependent on stored keys and verified state.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
- Agent Activity Logging: Telemetry that records what an AI or workstation agent actually did, not just which human or admin account configured it. This matters because a deployment can have strong administrative logs and still lack the evidence needed to reconstruct prompt use, file access, and tool invocation.
- Project-Scoped Configuration: Project-scoped configuration is settings data stored inside a repository and loaded by a tool when that project opens. In coding agents, this matters because a repository can influence startup behavior, permissions, and MCP server registration, which makes malicious config files a direct attack surface rather than simple metadata.
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.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org