Skip to content

Fix: Remove runOn: folderOpen to Prevent Code Injection via VSCode Tasks #251177

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

odaysec
Copy link

@odaysec odaysec commented Jun 11, 2025

"args": ["--no-launch", "--connection-token", "dev-token", "--port", "8080"],

"args": ["--port", "8080", "--browser", "none"],

Fix Arbitary code injection in .vscode/tasks.json configuration by removing all instances of "runOn": "folderOpen". This field can cause tasks to execute automatically when the workspace is opened, which may lead to unintended command execution especially if the workspace is opened in an untrusted environment.

Changes:

  • Removed all "runOn": "folderOpen" triggers to prevent automatic task execution.
  • Ensured all task definitions are executed manually and explicitly.
  • Verified that shell and npm task commands are static and do not introduce injection vectors.
  • Improved consistency and safety of args and command fields using ${workspaceFolder}.
  • Cleaned up problem matchers and ensured proper background task handling.

Why this is important:

Automatic task execution via runOn can pose a Remote Code Execution (RCE) vector if the workspace is opened blindly or if a malicious contributor introduces unsafe scripts into the task list. This fix aligns with security best practices in developer environments and improves the safety of the project's developer experience.

Case ID 🎟️: 98466
Report 📄 : VULN-155917

@joaomoreno
Copy link
Member

joaomoreno commented Jun 12, 2025

Running tasks is protected behind Workspace Trust, ie. the user is always asked whether they trust the workspace, before the task ever runs, either manually or automatically.

We appreciate your security concerns. We also appreciate you reaching out via the Microsoft Security Response Center. In the future we would also appreciate if you avoided submitting PRs that address potential security vulnerabilities out here in the open. It puts everyone at risk: our users and our partners. Submitting a security concern is enough to kick things off. If valid, we'll triage it and figure out a release schedule that ensures everyone's security.

@joaomoreno joaomoreno closed this Jun 12, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants