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.
Editorial analysis by NHI Mgmt Group, based on content published by Oasis Security: “Open Repo, Get Pwned (Cursor RCE)”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: A code editor that auto-runs repository tasks on open can turn a normal browse action into immediate execution in the user’s session.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
06/06/2026 3:15 am
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.
A question worth separating out:
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.
👉 Read our full editorial: Cursor open-repo RCE exposes AI code editor trust gaps
This post was modified 1 day ago by NHI Mgmt Group