Cursor open-repo RCE exposes AI code editor trust gaps

At a glance

What this is: A malicious repo can execute code on folder open in Cursor, exposing developer sessions, secrets, and downstream machine identities through default autorun behaviour.

Why it matters: IAM and security teams need to treat developer tooling as an identity boundary because a single IDE session can expose human credentials and pivot into NHI access.

👉 Read Oasis Security's analysis of Cursor open-repo RCE and trust gaps

Context

Cursor’s default posture creates a simple but high-impact problem: opening an untrusted repository can become execution, not inspection. In practice, the IDE becomes part of the trust boundary, because a project file can instruct the editor to run code in the developer’s context before the user has assessed the repo.

That matters for identity governance because developer endpoints are already packed with human credentials and, increasingly, routes into CI/CD and cloud workloads. When a repo can trigger execution on open, the security model has to account for both the human session and the non-human identities reachable from that machine.

The affected starting position is typical for convenience-driven developer environments, which is precisely why it is risky. Default trust settings are often accepted as usability choices, but they create an identity and access problem as soon as repositories become active execution payloads.

Key questions

Q: How should security teams handle automatic task execution in developer editors?

A: Security teams should disable automatic task execution for untrusted repositories, require an explicit trust prompt before folder-open actions can run, and log any exception through policy. The practical goal is to stop repository content from becoming execution content before the developer has evaluated it.

Q: Why do developer workstations create NHI risk as well as human identity risk?

A: Developer workstations often store or reach cloud keys, API tokens, SaaS sessions, and service-account paths used by automation. If malicious code runs in that context, the attacker can move from a human session into non-human identities and production controls without needing a separate breach.

Q: What do security teams get wrong about trusting code repositories?

A: Teams often treat a repository as something to inspect before trusting, but folder-open autoruns turn the repository into an active trigger. That means trust must be established before the repo is opened, not after a task has already executed inside the user’s session.

Q: How can organisations reduce the blast radius of repo-open exploits?

A: Organisations should separate code review from credential-bearing endpoints, use disposable environments for unknown repos, and alert on editor-spawned processes. The point is to prevent a single malicious project from inheriting the identity and access scope of the developer machine.

Technical breakdown

How folder-open autoruns turn a repo into execution

Cursor supports VS Code-style tasks, and a repository can define task behaviour in .vscode/tasks.json. When runOptions.runOn is set to folderOpen, the IDE can execute the task as soon as the folder is opened. With Workspace Trust disabled, the editor is not waiting for explicit trust confirmation, so the repository itself becomes the trigger. That changes the security model from manual action to implicit execution, which is why a benign-looking project tree can behave like a payload. The issue is not just code execution, but execution occurring inside a developer session that already contains valuable identity material.

Practical implication: treat repo-open behaviour as executable content and block automatic task execution by default.

Why developer identity becomes the real target

The first thing attackers gain is not just code execution, but access to the developer’s authenticated environment. Modern laptops often carry cloud credentials, personal access tokens, API keys, and active SaaS sessions. Once code runs in that context, the attacker can read local secrets, alter files, and interact with services the developer is already authorised to reach. This is a governance problem as much as a technical one because the machine is acting as an identity transit point. In identity terms, the repo is not the endpoint. The endpoint is the bridge into a wider set of human and NHI privileges.

Practical implication: inventory developer endpoints as identity-bearing assets and reduce the privileges reachable from them.

How the attack can pivot from IDE to CI/CD and cloud

Once the malicious task runs, the attacker can use whatever credentials or tokens are present on the workstation to move outward into engineering systems. That includes source control, CI/CD runners, cloud APIs, and service accounts reachable through automation. The pattern is a delegated trust chain: a developer opens a repo, the IDE executes code, and that code inherits enough context to reach downstream systems. The technical risk is not limited to malware on a laptop. It is the reuse of a trusted interactive session as a launch point into non-human identities and production access paths.

Practical implication: separate developer workstation trust from production credential reach and monitor for IDE-spawned shells.

Threat narrative

Attacker objective: The attacker aims to convert a routine repo-open action into privileged execution and downstream access to secrets, cloud services, and NHI-controlled infrastructure.

1. Entry occurs when a developer opens a malicious repository that contains a crafted .vscode/tasks.json file with folder-open autorun behaviour.
2. Credential access happens inside the developer session, where the injected code can read cloud keys, PATs, API tokens, and active SaaS sessions already available on the laptop.
3. Impact follows when the attacker uses those credentials to modify files, exfiltrate secrets, or pivot into CI/CD and cloud systems, including non-human identities with broad permissions.

Breaches seen in the wild

• Emerald Whale breach — exposed Git config files led to 15K secrets stolen and 10K repo compromises.
• Google Firebase misconfiguration breach — Firebase misconfigurations exposed 19.8M secrets across developer instances.

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

NHI Mgmt Group analysis

Default trust settings are not neutral in developer tooling. Workspace Trust off by default is an access decision, not a convenience feature. When a repository can execute tasks on folder open, the IDE stops being a passive viewer and becomes an execution environment that inherits the user’s identity context. Practitioners should treat that as an identity boundary failure, not just an editor hardening issue.

Developer endpoints are now identity concentrators for both human and non-human access. A single workstation can expose cloud credentials, SaaS sessions, source control tokens, and service-account pathways in one session. That means a repo-open exploit is not confined to the laptop. It is a bridge into the NHI estate, where broad permissions and weak provenance can magnify the blast radius.

Contextual trust is the wrong model for code repositories. The assumption that a project can be inspected before it is trusted breaks when the repository itself can trigger execution. The implication is that review workflows built for static content no longer match interactive development environments. Security teams need to recognise repo contents as active control inputs, not inert files.

Identity blast radius starts before a human has finished evaluating the project. The named concept here is repo-open execution debt: the gap between opening code for inspection and allowing code to execute in the same trust zone. That debt accumulates wherever developer experience overrides execution containment, and practitioners should treat it as a measurable governance exposure.

Non-human identities inherit risk from human developer workflows. The attacker does not need to compromise a production service account first. They can reach it by abusing the developer context that already has paths into automation and cloud control planes. That makes developer-tool governance part of NHI governance, not a separate hygiene track.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• A further 47% have only partial visibility into those third-party connections, which leaves delegated access paths insufficiently governed.
• For a broader breach lens, The 52 NHI breaches Report shows how unmanaged access paths repeatedly turn routine trust into incident exposure.

What this signals

Repo-open execution debt will become a standing governance issue anywhere developers use IDEs that can auto-run tasks from project files. The practical shift is that source control hygiene, endpoint telemetry, and identity governance now intersect at the moment a folder opens, not just when code is deployed.

With 1 in 4 organisations already investing in dedicated NHI security capabilities according to The State of Non-Human Identity Security, the market is moving toward identity controls that start on the developer endpoint and extend into automation.

Teams should expect more scrutiny on how developer tools interact with OAuth-connected apps, cloud sessions, and service accounts. When a local editor can trigger remote access paths, governance has to follow the session boundary, not only the production boundary.

For practitioners

• Disable automatic task execution on untrusted repos Require Workspace Trust or an equivalent trust gate in Cursor, and set task.allowAutomaticTasks to off wherever policy allows it.
• Treat .vscode/tasks.json as executable content Add repository scanning for runOn: folderOpen and review task definitions during source intake, especially in external or newly cloned projects.
• Isolate unknown code in disposable environments Open untrusted repositories in viewer-only editors, containers, or ephemeral VMs so that folder-open actions cannot inherit production credentials.
• Hunt for IDE-spawned shells and unusual egress Monitor endpoint telemetry for shells started by the editor and for outbound requests immediately after project open, then tie those events back to the repository source.

Key takeaways

• A repo-open autorun bug turns an IDE into an execution surface, which makes trust prompts part of identity control rather than user experience.
• Developer laptops already hold enough human and non-human access to turn a single malicious folder into a wide downstream breach path.
• The control that matters most here is pre-execution containment, because once code runs in the developer session, the identity blast radius has already expanded.

Key terms

• Repo-open execution debt: The gap between opening a repository for inspection and allowing content inside it to execute in the same session. In developer environments, this debt creates a hidden trust boundary where project files can act like commands before the user has granted explicit approval.
• 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.
• Developer identity concentrator: A workstation that aggregates human authentication, cloud credentials, SaaS sessions, and automation-reachable tokens in one place. If the endpoint is compromised, the attacker can move from the person’s session into downstream non-human identities and production controls.
• 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.

Deepen your knowledge

Repo-open execution debt and developer endpoint trust are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are extending identity governance into engineering workflows, it is worth exploring.

This post draws on content published by Oasis Security: Open Repo, Get Pwned (Cursor RCE). Read the original.