The coding test is the attack

In February 2026, ReversingLabs published a campaign they named Graphalgo: 192 malicious packages across npm and PyPI, planted specifically to reach developers through fake job interviews. It had been running since May 2025. It was still publishing new versions the week they wrote it up.

One of those packages was called bigmathutils. It sat on npm for about a month behaving perfectly, accumulated roughly 10,000 downloads, and then version 1.1.0 arrived carrying the payload. Anybody who reviewed that package before the update reviewed a clean package. They were right, and being right bought them nothing.

That's the part worth sitting with. Not the malware — the timing. Every defensive check available to you runs against the past.

Why your checks keep passing

Work down the list you'd actually use.

Is the company real? They present as a blockchain or crypto firm and post on LinkedIn, Reddit, and Facebook. Microsoft's March 2026 write-up of the parallel Contagious Interview operation describes the same operators posing as crypto trading desks and AI shops. Is the repo hosted somewhere legitimate? GitHub, GitLab, Bitbucket — the real ones. Is the package on npm a known-good name? The graph family impersonated graphlib on npm and networkx on PyPI, and from December 2025 the operators moved to packages with "big" in the name. Does the dependency have real download numbers? Ten thousand of them, earned honestly, before it turned.

Are they asking you for money? No. They're offering you a job.

So the interview is real. The infrastructure is real. The download count is real. The only thing that isn't is the version you happen to install, and that changed after everyone stopped looking.

What runs when you run the take-home

The assignment sounds like every take-home you've done: run this project, debug it, improve it. ReversingLabs found the payload executing during the initial install step. Not at npm start, not when you open the file the task description points you at — during setup, before you've read a single line.

The delivery is layered on purpose. The malicious code isn't in the package you install; that package is a downloader. It pulls the next stage through public services — GitHub, npm, PyPI — so nothing in the artifact you cloned looks wrong when you scroll through it.

Microsoft documented a second route in the same family that's worse, because it removes the install step entirely. You clone the repo, you open the folder, and VS Code asks whether you trust the author. You click yes — you cloned it yourself thirty seconds ago. That trust grant executes the repo's task configuration, which fetches the backdoor through a URL shortener into a vercel.app host. Opening the folder is the whole attack.

For a salaried engineer on a managed laptop, that's a bad week and an incident ticket. For a remote contractor in Tbilisi or Da Nang with one machine, that laptop is your wallet, your client's production keys, and your only computer, and there is no IT department watching the endpoint.

The tell they can't remove

The October 2025 variant of the OtterCookie backdoor checks whether it's running in a virtual machine before it does anything interesting.

That single engineering decision tells you what the operators are afraid of, and it isn't your judgement of their LinkedIn profile. It's containment. They built VM detection because a contained execution wastes the payload — no keys in a fresh container, no logged-in browser, no keychain, nothing to take.

Which means containment is the one defence they had to spend development effort on. Everything else they route around for free.

Change what you're willing to run

Stop trying to authenticate the person. Their profile is disposable, the company is borrowed, and the package was genuinely clean when you'd have checked it. Move the decision onto the thing you're being asked to execute, because that part they can't make safe without giving up the operation.

Three defaults, none of which cost you anything in a real hiring process:

Treat npm install and pip install as running code, not fetching it. Install-time execution is where this campaign lands, not in the app you were told to debug.

Run every take-home in a throwaway VM or container — no keys, no signed-in browser, no keychain, no wallet, no SSH agent. If the assignment can't run that way, that constraint is the finding. Legitimate take-homes don't care where they execute.

Open the folder in an editor that doesn't execute a task config on trust, and read package.json, .vscode/, and the install hooks before you let a real IDE near it.

None of this is visible to a genuine hiring manager. Nobody has ever failed an interview for using Docker.

If you already ran it

Assume every credential that lived on that machine is gone. Not "might be" — plan as if it is, because the alternative is finding out in three weeks.

Rotate from a different device. Rotating on the compromised machine hands the attacker the new secret alongside the old one. Revoke sessions and tokens rather than just resetting passwords, or the live session survives the reset. Move wallet funds first, from a clean machine, before anything else on this list. Regenerate SSH and signing keys and strip the old public keys from GitHub, your cloud provider, and every deploy target. Tell any client whose production credentials were sitting in a .env on that disk.

Then wipe it. A backdoor that read your Keychain and installed persistence is not something you remove with a scan.

Before the next DM

The check that helps takes about a minute, and it belongs before the clone, not after.

Run the recruiter's name, the domain, or the email through our scam registry. A miss is not a clearance — it means nobody has filed that string yet, and these operators burn identities fast enough that most never get filed at all. A hit saves you an afternoon and possibly your keys.

If one of them already reached you, file it with the handle and the repo URL. The handle and the URL are the parts that are searchable later. "A scammer on LinkedIn" helps nobody.