Malicious Next.js Repos Target Developers via VS Code

Introduction: why this matters

Developer workstations and build environments are high-value targets because they often hold source code, signing material, and secrets (API tokens, cloud credentials) in environment variables. Microsoft Defender Experts reports a campaign seeding malicious Next.js repositories—often wrapped as job-related “take-home” assessments—designed to blend into normal developer workflows and reliably trigger code execution.

What’s new / key findings

Microsoft observed multiple related repositories with shared naming conventions and reused loader logic. While the initial lure varies, the end state is consistent: runtime retrieval and in-memory execution of attacker-controlled JavaScript, followed by staged C2.

1) VS Code workspace execution on folder open

Some repos include .vscode/tasks.json configured with runOn: "folderOpen". If a developer opens (and trusts) the project, a task runs automatically and launches a Node script that fetches a JavaScript loader (observed staged on Vercel) and executes it.

2) Build-time execution when running the app

Other variants trigger when a developer starts the project (for example, npm run dev). These repos embed malicious logic in seemingly normal assets (e.g., a trojanized jquery.min.js). The asset decodes a base64 URL, retrieves the loader (again, frequently from Vercel), and executes it in memory.

3) Backend startup execution with env exfiltration + dynamic RCE

A third path activates during server initialization/module import. Repos may contain a .env value like AUTH_API=<base64>. On startup, backend code decodes the endpoint, posts process.env to the attacker, then executes returned JavaScript using dynamic compilation (e.g., new Function("require", response.data)(require)). This can leak sensitive configuration and enables operator-driven follow-on payload delivery.

Stage 1 registration → staged command-and-control

Across all paths, execution converges on an initial “registrar” stage that profiles the host and polls a registration endpoint, receiving an instanceId to correlate subsequent activity. Telemetry also noted persistent callbacks to attacker-controlled infrastructure (including HTTP traffic on port 300) after initial staging.

Impact for IT admins and security teams

• Higher risk on developer endpoints: Opening a repo can be enough to execute code if workspace tasks are trusted.
• Credential exposure: The backend startup path can exfiltrate environment variables (cloud keys, database credentials, CI tokens).
• Harder detection: In-memory execution and staged loaders can reduce obvious on-disk artifacts.

Action items / next steps

• Developer guidance: Treat take-home assessments and unfamiliar repos as untrusted; avoid clicking “Trust” in VS Code until reviewed.
• Repo inspection: Flag/inspect .vscode/tasks.json (especially runOn: "folderOpen"), unexpected Node scripts under .vscode/, and minified libraries that don’t match known-good hashes.
• Secret hygiene: Reduce reliance on long-lived secrets in .env; use managed identities/short-lived tokens where possible and rotate any exposed credentials.
• Detection & controls: Monitor Node.js processes for unusual outbound connections (e.g., dev tools calling staging domains followed by unknown C2), and consider egress restrictions from developer devices and build agents.
• Hunting: Search code hosting and internal mirrors for naming “families” and structural reuse patterns described by Microsoft (near-duplicate repos, similar loaders, repeated staging endpoints).