I Almost Got Hacked by a Fake Coding Challenge

Last week I received what looked like a standard coding challenge for a developer role. The repository appeared professional—a full-stack CRM application with React frontend and Node.js backend. Everything seemed normal until I decided to audit the dependencies before running npm install.

That decision probably saved my machine from being compromised.

The Setup

The attack vector was clever. Hidden among legitimate dependencies in server/package.json was a package called dotenv-embed. The name is designed to look innocuous—it sits right next to dotenv, a package nearly every Node developer uses.

{
  "dependencies": {
    "dotenv": "^16.3.1",
    "dotenv-embed": "^3.3.5"
  }
}

In the code, it was imported as logger to further disguise its purpose:

import logger from "dotenv-embed";
logger(); // Triggers malware execution

What the Malware Does

The package spawns a detached child process that:

1. Fetches obfuscated JavaScript from a remote server
2. Executes it with full require() capabilities
3. Has access to your file system, environment variables, and potentially browser data

The payload targets exactly what you’d expect—.env files, SSH keys, credentials, and anything else valuable on a developer’s machine.

Red Flags I Noticed

A few things stood out:

• Package name mismatch: Why would something called dotenv-embed be imported as logger?
• Low npm stats: The package had almost no downloads or community engagement
• Recent publish date: Created just days before the “challenge” was sent
• Spoofed git commits: The repository had commits dated months ago, but the package was brand new

What I’m Doing Differently Now

I’ve always been pretty careful, but this made me paranoid in useful ways. I now audit dependencies before running npm install on anything from an unknown source. I check npm stats—legitimate packages have download counts and community activity. And if something’s imported under a different name than the package, that’s worth investigating.

Running untrusted code in containers is probably the right move. At minimum, don’t run it on a machine that has your SSH keys and .env files sitting around.

Why This Matters

This attack required real effort—stolen documentation from the Pino logger project, fake identities, and a professionally structured repository. Supply chain attacks are getting more sophisticated, and developers make good targets. Our machines tend to have a lot of access.

If something feels off about a coding challenge or job opportunity, trust that instinct. Mine almost certainly saved me here.

I’ve published a full technical analysis of this malware with IOCs and file hashes. If you’re a security researcher or want to report the package, feel free to reach out.