Topic starter
02/08/2026 12:06 pm
TL;DR: Contagious Interview actors are using malicious .vscode/tasks.json files to trigger code execution when a trusted repository is opened in Visual Studio Code, helping them deliver downloader and backdoor payloads through fake job assessments, according to Abstract Security. The pattern shows how developer trust, workspace auto-execution, and hidden shell commands combine into a practical intrusion path that IAM-adjacent teams cannot ignore.
Editorial analysis by NHI Mgmt Group, based on content published by Abstract Security: “Contagious Interview: Tracking the VS Code Tasks Infection Vector”.
Key questions
Q: What breaks when VS Code tasks are allowed to run on folder open?
A: The control boundary breaks at the point where opening a repository becomes equivalent to executing attacker-defined commands.
Q: Why do trusted workspaces create lasting compromise risk after the first approval?
A: Because the approval can persist across later project opens and new pulls, a malicious task added after the first review may execute without another prompt.
Q: What are the signs that a developer workspace has been used as an infection path?
A: Look for VS Code spawning shell interpreters, Node executing unexpected file types, and outbound requests to unfamiliar hosting domains immediately after a project is opened.
Practitioner guidance
- Disable automatic task execution Set VS Code task.allowAutomaticTasks to off for user environments that open untrusted or externally supplied repositories.
- Review repositories in the browser first Use github.dev or another browser-based view to inspect .vscode/tasks.json before opening a repository in the desktop IDE.
- Treat workspace trust as a revalidation event Re-check trusted repositories after new pulls or contributor changes, because malicious tasks can appear after the initial trust prompt.
Bottom line: Malicious VS Code task files turn a normal repository open into an execution event, which is why developer trust settings now function as a security control.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:10 pm
Workspace trust has become a security control, not a convenience setting: when a repository can execute commands at open time, the approval decision functions like an access grant. That changes the governance model for developer environments because trust now persists beyond a single review session. Practitioners should treat trusted workspaces as controlled execution zones, not neutral folders.
A few things that frame the scale:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
A question worth separating out:
Q: How should security teams govern package and pipeline trust in developer environments?
A: Treat package ingestion, secret detection, and scanner execution as one trust boundary rather than separate tools. Apply policy where code and dependencies enter the environment, require explainable block reasons, and align controls to the developer contexts where installation actually occurs. That reduces bypass pressure while keeping supply chain governance operationally workable.
👉 Read our full editorial: VS Code tasks files let attackers trigger developer infection chains