How to Audit Your package.json for Typosquatting Attacks

What Is Npm Typosquatting?

Typosquatting is the practice of registering package names that are deliberately similar to popular legitimate packages — banking on developers making typos, AI tools hallucinating names, or teams copying package names from memory. When someone accidentally installs the impostor package, they execute the attacker's code.

Unlike traditional malware, typosquatted packages have legitimate-looking names, often minimal README files to appear genuine, and the malicious payload runs silently during installation via postinstall scripts. By the time you notice something is wrong, credentials, tokens, and environment variables may already be exfiltrated.

Real-World Typosquatting Attacks

crossenv (instead of cross-env) — stole environment variables from CI pipelines
lodash.clonedeep (instead of lodash's cloneDeep) — injected cryptocurrency miners
event-source-polyfill variants — multiple malicious versions targeting different typos
discord.js variants — targeted Discord bot developers to steal tokens

Why AI-Generated Code Makes This Worse

Traditional typosquatting relied on human error — a misplaced letter, a forgotten hyphen. With the rise of AI coding tools, the attack surface has expanded dramatically. AI models:

Hallucinate package names that don't exist — and malicious actors pre-register these names
Suggest plausible-sounding alternatives to real packages — often ones that already have typosquatted versions
Generate large package.json files quickly — too fast for developers to verify each entry manually
May reference outdated or renamed scoped packages — e.g., suggesting an old @types/ package that has been superseded

Common Typosquatting Patterns to Watch For

Attackers use predictable techniques. Training yourself to recognise these patterns is step one:

# Pattern 1: Character substitution

lodash → 1odash (l → 1)

moment → mornent (double char)

# Pattern 2: Hyphen/underscore confusion

cross-env → crossenv

date-fns → date_fns

# Pattern 3: Prefix/suffix additions

express → expressjs or node-express

axios → axios-http or node-axios

# Pattern 4: Scoped package attacks

@babel/core → babel-core (unscoped impersonation)

@aws-sdk/client-s3 → aws-sdk-client-s3

How to Audit Your package.json: Step-by-Step

Step 1: Start with a Baseline Check

Before anything else, get a clear picture of what you're working with. Extract all direct dependencies from your package.json and list them for review.

# Quick dependency list

node -e "const p = require('./package.json'); console.log(Object.keys({...p.dependencies, ...p.devDependencies}).join('\n'))"

Step 2: Verify Registry Existence

For every package, confirm it exists on the official npm registry. You can check manually using npm info [package-name], but for large dependency lists this becomes tedious quickly.

# Check a package exists

npm info react-auth-flow 2>&1 | grep "npm error 404"

# If you get 404, the package doesn't exist

Step 3: Check for Suspicious Lookalikes

For each dependency, search npm for packages with similar names. A real package should have a clear history, multiple versions, a meaningful description, and a reasonable download count. Be suspicious of:

Packages published within the last few weeks with very few downloads

Packages with no README or a README that's clearly copied from the legitimate package

Packages whose author doesn't match what you'd expect

Packages with a single version and no update history

Packages with postinstall scripts (check package.json on the npm registry page)

Step 4: Review Transitive Dependencies

Your direct dependencies bring their own dependencies — the full dependency tree can easily be 10x larger than your package.json suggests. Running npm ls shows the full tree, but it's difficult to audit manually.

Step 5: Automate It

Manual auditing doesn't scale — especially when you're shipping fast with AI tools. The right approach is to integrate automated dependency auditing into your workflow so every package.json is checked before installation and at every CI run.

Prevention: Hardening Your Setup

Use a lockfile and commit it

package-lock.json or yarn.lock pins exact versions and checksums. Never gitignore your lockfile — it's your tamper-proof record of what should be installed.

Enable npm's integrity checking

Use npm ci instead of npm install in CI environments — it strictly validates against your lockfile and fails if there are any discrepancies.

Run a pre-install audit

Before npm install on any AI-generated codebase, scan the package.json first. Catching a typosquatted package before installation means the malicious code never runs on your machine.

Consider a private registry or allowlist

For production environments, proxy npm through a private registry like Verdaccio or Artifactory, where you can enforce an allowlist of approved packages.

The Bottom Line

Typosquatting is not a theoretical risk — it's an active attack vector with documented victims. As AI code generation increases the volume and speed at which developers introduce new dependencies, the attack surface grows proportionally.

The good news: it's one of the most preventable supply chain attacks with the right tooling. Automated auditing before install, lockfile discipline, and CI/CD integration are the three pillars of a robust defence.