Notifications
Clear all
Topic starter
06/06/2026 1:52 am
TL;DR: A malicious repository can trigger code execution in Cursor as soon as a folder opens because Workspace Trust is disabled by default and .vscode/tasks.json autoruns can fire without consent, according to Oasis Security. This shows how developer tooling can turn repo access into immediate session execution, expanding identity and secrets exposure beyond the IDE itself.
NHIMG editorial — based on content published by Oasis Security: Open Repo, Get Pwned (Cursor RCE)
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
What's in the full report
Oasis Security's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step proof-of-concept behaviour showing how the folder-open task executes inside Cursor.
- Specific hardening guidance for Cursor Workspace Trust and task.allowAutomaticTasks settings.
- Detection examples for identifying .vscode/tasks.json patterns that trigger autoruns.
- Implementation detail on how the vulnerability affects developer sessions, secrets, and downstream systems.
👉 Read Oasis Security's analysis of Cursor open-repo RCE and trust gaps →
Cursor open-repo RCE: what it means for IDE trust controls?
Explore further
06/06/2026 3:15 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Cursor open-repo RCE exposes AI code editor trust gaps
