Fake ‘interview’ repos lure Next.js devs into running secret-stealing malware
Summary
Microsoft has flagged a campaign in which attackers publish fake Next.js “interview” repositories that execute malicious JavaScript in memory on developers’ machines. The traps are designed to run during normal dev workflows: opening a project in Visual Studio Code, running the dev server (npm run dev), or starting backend modules. In all cases the malicious code loads a JavaScript loader—sometimes hosted via Vercel—runs it with Node, and connects to attacker-controlled command-and-control (C2) infrastructure.
The loader runs in memory via a separate Node interpreter to minimise disk artefacts, fetches further JavaScript tasks from the controller, and can exfiltrate data such as source code, secrets or credentials. The C2 rotates identifiers to evade detection, can obey kill-switch commands, and tracks spawned processes to avoid obvious performance fingerprints.
Key Points
- Attackers publish malicious Next.js repositories posing as interview or coding-test projects.
- Execution is triggered by normal developer actions: opening projects in VS Code, running dev servers, or importing backend modules.
- Malicious logic retrieves and runs a JavaScript loader (sometimes from Vercel) under Node and connects to C2 servers.
- Loader runs in memory via a separate Node process to reduce on-disk traces and fetches follow‑on tasks for data theft or further payloads.
- Threat actor rotates identifiers and uses telemetry/kill-switch features to evade detection and control campaigns.
- Compromises can expose source code, secrets and cloud credentials and may lead to wider organisational breaches if run from corporate machines.
- Microsoft advises treating developer workflows as a primary attack surface and monitoring unusual Node executions and outbound connections.
Context and Relevance
Developer-targeted supply-chain and social-engineering attacks have grown more sophisticated: instead of infecting popular packages, adversaries now weaponise hiring workflows where candidates are expected to run provided code. This campaign fits that trend and is particularly dangerous because it leverages common, trusted tools (VS Code, npm, Node) and relies on in-memory execution to avoid conventional detection.
For security teams and engineering managers this matters because a single developer machine can be a pivot point into source repositories, CI/CD pipelines and cloud accounts. Organisations that assume dev boxes are low risk should reassess controls, telemetry and isolation practices for build and test environments.
Why should I read this
Short version: if you build or hire Next.js (or Node) developers, this is the kind of sneaky trap that can quietly steal code and keys. Don’t run strangers’ interview projects on work machines and start watching Node processes and odd outbound traffic — you’ll save a lot of pain later.
Author style
Punchy: this is urgent for devs and security teams. The article flags a practical, realistic attack that exploits everyday behaviours — read the full details and act: isolate test environments, enforce policies for running third‑party code, and monitor for unusual Node runtime activity.
Source
Source: https://www.theregister.com/2026/02/25/jobseeking_nextjs_devs_attack/
