# 800 Fake npm Packages Are Hunting Developer Machines Right Now


Somewhere between your morning standup and your next npm install, an attacker may have already gotten a foothold.


Researchers at OpenSourceMalware have uncovered a coordinated campaign that published nearly 800 malicious packages to the npm registry — each one designed to drop a cross-platform remote access trojan and credential-stealing payload on whatever machine runs it. Windows, Mac, Linux. All of them.


That's not a skirmish. That's an invasion.


## Eight Hundred Is Not a Typo


The scale here deserves a full stop. Previous typosquatting campaigns on npm typically involved dozens of packages — sometimes a few hundred over months of sustained activity. Eight hundred in what appears to be a single coordinated push suggests either a well-resourced threat actor or, more likely, something that's been dramatically accelerating the economics of supply chain attacks: AI-assisted package name generation.


Researcher Paul at OpenSourceMalware put it plainly: the packages "appear to use AI slop squatted, or randomly generated typo-squatting package names." That phrase — AI slop — is doing a lot of work. It names something the security community has been watching quietly for about 18 months: attackers using generative models to churn out fake package identifiers at machine speed.


The math matters here. When an attacker had to manually craft convincing typosquats — lodahs for lodash, cros-env for cross-env — the ceiling on campaign scale was human creativity and time. Now the ceiling is compute cost. And compute is cheap. A campaign that once took weeks of preparation now takes an afternoon.


## One Payload, Three Platforms, Nowhere to Hide


The payload itself is doubly alarming: it's both a RAT and an infostealer packaged together. That combination isn't accidental.


A RAT (remote access trojan) gives the attacker persistent, interactive control of the compromised machine. An infostealer sweeps up credentials, tokens, browser-stored passwords, SSH keys, and API secrets in the immediate aftermath of infection. Together, they cover the two primary post-compromise objectives: get the credentials now, keep the door open for later.


What makes this campaign different from many that came before is the deliberate cross-platform build. Most commodity malware campaigns pick a lane — Windows, because that's where the numbers are, or occasionally Mac, because that's where the money is. Going after Linux simultaneously tells you something about the intended targets: developers. Specifically, developers running mixed environments. DevOps engineers. Security teams. People whose machines are connected to production infrastructure, CI/CD pipelines, and cloud accounts.


A developer's laptop is not a consumer endpoint. It's a lateral movement starting point.


## The npm Supply Chain Problem Nobody Fixed


This is, depressingly, not new territory. The npm ecosystem has been a recurring vector for supply chain attacks for years.


The event-stream compromise in 2018 targeted a specific Bitcoin wallet by injecting malicious code into a widely-used package with 2 million weekly downloads. The ua-parser-js incident in 2021 hit a package with 8 million weekly downloads. In 2022, 218 packages were found deploying a cross-platform RAT called njRAT. The pattern is established. The tooling available to npm's maintainers has improved. And yet: 800 packages.


Part of the structural problem is that npm operates at a scale that makes manual review impossible and automated detection a permanent arms race. The registry hosts over 2 million packages. Publish rate runs into the hundreds of thousands of new versions per month. The attacker's advantage is volume and velocity; the defender's advantage is supposed to be pattern detection and community reporting. When the attacker is using AI to randomize naming patterns at scale, the signal-to-noise problem becomes significantly harder.


There's also the install reflex. Developers are trained — by culture, by deadline pressure, by the sheer convenience of the ecosystem — to npm install first and verify never. That habit is the actual vulnerability being exploited here.


## What the Package Names Tell Us


The AI-generated naming approach has a specific strategic value beyond just volume. Convincing typosquats require the attacker to anticipate what a developer might mistype. Good typosquats are high-effort and high-precision. AI-generated random names catch something different: developers installing packages from unverified README snippets, StackOverflow answers, or AI coding assistants that hallucinate package names.


That last one is particularly significant. As developers increasingly use AI code assistants that occasionally invent plausible-looking package names, attackers can register those hallucinated names in advance and wait. The attack surface isn't just human error anymore — it includes model error.


---


## HackWire Analysis


The buried lead in this story isn't the RAT payload or even the scale of the campaign. It's what 800 AI-assisted packages in a single campaign tells us about where supply chain attacks are headed.


We've been operating under an implicit assumption that the effort required to run a convincing typosquatting campaign served as a natural throttle — that the cost of generating hundreds of plausible package names, registering them, wrapping a payload, and maintaining the infrastructure would limit who could run these campaigns and how often. That assumption is eroding.


When OpenSourceMalware's Paul describes these as "AI slop squatted" names, he's identifying a qualitative shift: the names don't need to be convincing. They just need to match what a developer types or what a coding assistant generates. The attacker is fishing with a net, not a speargun. Some percentage of developers will npm install some-weird-package because it appeared in a blog post, an AI suggestion, or a copied snippet. At 800 packages, you need only a small percentage to hit.


The concrete implication for engineering teams: your dependency policies need to treat any package under some meaningful threshold of downloads and age as high-risk by default. Tools like Socket.dev, Snyk, and Semgrep can surface behavioral analysis — packages that spawn processes, make network calls, or access credentials on install deserve immediate scrutiny regardless of their name. Lock your .npmrc to require explicit registries. Enable provenance where available.


More importantly: this campaign should be read as proof of concept for a new attack pattern that will get worse before it gets better. Defenders who haven't locked down their npm install pipelines in CI/CD environments are running exposed.


— HackWire Editorial


---


## Related Coverage


  • Read more in our [Malware](https://www.hackwire.news/category/malware) coverage
  • Cross-reference with [Breaches](https://www.hackwire.news/category/breaches) and [Vulnerabilities](https://www.hackwire.news/category/vulnerabilities)
  • Stay current via the [HackWire homepage](https://www.hackwire.news/)