SUPPLY CHAIN THREAT DESK — Typosquatting on the npm registry has moved from an occasional nuisance to a persistent, industrialized attack channel. Security researchers monitoring npm ingestion feeds have flagged waves of lookalike packages arriving in bursts of dozens to hundreds within single days, often published within minutes of each other from freshly created maintainer accounts. The pattern is consistent enough that threat intel teams now track typosquatting less as isolated incidents and more as an ongoing campaign category — one that shows no sign of slowing as the registry crosses several million published packages and continues to grow by thousands more each week.
This roundup pulls together the recurring campaign patterns, the techniques attackers have refined over the past several years, and what they mean for engineering organizations that treat npm install as a routine, low-risk action.
What Typosquatting Looks Like on npm
Typosquatting exploits a simple human failure mode: fast typing and fuzzy memory. Attackers register package names that are one keystroke, one homoglyph, or one word-order swap away from a popular dependency, then wait for developers, CI scripts, or copy-pasted package.json files to make the mistake for them. Classic historical examples that security teams still cite as templates include crossenv (targeting cross-env), babelcli (targeting babel-cli), and d3.js (targeting d3) — all published years ago but still instructive because the underlying technique hasn't meaningfully changed.
What has changed is scale and automation. Modern campaigns don't register one or two lookalikes; they register clusters — permutations covering common misspellings, hyphen/underscore swaps, singular/plural variants, and scoped-vs-unscoped naming confusion — sometimes for a single popular package in one sitting. Researchers tracking registry activity have repeatedly observed cadences where malicious or suspicious packages are published to npm at a rate of dozens per day during active campaign windows, a volume that manual review processes at the registry level struggle to keep pace with.
Recurring Campaign Patterns
Dependency confusion mixed with typosquatting. Several campaigns have blended two techniques at once: publishing a public package under a name that collides with an internal, private package name at a target company, while also typosquatting adjacent public libraries to widen the net. This dual approach was visible in incidents following the original dependency-confusion research that put internal package naming under scrutiny industry-wide, and it remains a go-to move because it turns one registry upload into two separate attack surfaces.
Compromise-then-typosquat hybrids. The event-stream incident, ua-parser-js compromise, and the coa/rc account takeovers demonstrated a related but distinct pattern: rather than register a new lookalike name, attackers take over a legitimate, trusted package and inject malicious code into a version bump. Typosquatting campaigns frequently run in parallel with these takeover events — while defenders and registry maintainers are focused on the compromised original package, lookalike names capitalize on the resulting search confusion and news coverage to catch developers double-checking the "correct" name under pressure.
Protestware-adjacent and geopolitical triggers. The node-ipc incident, where a maintainer shipped destructive code targeting machines with Russian or Belarusian IP addresses, triggered a secondary wave of typosquatted forks and lookalikes as developers scrambled to find "safe" alternatives — some of which were themselves malicious. This is a recurring dynamic: any high-profile npm security event creates a short window where typosquatters register names playing on the confusion itself.
Credential and token theft targeting developer tooling. Campaigns mimicking popular CLI and SDK packages — including lookalikes for Discord bot libraries, cloud provider SDKs, and testing frameworks — have shipped payloads designed to harvest environment variables, .npmrc tokens, SSH keys, and browser-stored credentials, then exfiltrate them via webhook endpoints or DNS beaconing. The IconBurst campaign, which used typosquatted and confusingly-named packages to harvest form data from downstream applications, is a widely cited example of how far the blast radius can extend once a typosquatted package gets pulled into a build.
AI/ML tooling lookalikes. As AI-adjacent tooling exploded in popularity, typosquatters followed the traffic. Packages riding on the naming conventions of popular AI SDKs and chatbot integration libraries have appeared on npm mimicking legitimate client libraries, exploiting the fact that many developers are installing unfamiliar packages in this space for the first time and have no baseline for what the "real" package name should look like.
Why npm Remains a Persistent Target
Three structural properties of the npm ecosystem make it an efficient venue for typosquatting relative to other registries:
- Deep, implicit trust in transitive dependencies. A single top-level install can pull in hundreds of transitive dependencies that no human ever reviews by name, giving a typosquat multiple entry points beyond the direct
npm installcommand line. - Low publication friction. Registering a new package name and publishing a first version takes minutes and requires minimal verification, which keeps the cost of an attempt near zero even when most individual lookalikes are caught or ignored.
- Automation-friendly install patterns. CI pipelines, Docker build steps, and scaffolding tools frequently install packages non-interactively based on strings pulled from documentation, tutorials, or AI-generated code snippets — none of which involve a human pausing to double-check spelling.
Registry-side defenses, including npm's automated malware scanning and faster takedown processes, have improved measurably. But detection at the registry level is inherently reactive: it catches packages after publication and after some number of installs have already occurred, which for a targeted campaign can still mean meaningful exposure before removal.
Detection Challenges for Engineering Teams
The hard part for defenders isn't recognizing an obvious typosquat once it's pointed out — it's catching it before install, at the speed development actually happens. Manual code review rarely inspects package.json diffs line by line for subtle name changes. Lockfiles can mask a switch from a legitimate package to a lookalike if a developer edits a dependency string by hand and regenerates the lock. And because many malicious packages are designed to behave identically to the real thing for everyday functions while quietly exfiltrating data or establishing persistence in the background, runtime behavior alone often doesn't raise obvious red flags during a quick manual test.
This is compounded by dependency sprawl: most organizations have no reliable, continuously updated inventory of exactly which open source packages — and which versions — are running in which services, which makes it difficult to answer the first question incident responders ask when a new typosquat campaign hits the news: "are we affected?"
How Safeguard Helps
Safeguard is built to close the gap between "a malicious package was published" and "we know whether it's in our environment." Automated SBOM generation and ingest give security teams a continuously current, queryable inventory of every open source package and version across their codebase and containers, so when a new typosquatting campaign is disclosed, the question of exposure is answered in seconds rather than days of manual dependency-grepping. Reachability analysis goes a step further, distinguishing packages that are merely present in a lockfile from those whose flagged code paths are actually invoked by application code — cutting through alert noise so teams triage real exposure first. Griffin, Safeguard's AI-powered detection engine, continuously screens newly published and updated packages for typosquatting patterns, suspicious install-time behavior, and credential-harvesting indicators, flagging risky dependencies before they get deeply embedded in a codebase. And when a malicious or high-risk package is confirmed, Safeguard can open an auto-fix pull request that swaps in the legitimate dependency or pins to a known-safe version, turning a threat intel finding into a merged remediation with minimal engineering overhead.