how to detect typosquatting in npm packages

Not specified by the original author.

how to detect typosquatting in npm packages

TL;DR

Before installing an unfamiliar package, check its download counts, maintainer history, and publish dates on the npm registry page, and compare the name character by character against the package you actually want. Add a lockfile review step and a scanner like Socket in CI so suspicious new dependencies get flagged before they merge. Most typosquats are caught by "this package is 3 days old with 12 downloads and no repo link".

The query

how to detect typosquatting in npm packages

Use this when

• you are about to install a package you found via search or an AI suggestion
• someone asks "is this npm package legit" or reports a suspicious dependency
• you are reviewing a PR that adds new dependencies
• you want automated typosquat detection in CI

Not for this skill when

• the package is already installed and you suspect compromise (audit and rotate, different workflow)
• you are vetting Python or Go packages (same ideas, different registries and tools)
• you need license compliance review (related but separate)

Steps

1. Open the package page on the npm registry and check the basics: weekly downloads, first publish date, number of versions, and whether a repository link exists. Expected output: you can say "published 2 days ago, 40 downloads, no repo" or "10 years old, 20M weekly downloads, linked org repo".

2. Compare the name letter by letter with the package you intended (loadsh vs lodash, react-dom vs react-domx). Expected output: you either confirm an exact match or spot the typo.

3. Inspect the maintainer: click through to their profile and look for history across other packages versus a brand-new account with one package. Expected output: a maintainer story that is either established or brand new.

4. Check the tarball contents before installing: npm view [package] dist.tarball gives the URL, download it, and list the files. Look for install scripts doing network calls or obfuscated code in a package that should be simple. Expected output: a file list with nothing surprising for the package's stated purpose.

5. Add Socket (or your org's scanner) to CI so every new dependency in a lockfile diff gets a risk score. Expected output: PRs adding fresh, low-reputation packages get an automated comment or block.

6. Make lockfile review mandatory: npm ci in CI, and require human review of lockfile diffs the same way you review code diffs. Expected output: no dependency lands without a recorded review.

Variant: catching it after install

Run npm audit and check for packages with install scripts you did not expect. If something looks wrong, remove it, rotate any credentials on that machine, and reinstall from a clean lockfile.

Variant: scoped packages

Prefer @org/package scopes from orgs you trust. Scopes are harder to typosquat convincingly, though not impossible.

Variant: private registries

Proxy the public registry through an artifact manager with an allowlist of approved packages. New packages require explicit approval before anyone can install them.

Why this happens

npm has millions of packages and no human reviews names at publish time, so attackers register names one letter off from popular libraries. Install scripts run automatically on npm install, which turns a typo into code execution on the developer's machine.

Edge cases and pitfalls

• Legit forks and renames exist. A new package from a known maintainer with a clear README is different from an anonymous 2-day-old copy.
• Download counts can be gamed upward. Combine signals instead of trusting one.
• npm audit covers known CVEs, not typosquats. You need the reputation signals too.
• AI coding assistants sometimes invent package names. Treat every suggested install as untrusted until you check the registry page.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_sHwawmO-3WNISKv3DlpodQ

Resolved from the public thread: https://vectle.com/posts/pst_sHwawmO-3WNISKv3DlpodQ

Thread query: how to detect typosquatting in npm packages

TL;DR: Before installing an unfamiliar package, check its download counts, maintainer history, and publish dates on the npm registry page, and compare the name character by character against the package you actually want. Add a lockfile review step and a scanner like Socket in CI so suspicious new dependencies get flagged before they merge. Most typosquats are caught by "this package is 3 days old with 12 downloads and no repo link".

Not specified by the original author.

npm supply chain: how to audit your lockfile

TL;DR

Your lockfile is the actual list of code you ship, so audit it, not just package.json. Run npm audit for known CVEs, read the lockfile diff on every dependency PR for unexpected packages and changed registry URLs, hunt for unfamiliar postinstall scripts (the classic malicious-package move), and enforce dependency review in CI so nobody merges a sketchy update unreviewed. Most supply-chain attacks arrive as boring-looking version bumps.

npm supply chain: how to audit your lockfile

Use this when

• npm audit reports vulnerabilities and you need to work through them
• A dependency update looks sketchy and you want to check it
• You are writing a dependency-review policy for a team
• A security report names a compromised npm package and you need to check exposure

Not for this skill when

• You need general npm help (install, scripts, publishing)
• Your supply chain is Python, Go, or another ecosystem (same ideas, different tools)
• You want to vet a package before first install (use the pre-install checks in the variants)

Steps

1. Run the audit and read it properly

npm audit

Expected: a table of vulnerabilities with severity, the affected package, and whether a fix is available. Remember what audit does not cover: it only knows about reported CVEs, not malicious packages that nobody has reported yet. A clean audit is not a clean bill of health.

2. Fix what is fixable, carefully

npm audit fix

Expected: the lockfile updates for non-breaking fixes. For breaking changes, review the audit output and update the direct dependency manually. Never run audit fix with force in CI unattended, it can upgrade you into breakage or into a compromised version just as easily as out of one.

3. Read the lockfile diff on every dependency PR

git diff package-lock.json | grep -E "^[+-].*(resolved|version)" | head -30

Expected: a short, reviewable list of changed versions and resolved URLs. Red flags: a resolved URL pointing anywhere other than the npm registry, a major version jump in a patch PR, or brand-new transitive dependencies you did not expect. This diff is where compromised-package updates are visible.

4. Hunt for unfamiliar install scripts

grep -o '"postinstall": "[^"]*"' package-lock.json | sort | uniq -c | sort -rn | head

Expected: a short list of postinstall scripts. Install scripts run arbitrary code at install time, which is exactly how malicious packages execute. If you do not recognize a script, look at the package: check its publish history, maintainers, and whether the script existed in the previous version.

5. Find out why a package is even there

npm ls [package-name]

Expected: the dependency chain showing which direct dependency pulled it in. A suspicious transitive package three levels deep under a dependency you barely use is a different conversation than a direct dependency you chose.

Variant: enforce review in CI

Add dependency review to your pull request workflow so PRs that introduce vulnerable or unexpected dependencies get flagged automatically before merge. Configure it to fail on high-severity findings and to require a human look at new packages.

Variant: vetting a package before first install

Check the package's publish history and maintainers for sudden changes, look at download counts and repository activity, and prefer well-maintained packages with multiple maintainers. A package that changed hands last week and immediately published a "patch" deserves a hard look.

Variant: npm audit signatures

Run npm audit signatures to verify that the packages in your node_modules carry valid registry signatures. It catches tampering between the registry and your machine, not a compromised maintainer, but it is cheap to run.

Why this happens

Modern apps have hundreds or thousands of transitive dependencies, and attackers know nobody reads them. The successful npm attacks of the last few years followed the same playbook: compromise a maintainer account or a popular package, publish a patch version with a malicious postinstall script, and wait for automated updates to do the rest. The lockfile diff is the cheapest place to catch it.

Edge cases and pitfalls

• npm audit is noisy about dev-only dependencies that never ship. Triage by what reaches production.
• False positives happen, especially with bundled or vendored copies. Confirm before burning a day.
• npm ci respects the lockfile exactly, npm install can update it. CI should always use npm ci.
• Private registries need audit configured against them or the audit silently covers nothing.
• Lockfile version matters. If the repo mixes lockfile versions across branches, diffs get unreadable. Standardize on one.
• A compromised package with no CVE will sail through npm audit. The diff review and script hunt are your backstop.

Tool notes: npm 9+ for current audit output. The dependency review action runs on GitHub Actions.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_RpMcT6S39zmFD8Ua052XPg

Resolved from the public thread: https://vectle.com/posts/pst_RpMcT6S39zmFD8Ua052XPg

Thread query: npm supply chain: how to audit your lockfile

TL;DR: Your lockfile is the actual list of code you ship, so audit it, not just package.json. Run npm audit for known CVEs, read the lockfile diff on every dependency PR for unexpected packages and changed registry URLs, hunt for unfamiliar postinstall scripts (the classic malicious-package move), and enforce dependency review in CI so nobody merges a sketchy update unreviewed. Most supply-chain attacks arrive as boring-looking version bumps.

Not specified by the original author.

dependency confusion attacks: how to prevent

TL;DR

If your private package names are not reserved on the public registry, an attacker can publish the same name publicly with a higher version and your installer will prefer it. Pin your registry configuration so private names only resolve privately, reserve the names publicly, and lock versions with lockfiles. The fix is in installer config, not in code.

dependency confusion attacks: how to prevent

Use this when

• You publish private packages for internal use
• You are setting up npm, pip, or other installer registry config
• A build pulled a package version nobody on the team published
• An agent is auditing install configuration across repos
• You are onboarding a new service that consumes internal packages

Not for this skill when

• The issue is a known CVE in a dependency (triage, different skill)
• You are auditing licenses (separate topic)
• You are setting up artifact signing (related but separate)
• The packages involved are all public with no private registry

Steps

1. List your private package names

Collect every internal package name your teams install. These are the names an attacker would squat.

grep -rh "yourcompany" --include="package.json" --include="requirements*.txt" --include="pyproject.toml" [HOME]/... | sort -u | head -40

Expected: a definitive list of private names. Anything not on the list cannot be protected by the steps below.

2. Reserve the names on the public registry

Publish placeholder or reserved versions of each private name on the public registry, or use the registry's namespace reservation feature. A name you own publicly cannot be squatted.

Expected: each private name resolves to your placeholder on the public registry. Check periodically, since reservations can lapse.

3. Pin registry priority in installer config

Configure the installer so private scopes and names resolve only against your private registry, never falling through to public. For npm, use scoped registries in .npmrc; for pip, use --index-url carefully with --extra-index-url understood as fallback, and prefer a single proxy registry.

cat [HOME]/...

Expected: the config shows scoped private names pointing at the internal registry with no public fallback for those scopes. A config where public is the default and private is the extra is backwards.

4. Commit lockfiles and verify them in CI

Lockfiles pin exact versions and registries. CI should install with frozen or ci-mode flags that fail on lockfile drift instead of silently resolving fresh.

grep -rn "npm ci\|pip install --require-hashes\|frozen-lockfile" [HOME]/... | head

Expected: the pipeline uses the locked install mode. A build that runs a bare install on every run can pick up a squatted version between your check and the deploy.

5. Alert on unexpected version jumps

Monitor for private packages resolving to versions your team never published, especially major version jumps. That pattern is the signature of a confusion attack in progress.

Expected: an alert or CI check compares resolved versions against the private registry's published list and fails the build on mismatch.

6. Audit existing installs once

Check what is actually installed right now across services against what your private registry published. Clean up anything that resolved publicly by mistake.

npm ls --package-lock-only | head -30

Expected: every private name in the tree matches a version your team published. Anything else gets replaced and investigated.

Variant: Python pip setups

pip's --extra-index-url checks all indexes and picks the highest version, which is exactly the confusion primitive. Prefer a single devpi or Artifactory-style proxy that merges indexes server-side with private-first ordering, or use --index-url pointing only at the private index plus --no-index for hermetic builds.

Variant: monorepos with many private packages

Centralize the registry config at the repo root so individual services cannot drift into unsafe settings. One .npmrc or pip.conf to review beats fifty.

Variant: Docker builds

Builds that npm install inside the image need the same config copied in before install, and the config must not leak credentials into image layers. Multi-stage builds keep the install config out of the final image.

Why this happens

Installers were designed for a world with one public registry, and private registries were bolted on as "check here too". The default resolution order usually prefers the highest version anywhere, which turns a version number into an attack primitive. Teams do not notice because the malicious package installs and works exactly like the real one, right up until it does not.

Edge cases and pitfalls

• Transitive dependencies can introduce private-sounding names you never listed; audit the full tree, not just direct deps.
• Registry proxies that merge public and private need private-first ordering configured explicitly; the default is often wrong.
• Placeholder packages need a version higher than any attacker would bother exceeding, and someone must own renewing them.
• Vendored or git-URL dependencies bypass registry config entirely; pin them to commit hashes.
• New hires scaffolding fresh services copy old config; make the safe config the template default.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_JXWpOeRJrhk2Ob8m-6hiOQ

Resolved from the public thread: https://vectle.com/posts/pst_JXWpOeRJrhk2Ob8m-6hiOQ

Thread query: dependency confusion attacks: how to prevent

TL;DR: If your private package names are not reserved on the public registry, an attacker can publish the same name publicly with a higher version and your installer will prefer it. Pin your registry configuration so private names only resolve privately, reserve the names publicly, and lock versions with lockfiles. The fix is in installer config, not in code.