Cursor open-repo RCE exposes AI code editor trust gaps

At a glance

What this is: This is a report on a Cursor open-repo remote code execution issue where malicious repo contents can execute code on folder open without a trust prompt.

Why it matters: It matters because developer IDEs often hold cloud keys, tokens, and SaaS sessions, so a repo-opening event can become an identity and secrets exposure path before standard controls engage.

Context

Cursor’s default trust posture allows project content to influence execution as soon as a folder is opened. In practical terms, that means the IDE can turn a repository into an execution surface before the developer makes an explicit trust decision, which is a problem for both human identity sessions and the non-human identities reachable from that workstation.

The governance gap is not just code execution, but the collapse of the assumption that a repo must be actively trusted before it can run anything. For IAM and NHI teams, the important question is how much privileged access a developer laptop can expose the moment tooling evaluates project metadata rather than user intent.

Key questions

Q: What breaks when folder-open tasks are allowed to run in an untrusted code editor?

A: The trust boundary breaks because repository metadata can trigger execution before the user has decided the workspace is safe. That turns a file-browsing action into a session-level risk, exposing local secrets, authenticated sessions, and connected development tools to code that should never have run automatically.

Q: Why do developer repositories create identity risk for security teams?

A: Because they often carry the same access authority as the user who opens them. If a repository can trigger scripts, read environment variables, or reach cloud resources, it is acting like a non-human identity with delegated authority. That makes repository trust, token scope, and local execution policy part of the identity model.

Q: What are the signs that an IDE trust control is failing?

A: Unexpected shells, outbound network requests, or file changes immediately after opening a project are strong indicators that automatic execution is occurring. Another sign is finding .vscode/tasks.json entries with folder-open triggers in repositories that are not supposed to run anything on open.

Q: Should teams open unknown repositories in a normal developer workspace?

A: No. Unknown repositories should be treated like untrusted execution inputs, not passive documents. Use a viewer-only environment, disposable VM, or container so the repository cannot reach stored credentials, browser sessions, or connected cloud tools before trust is established.

Technical breakdown

How folder-open tasks turn repository content into execution

Cursor follows VS Code-style task definitions, including runOptions.runOn: "folderOpen". When Workspace Trust is disabled, a repository can embed instructions in .vscode/tasks.json that execute as soon as the folder is opened, without a separate consent step. The issue is not that tasks exist, but that the trust gate is absent at the exact moment the editor processes untrusted project metadata. That makes the IDE itself part of the attack surface. In an environment where developers routinely open external or cloned repositories, this creates a low-friction execution path that behaves more like implicit code loading than normal file viewing.

Practical implication: block automatic task execution until trust is explicitly established for each workspace.

Why developer sessions become an identity and secrets target

A developer workstation is usually not a low-value endpoint. It often contains cloud credentials, personal access tokens, API keys, browser sessions, and access to CI/CD systems. Once malicious code runs in the editor context, it can read local secrets, alter files, or initiate network calls using the developer’s own authenticated session. That is why this is not just an IDE issue. It is an identity issue, because the attacker is trying to inherit the session’s trust and the privileges already present on the machine. The same pattern can also bridge into NHI exposure when workstation access reaches automation systems or service credentials.

Practical implication: treat IDE execution context as privileged access and restrict what that context can reach.

Why default trust settings matter more than user awareness

Security guidance often assumes the user will notice a risky action and decide whether to proceed. Here, the default configuration reverses that expectation by allowing automation unless trust is manually enabled. That is a governance failure because it makes safe behaviour optional and unsafe behaviour convenient. In effect, the control boundary moves from explicit approval to ambient execution. For identity programmes, this is the same class of problem seen when standing privilege is easier to use than just-in-time access. The control only works if the safe path is the default path.

Practical implication: make trust prompts and task controls the enforced baseline, not an optional hardening step.

Threat narrative

Attacker objective: The attacker wants to convert a routine repository open into execution in the developer’s trusted session, then steal credentials or pivot into downstream systems.

1. Entry occurs when a user opens a malicious repository in Cursor and the folder-open task definition is processed as trusted content.
2. Credential access follows when code executes in the developer’s session and can read local secrets, tokens, or authenticated browser state.
3. Escalation happens when the initial session can modify files, invoke shells, or pivot into connected development and cloud systems.
4. Impact is achieved when the attacker steals secrets, alters code, or uses the compromised workstation as a bridge to broader CI/CD or cloud access.

Breaches seen in the wild

• PocketOS database deletion incident: An AI coding agent found an over-privileged Railway API token in the codebase and deleted PocketOS production data and backups in nine seconds.
• Sentry MCP Agentjacking 2026: Researchers showed a fake Sentry error, posted with a public DSN, could make AI coding agents run attacker code with developers' credentials.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Editor trust is now an identity control, not just a usability setting. When a code editor can execute project instructions before a user grants trust, the security boundary has already moved from file access to session authority. That makes workspace trust part of identity governance for the developer endpoint, because the session can expose human credentials and downstream non-human identities in one chain of execution. Practitioners should treat editor trust policy as a privileged access decision, not a preference.

Default autorun creates a trust collapse at the point of repository inspection. The assumption that users will review a repository before anything executes is broken when folder-open tasks fire automatically. The implication is that governance cannot rely on post hoc review of actions that already happened in the user context. Teams need to recognise that the trust decision occurs before any code review or security scan can intervene.

Workspace Trust disabled by default is a policy design flaw when the editor handles untrusted code. This configuration assumes safe-by-default behaviour in an environment where the primary interaction pattern is opening third-party or cloned repositories. That assumption fails because repository metadata can be weaponised as executable control flow. The implication is that IDEs need enforced trust boundaries aligned to how developers actually consume code, not how vendors wish they would.

Ephemeral repo trust window: the dangerous moment is the short interval between opening a project and establishing trust, because that is enough for code to execute in the developer’s session. That window is long enough to reach secrets, short enough to evade normal review habits, and broad enough to touch both human and machine identities. Practitioners should reframe workspace opening as an access event with identity consequences.

Developer laptops are high-value identity brokers, so IDE compromise is often a starting point rather than an endpoint. Once code runs locally, the workstation can expose cloud keys, PATs, SaaS sessions, and paths into CI/CD tooling. That means the blast radius is defined by what the laptop can already reach, not by the repository itself. Security teams should map editor execution to the same containment model they use for privileged access workstations.

What this signals

Workspace trust has become part of endpoint identity governance. Developer tooling now sits on the boundary between source code and session authority, which means repo-opening controls need to be managed like access controls. If the trust decision is deferred or disabled, the editor can become an execution broker for the credentials already present on the machine.

Ephemeral repo trust window: the short period between opening an unknown project and hardening the workspace is enough for code to run, secrets to be read, and downstream systems to be reached. That window is the programme signal teams should watch, because it shows where user intent and machine execution are out of sync.

For practitioners

• Enable Workspace Trust by policy Require the trust prompt in Cursor and block default automatic execution of folder-open tasks unless the workspace has been explicitly trusted.
• Disable automatic task execution Set task.allowAutomaticTasks to off where possible so .vscode/tasks.json cannot silently run when a repository is opened.
• Isolate unknown repositories Open untrusted code only in a viewer-only editor, disposable VM, or container so local credentials and sessions are not exposed to project code.
• Hunt for folder-open autoruns Search repositories for .vscode/tasks.json entries using runOn: "folderOpen" and alert on unexpected outbound traffic or spawned shells after folder open.

Key takeaways

• A code editor that auto-runs repository tasks on open can turn a normal browse action into immediate execution in the user’s session.
• The practical impact is credential exposure, file modification, and possible pivoting into cloud or CI/CD systems already reachable from the developer laptop.
• The most relevant control shift is to make trust explicit, disable automatic tasks, and isolate untrusted repositories from privileged sessions.

Key terms

• Workspace Trust: A trust control in code editors that separates passive file viewing from active execution of project-defined tasks. When disabled or bypassed, the editor can run repository instructions in the user’s context, which turns source control content into an execution path.
• Folder-open autorun: A repository setting that triggers a task or script automatically when a folder is opened in an editor. In security terms, it is a pre-execution trigger that can convert a routine browse action into code execution without a separate approval step.
• Editor Session Privilege: The effective access carried by a developer’s active desktop, browser, and tool sessions while using an IDE. It matters because code that runs in the editor may inherit access to cloud consoles, source control, tokens, and other high-value identity assets.
• Ephemeral Repo Trust Window: The short period between opening a repository and establishing that it is safe to trust. For developer tools, this window can be enough for a malicious project to execute code, read secrets, or pivot into connected systems before any review step occurs.

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 building or maturing an IAM programme, it is worth exploring.