Subscribe to the Non-Human & AI Identity Journal

Notifications
Clear all

VS Code tasks files and developer compromise: are your controls ready?


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 15051
Topic starter  

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.

NHIMG editorial — based on content published by Abstract Security: Security Contagious Interview Interview Tracking the VS Code Tasks Infection Vector

By the numbers:

Questions worth separating out

Q: How should security teams prevent malicious VS Code tasks from executing in developer workspaces?

A: Turn off automatic task execution, review task files before trust is granted, and treat workspace approval as a security decision.

Q: Why do trusted repositories create a persistent risk in developer environments?

A: Because trust is remembered at the workspace level, not only at first open.

Q: What do security teams get wrong about file extensions in malicious code reviews?

A: They often assume the extension tells the full story.

Practitioner guidance

  • Disable automatic task execution Set task.allowAutomaticTasks to off in VS Code user settings so folder-open tasks do not execute without explicit approval.
  • Review repositories in a web editor first Open unfamiliar code in github.dev or another browser-based editor so you can inspect .vscode/tasks.json files without shell access.
  • Monitor for VS Code spawned child processes Alert when VS Code starts curl, wget, powershell, bash, cmd, or Node shortly after launch, especially if the child process reaches out to staging or payload-hosting domains.

What's in the full report

Abstract Security's full analysis covers the operational detail this post intentionally leaves for the source:

  • The exact GitHub Code Search queries used to surface malicious tasks.json repositories and related campaign infrastructure
  • Examples of task-file command patterns that trigger curl, wget, bash, cmd, and Node-based execution paths
  • Indicators tied to hidden payloads, including non-JavaScript file masquerading and whitespace-based command hiding
  • Detection opportunities for VS Code process trees, payload-hosting domains, and JSON storage staging

👉 Read Abstract Security's analysis of the VS Code tasks infection vector →

VS Code tasks files and developer compromise: are your controls ready?

Explore further

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 3 months ago
Posts: 14635
 

Workspace trust is becoming an identity control, not just a developer convenience. The article shows that a trusted repository can execute code without further challenge once the workspace is accepted, which means the approval boundary is now a security control boundary. That is a governance shift, not a niche malware trick. Teams should treat developer workspace trust as part of the access model, with review, revocation, and monitoring expectations aligned to the risk of local execution.

A few things that frame the scale:

A question worth separating out:

Q: Who is accountable when a trusted developer workspace executes malicious code?

A: Accountability sits with the organisation that defined the trust and review process, not just the individual developer who clicked through a prompt. Security, engineering, and platform owners all share responsibility for workspace policy, task execution settings, and safe repository handling procedures.

👉 Read our full editorial: VS Code tasks files let attackers trigger developer infection chains



   
ReplyQuote
Share: