The LinkedIn 'coding challenge' that ships a backdoor — and how it slipped past every red flag

What happened

A developer publishing under the handle Roman (roman.pt) walked through, step by step, a recruitment scam that arrived in his LinkedIn inbox dressed as a senior engineering role. The pitch was familiar: a Web3-adjacent startup, competitive compensation, a quick chat, then a 'small take-home assignment' shared as a private repository. The repo built. The tests passed. Buried inside a transitive helper file was a base64-encoded payload that, on `npm install` and the first `npm start`, reached out to a command-and-control endpoint, pulled down a second-stage Python loader, and dropped a persistent backdoor with shell access, clipboard scraping, and browser-credential exfiltration.

The clever part wasn't the malware — it was the social engineering wrapper that made running untrusted code on your main workstation feel like a normal Tuesday. The recruiter had a plausible profile, mutual connections, a company website with a real domain age, and a calendar link that resolved to a real Calendly. The 'CTO' he met on Google Meet had a working camera and a passable accent. The repository was small enough to feel reviewable and just complex enough that pasting a snippet into ChatGPT would return 'looks fine.' The post is calm and detailed, with screenshots, the deobfuscated payload, the C2 domain, and the exact moment Roman realized what he had just done.

The technique is not new. It maps cleanly onto the campaigns Mandiant and Unit 42 have been tracking under names like Contagious Interview, DEV#POPPER, and CL-STA-0240 — operations attributed to North Korean state-sponsored clusters (Lazarus, BlueNoroff) that pivoted from exchange heists to direct developer compromise after sanctions tightened around crypto mixers. What's new is the polish: in 2024 the lure projects were sloppy React skeletons with obvious obfuscated blobs; the 2026 version Roman documents looks like a real engineering codebase, with passing CI, a CONTRIBUTING.md, and a payload tucked inside the kind of file no candidate ever reads — a postinstall hook in a vendored utility.

Why it matters

The interesting failure mode here isn't technical, it's procedural. Senior developers have been trained for a decade to be paranoid about email attachments, USB sticks, and browser extensions, and almost completely untrained on the threat model of 'a stranger sends you a Git repo and asks you to run it.' Interview culture has normalized that exact action. A take-home assignment is, structurally, an attacker's dream: the victim has financial motivation to cooperate, the artifact has plausible deniability ('it's just a CRUD app'), and the victim's own laptop — the one with SSH keys, AWS profiles, browser sessions, and a logged-in `gh auth status` — is the runtime.

The economics also favor the attacker brutally. Sending a thousand LinkedIn messages costs roughly nothing; getting one mid-career engineer to `git clone && npm install` on a machine that holds production credentials is worth six figures on the right resale market, or a foothold into an entire company. Roman's piece notes that the recruiter's account, after he reported it, was still active a week later under a slightly different name. LinkedIn's response loop for this category of abuse is measured in weeks; the campaign's iteration loop is measured in hours.

The community reaction on the HN thread (1,003 points and climbing) split into two useful camps. The first treated the post as a cautionary tale about VMs and sandboxing — practical, correct, and largely already-known to security-minded engineers. The second, more interesting, camp pointed out that the real defense isn't technical isolation but a refusal to participate in the interview format at all: any company whose hiring process requires you to execute their code on your hardware is either naive about modern threat models or selecting against candidates who aren't. A handful of replies from engineers at Cloudflare, Stripe, and Sourcegraph noted that their own loops moved entirely to either live pairing on shared infrastructure (CodeSandbox, a company-provisioned Coder workspace) or to discussion-of-prior-work formats specifically because of this risk class.

The deeper point Roman makes — and the reason this post is hitting harder than the dozens of similar writeups before it — is that the attacker no longer needs to hide the payload well. They need to hide it in something boring. In a 4,000-line repo that builds cleanly, almost nobody will diff `node_modules/`, nobody will audit a postinstall script in a vendored helper, and nobody will read the minified bundle. The attack surface is human attention, and human attention is the cheapest resource in the engineering economy.

What this means for your stack

Three concrete changes are worth making this week, regardless of whether you're actively interviewing.

First, never run unsolicited code on a machine that holds credentials. The cost of a disposable VM is roughly zero in 2026 — a Coder workspace, a Lima VM, an OrbStack microVM, a free-tier Codespace. If a take-home requires `npm install` or `pip install -r`, that command should run inside something you can `rm -rf` without losing anything that matters. Configure your shell so that your real workstation has no globally readable AWS keys, no plaintext `.npmrc` tokens, and no SSH keys without passphrases. These are 2015 hygiene rules; the LinkedIn vector is the reason they're 2026 hygiene rules.

Second, change your interview defaults. If you run hiring loops, drop take-home assignments that require execution on the candidate's machine. Pair on a shared environment, or review prior work. If you're the candidate, push back: a company that can't accommodate 'I'll run this in a sandbox and screen-share' is telling you something about how they think about security, and the answer is unflattering. The HN thread surfaced multiple stories of candidates who lost AWS credentials, GitHub PATs, or in one case an entire crypto wallet to this exact pattern. None of them were junior.

Third, harden the dependency graph on the machines you can't replace. Use `npm ci --ignore-scripts` by default and only enable scripts when you've read them. Run `pnpm` with `--side-effects-cache=false` for unfamiliar projects. Pin Node and Python versions in a devcontainer so an attacker's postinstall can't assume a global tool path. None of this is novel — it's just that the threat model has finally caught up with what package maintainers have been warning about since the `event-stream` incident in 2018.

Looking ahead

The LinkedIn-recruiter vector is going to get worse before it gets better, because the asymmetry favors the attacker on every axis: cost, iteration speed, victim selection, and platform response time. The defensive move is not to outpace the attackers technically but to make 'I don't run strangers' code on my laptop' as socially normal as 'I don't plug in strangers' USB sticks' — a norm that took the industry roughly a decade to internalize and that we're now going to have to repeat for the package manager era. Roman's post is useful not because the attack is novel but because it's specific, named, and complete enough to forward to your team. Forward it.