A Single npm Account Pushed 14 Typosquatted Packages in Four Hours to Steal Cloud and CI Secrets. Here's the 10-Minute Audit.
On May 28, a single newly created npm maintainer alias (vpmdhaj) published 14 malicious packages inside a four-hour window. They typosquat well-known OpenSearch, ElasticSearch, DevOps, and environment-config libraries, and they exist for one reason: to steal cloud and CI/CD secrets the moment they install. If you run automated installs anywhere (and if you have a CI pipeline, you do), you're the intended target.
This caps a genuinely brutal month for npm. node-ipc, a library with over 10 million weekly downloads, got three malicious versions in May. The AntV ecosystem took a 300-plus-package "Mini Shai-Hulud" wave. The TrapDoor campaign spread across npm, PyPI, and Crates.io at once. But typosquatting deserves its own attention because the attack vector is different in a way that matters: it doesn't require compromising anything upstream. It requires you to make a typo, and then your machine does the rest.
Why typosquatting is the one you can actually prevent
A maintainer-account compromise (what hit TanStack and AntV) is mostly out of your hands. A trusted package you already depend on gets a poisoned version pushed through a legitimate pipeline, and unless you pin and verify, you inherit it. That's a hard problem and most of the defense lives upstream.
Typosquatting is the opposite. The attacker isn't compromising a real package; they're registering a fake one with a name one keystroke away from a real one and waiting for someone to fat-finger an npm install. opensarch instead of opensearch. A hyphen where there should be a dot. A swapped letter in a DevOps tool you install in CI. The whole attack depends on a human or a script typing the wrong name, which means, unlike an upstream breach, this is one you can almost entirely shut down on your side.
And the payload is nasty by design. These packages are built to grab cloud credentials and CI/CD secrets on install. On a CI runner, that's the keys to your deploys. On your laptop, that's your AWS profile and whatever tokens live in your environment.
Why solo operators are uniquely exposed
You're one person. There's no security team reviewing dependency additions, no second pair of eyes on the package name in a PR, no internal registry proxy quietly blocking known-bad names. Your CI runner holds your deploy credentials because you set it up that way, alone, probably in a hurry. Every structural protection a larger org has against this, you don't, which means you have to make a few of them yourself, deliberately, because no one's going to do it for you.
The good news is it genuinely takes about ten minutes.
The 10-minute audit
Do these this weekend. None of them require buying anything.
Pin exact versions. Make sure your lockfile is committed and that CI installs from it. Use npm ci, not npm install, in every pipeline: npm ci installs exactly what the lockfile specifies and fails if package.json and the lockfile disagree, which kills a whole class of surprise substitutions.
Grep your lockfile for the named typosquats. Open package-lock.json and search for the libraries this campaign imitates: OpenSearch, ElasticSearch, and your DevOps/env-config dependencies. Confirm the exact spelling of every one matches the real package. While you're there, eyeball any dependency name that looks slightly off. A typo that's been sitting in your lockfile for weeks is the worst case, because it already ran.
Scope your CI tokens to least privilege. This is the one that limits the blast radius if something does get through. Your CI deploy token should be able to deploy and nothing else: not read your whole cloud account, not touch unrelated services. If a malicious install lifts a tightly scoped token, the attacker gets a narrow capability instead of your entire infrastructure.
Turn on provenance and audit signals. Run npm audit and pay attention to provenance where packages publish it. Provenance won't catch a brand-new typosquat with no history, but it raises the cost of the broader category of supply-chain attacks, and it's free to enable.
Rotate anything that might already be exposed. If you've installed anything questionable recently, or you're not sure, rotate your cloud keys and CI secrets. Rotation is cheap insurance and it's the only move that actually helps if you've already been hit and don't know it.
The honest take
You cannot dependency-audit your way to zero risk. The upstream compromises (TanStack, AntV, node-ipc) prove that even perfect hygiene on your end doesn't stop a poisoned version of a package you legitimately trust. That fight is partly out of your hands and it's going to keep happening.
But typosquatting is the part you own completely, and that's worth being clear-eyed about. The entire attack hinges on a wrong name making it into your install path. npm ci, a committed lockfile, scoped CI tokens, and a two-minute grep through your lockfile shut down nearly all of it. That's not a security program: it's a checklist you finish before lunch. Do it this weekend, because the alternative is finding out your CI token had account-wide permissions on the day someone's typosquat finally lands in your pipeline.
Author
Lukas
@lukcombinator