Supply Chain Security

How nproxy catches typosquat attacks before they reach your code

Typosquatting is still one of the easiest ways to land malware in a build pipeline. One transposed letter and your package manager pulls a different package than you intended. In npm, this is not theoretical: it has repeatedly led to credential theft and malware execution.

Published April 2, 2026

How typosquatting actually happens

Developers move fast and dependency names are easy to miss in review. The attack pattern is simple: publish a lookalike package name, wait for an install typo or dependency confusion, then run malicious code in install-time or runtime paths.

Common examples look like this: lodash vs lodas, or axios vs axois.

Real incidents, not hypotheticals

Incident timeline
  • July-August 2017 - crossenv typosquatted cross-envand exfiltrated environment variables. npm removed the package and related lookalikes on August 2, 2017.
  • October 4, 2023 - ReversingLabs documented node-hide-console-windows, a typosquat of node-hide-console-window, delivering DiscordRAT and r77 rootkit payloads.
  • March 24, 2026 - Socket reported five typosquatting npm packages (raydium-bs58, base-x-64, bs58-basic, ethersproject-wallet, base_xd) stealing private keys via Telegram exfiltration.

Which nproxy rules catch this attack class

nproxy evaluates package requests at fetch/install time and can block or warn before dependency resolution completes. For typosquats, the highest-signal controls are first_seen and malware.

first_seen
block (default Pro)

Blocks package names first published within your quarantine window (default 7 days). This is effective against fresh typosquats that appear shortly before an install attempt.

malware
block (default Free/Pro)

Blocks package versions flagged by threat intelligence as malware, typosquatting, protestware, or trollware. This catches known bad packages even when they are no longer brand new.

These rules are complementary: first_seen helps during the early publication window, malware blocks known-bad packages once threat intelligence catches up.

nproxy does not guarantee every malicious package is caught. It reduces risk by enforcing policy at install time instead of after code has already been pulled into developer machines and CI.

Reproducible setup commands

These commands were validated against the current CLI and are copy/paste safe.

1) Configure .npmrc for your org
npx @nproxy/cli setup acme-security
2) Verify proxy connectivity
npx @nproxy/cli verify acme-security
3) Install through nproxy (example typo package test)
npm install lodas \
  --registry=https://acme-security.nproxy.app/

What a blocked typosquat looks like

Example install-path output using real nproxy rule names and messages:

Terminal

$ npm install base-x-64 --registry=https://acme-security.nproxy.app/

resolving packages via acme-security.nproxy.app...

BLOCKED base-x-64@0.0.6 - first_seen: Package first published within the last 7 days

BLOCKED base-x-64@0.0.6 - malware: Known malware or typosquatting detected

resolution failed - blocked package in dependency graph

$

Operational guidance for platform teams

  • Keep malware blocking enabled in all environments, including developer laptops and CI agents.
  • Use first_seen in block mode for production pipelines and high-trust repos where new package adoption should be deliberate.
  • Review blocked package events in audit logs and either approve intentionally new packages or keep them quarantined.
  • Train reviewers to treat one-character dependency name changes as a security event, not a typo fix.
Sources

Stop risky packages before they reach production

Typosquatting is not slowing down. Put policy checks in your install path before the next lookalike package lands in your lockfile.

npx @nproxy/cli setup your-org-slug
Protect a repoReview security rules