I Found a Self-Propagating Worm Hiding Inside [.vscode] in My Own Commits

How a fake job-interview malware campaign made it into four of my repositories; disguised as a font file, triggered by opening VS Code, and carried in by my own collaborators without any of us knowing. And why the real danger isn't the repo it's in it's every other repo your access token can reach.

I checked my repos against two pieces of threat intel making the rounds:-Trend Micro's writeup on "Void Dokkaebi" and a LinkedIn post on a related campaign, "PolinRider": 1,900+ compromised repos, 1,047 account owners. Both describe a North Korea-aligned group running fake job interviews, getting candidates to run a "take-home assignment," and letting the payload spread on its own from there no further social engineering needed.

I expected to find nothing. I found four infected repos, malware quietly talking to Ethereum RPC endpoints, and proof it had spread there on its own inside ordinary, legitimately-titled commits from my own collaborators.

The trick

• .vscode/tasks.json with "runOn": "folderOpen" — runs automatically the instant VS Code opens the project. "hide": true keeps it invisible.
• The task runs node against a "font" — fa-solid-500.woff2.
• That font is fake: several KB of tab characters padding the real code off-screen, followed by an obfuscated loader.

The tell: FontAwesome doesn't ship a "solid 500" weight — only 400 and 900. A forged filename, sitting right next to genuinely real ones.

What I found

A full file-tree sweep (GitHub's code search lags badly on private repos and missed this) found the trigger in three repos and the byte-identical fake font in a fourth. Decoded, the payload was a Node loader hitting public Ethereum RPC endpoints (1rpc.io, drpc.org, publicnode, blockscout) plus a hardcoded wallet the "blockchain as C2" pattern from both reports. Each repo had exactly one commit ever touch these files planted in one shot, never edited again.

The part that worried me

The four commits weren't from strangers they were from people I'd added as collaborators, buried in normal, legitimate work: "Add audit findings feature," "Add dimensions to custom journal migration," a routine reviewed PR. Each commit did what its message said and silently dropped in the payload alongside it. That's the self-propagation: once a dev's machine is compromised, their tooling injects this into whatever they commit next, to any repo they can write to. Nothing for a reviewer to catch the diff just looks like a feature with two extra files.

It doesn't stop at the repo it started in

This is the part I'd actually want you to remember: PolinRider's own writeup notes that stolen credentials get used to force-push the payload to every branch that credential can reach not just the one repo you found it in.

A normal PAT, SSH key, or gh auth login session usually has repo scope: every private and public repo you own, everything you collaborate on, sometimes every org repo too. One cached credential, handed to every git push without asking which repo you meant. So the real blast radius isn't "the infected repo" — it's every repo that shares a credential with the machine that had it. A throwaway personal project and a client's production repo, pushed from the same laptop with the same token, are one exposure, not two.

Where I nearly made it worse

Cleanup is git-filter-repo to strip the malicious paths from history, then force-push. On one larger repo, my clone silently failed mid-transfer, leaving an empty local repo that git treated as valid. I ran the rewrite against it, then git push --mirror --force.

--mirror makes the remote match local exactly. Empty local, empty remote it force-deleted twenty real branches in seconds. Only the HEAD branch survived, because GitHub won't delete that one.

Lesson: --mirror --force can lose real work faster than you can read the confirmation prompt. Verify the clone's ref count against the remote first. I recovered 18 of 20 branches because GitHub keeps refs/pull/N/head alive even after a branch is deleted cross-referencing branch names against their last PR gave back the SHAs. The two branches that never went through a PR left no trace anywhere in the API. Gone, unless someone has a local copy.

What to actually check

• Search every repo's full tree (not just code search) for .vscode/tasks.json with runOn: folderOpen + hide: true running node against something in fonts/.
• Check font magic bytes real .woff2 starts with wOF2. Tab-character padding isn't a font.
• Don't trust a clean commit message check which files changed, not what the message claims.
• Audit what your active credential can actually reach, not just the repo in front of you. Move off blanket-repo-scope classic tokens to fine-grained, per-repo PATs.
• If you find it, tell whoever's commits carried it their machine is the actual point of compromise, not their intent.
• Never --mirror --force without confirming your local ref count matches the remote's first.

The four repos are clean now. I'm still rotating every credential that was ever active near the infected files, and checking everything else they touch.

Sources: Trend Micro, Void Dokkaebi · LinkedIn, PolinRider. Personal Experience