So we checked. Not a sample, not an estimate — every single-character typo (omit a letter, double a letter, swap two adjacent letters — the three classic patterns) of the 30 most popular packages on npm and the 30 most popular on PyPI, queried live against each registry's real API, then cross-referenced every hit that's actually registered against OSV.dev's public malicious-package database.

The headline numbers

• npm: 498 candidate typo names checked across 30 popular packages. 297 (59.6%) are currently registered, real packages. Of those 297, 97 (32.7%) are already documented as malicious in OSV's public database — not "suspicious," not "flagged by us," but carrying a real MAL- or GHSA- advisory ID today.
• PyPI: 582 candidate typo names checked across an equally popular 30-package set. 47 (8.1%) are registered. Zero are flagged malicious in OSV.

Same technique, same rigor, same day. One ecosystem where a third of the look-alikes you'd stumble into are already confirmed hostile; the other where the exposure — at least via this specific single-typo technique — is close to zero.

Methodology

This mirrors the exact detection method DepWarden uses in production: Damerau–Levenshtein edit-distance matching against a curated list of high-popularity package names. For this study we narrowed to the three typo patterns that account for the overwhelming majority of real-world typosquats (and match the classic examples — expresss, epxress — that show up in every writeup of this technique):

1. Omission — drop one character (express → expres)
2. Duplication — double one character (express → expresss)
3. Adjacent transposition — swap two neighboring characters (express → epxress)

For each of the 30 most popular packages per ecosystem, every candidate generated by these three rules was checked against the real registry API (registry.npmjs.org for npm, pypi.org/pypi/.../json for PyPI) — a 200 response means it's a real, currently-published package. Every hit was then queried against api.osv.dev for any associated advisory. Nothing here is inferred or estimated; every count is a live HTTP response, checked on 25 August 2026.

What this deliberately doesn't claim: a registered look-alike name is not automatically malicious. Plenty of short candidate strings (vue → ve, next → net) collide with legitimate, completely unrelated packages that just happen to be short common words — npm alone has over 3 million packages, so some collision is inevitable. That's exactly why the OSV cross-reference matters: it's the difference between "this name exists" (weak signal) and "this specific package is a documented, named threat" (real finding). The 97/47 split above is the second kind.

Which popular packages attract the most confirmed-malicious squats

request — deprecated since 2020 but still one of the most-installed packages in npm history from years of accumulated dependents — tops the list by a wide margin. That's a pattern worth naming explicitly: an old, extremely popular, no-longer-actively-maintained package appears to be a more attractive squatting target than a young one, plausibly because the volume of developers who've typed its name from memory (and therefore mistyped it) over the package's lifetime is simply larger. We're not claiming causation from an n=30 sample, but the shape of the data points that way.

The full data, and how to re-run it yourself

The top-10 table above is the interesting slice, but a study you cannot check is just an assertion. So here is all of it — every candidate name, whether the registry says it is published, and every advisory id attached to it.

• Download the dataset (CSV) — one row per candidate, 1,098 rows across both ecosystems.
• Same data as JSON — includes the exact package lists used.
• Re-run it yourself: the generator is in the DepWarden repo at scripts/typosquat-study.mjs. The package lists are hard-coded in that file on purpose, so a re-run stays comparable rather than drifting with whatever is popular this week.

Re-running the whole study on 5 September 2026, eleven days after the original pass, reproduced it closely: npm 483 candidates, 284 registered (58.8%), 99 carrying an advisory (34.9% of registered); PyPI 615 candidates, 52 registered (8.5%), zero carrying an advisory. The per-package ranking came back identical — request still first by a wide margin at 17. Counts move by a few points between runs because packages get published and unpublished and OSV adds advisories; the finding does not.

The second data point: how healthy are the real packages?

Alongside the typosquat check, we pulled real OpenSSF Scorecard scores — an independent, automated 0–10 supply-chain-hygiene rating covering branch protection, CI presence, signed releases and 15 other checks — for the same 60 popular packages (59 resolved; one npm package's GitHub mapping didn't return a score).

• npm: average score 6.24/10. 20.7% score below 5. 6.9% score below 3.
• PyPI: average score 6.79/10. 10.0% score below 5. 0% score below 3.

Lowest-scoring packages checked: bluebird (2.0), debug (2.6), and request (3.4) on npm; psycopg2 (3.7), setuptools (4.4), and httpx (4.9) on PyPI. Worth noting: bluebird and debug — two of the lowest Scorecard scores in the whole sample — also both appear in the confirmed-malicious-squat table above. Again, not a causal claim from this sample size, but a genuinely interesting adjacency: the same handful of enormously popular, comparatively lower-maintenance-signal packages show up on both lists.

What this means if you ship software

The practical takeaway isn't "avoid npm" — it's that single-character typing mistakes in npm install carry real, non-hypothetical, currently-live risk today, at a rate (roughly 1 in 3 of the names you could plausibly typo into) that's higher than most developers would guess. PyPI's exposure, at least to this specific attack pattern, is measurably lower — worth knowing if you're weighing where a supply-chain review should focus first.

Three concrete things that actually help: pin exact versions in a lockfile so a one-off typo in a scratch command doesn't become a permanent dependency; use a scanner that checks for typosquat-shaped names as a distinct signal from CVE matching, since (by definition) none of these 97 malicious packages have a CVE; and treat an unfamiliar package with a name suspiciously close to something you know — one character off, one character doubled — as worth a second look before installing, especially if it has few downloads and a recent publish date.

DepWarden runs this same detection — Damerau-Levenshtein matching against a curated popular-package list per ecosystem — on every scan, free, no account required. Related reading: how npm typosquatting and dependency confusion attacks work, detecting typosquats in CI, what the OpenSSF Scorecard actually measures.

What SAST scans

Static Application Security Testing (SAST) reads your source code — the JavaScript, Python, Java, Go, Ruby files that your team writes — and looks for security flaws in the code itself. SQL injection in a database query. A hardcoded AWS key in a config file. An XSS vector in a template. A call to MD5 where bcrypt should be. An HTTP endpoint that passes user input to a shell command.

SAST doesn't know about or care about which npm packages you installed. It's analyzing your code logic. A SAST tool will flag this:

const result = db.query(`SELECT * FROM users WHERE id = ${req.params.id}`);

...because the user-controlled value req.params.id flows directly into a SQL query without parameterization. It doesn't matter which database library you're using or whether that library has any CVEs. The bug is in your code.

What SCA scans

Software Composition Analysis (SCA) reads your dependency manifest — package.json, requirements.txt, pom.xml, go.mod — and checks every package (direct and transitive) against a vulnerability database like OSV. If you're running lodash@4.17.4, which has a known prototype pollution CVE, SCA flags it.

SCA doesn't analyze your code at all. It's checking the versions of the packages you depend on against a list of known-vulnerable versions. A perfect SAST run with zero findings can coexist with fifty SCA findings in your dependencies — and vice versa.

The blind spots in each

What SAST can't see:

• Vulnerabilities introduced by the open-source packages you import
• Supply-chain attacks with no CVE (typosquatting, dependency confusion)
• Runtime configuration mistakes in cloud infrastructure
• Bugs that only manifest under specific execution conditions

What SCA can't see:

• Security bugs in the code your team writes
• Hardcoded credentials in your own source files
• Weak cryptographic choices in your own logic
• Framework misconfigurations (CSRF disabled, DEBUG mode on, CORS wildcard)

The blind spots are almost perfectly complementary. An attacker probing your application has two main paths: exploit a bug in your code (SAST territory) or exploit a bug in a library you imported (SCA territory). Both scanners, covering both paths.

A concrete example: two reports, two attack surfaces

Imagine a Node.js API with these two problems:

Problem A (SAST territory): In controllers/user.js, you build a MongoDB query with string interpolation from req.query.username. This is a NoSQL injection vulnerability. It's in your code. No CVE exists for it. SCA will never find it.

Problem B (SCA territory): You depend on jsonwebtoken@8.5.1, which has a known algorithm confusion vulnerability (CVE-2022-23529). Your code calls jwt.verify() correctly. SAST may not flag it because the call looks correct in isolation — the vulnerability is in the library's internal implementation.

These are two real attack vectors. One scanner catches Problem A; the other catches Problem B. Running only SCA leaves NoSQL injection open. Running only SAST leaves the JWT library vulnerability open.

Running both together

The most effective setup runs SCA and SAST on the same codebase in one pass: upload a manifest alongside a source zip in the browser, or connect a GitHub, GitLab, Bitbucket or Azure DevOps repo branch directly and DepWarden runs both.

That single scan:

• Parses package-lock.json, resolves the full transitive dependency tree, checks OSV/KEV/EPSS for vulnerabilities and typosquats
• Walks the source tree, detects languages, runs pattern + taint analysis against 300+ security rules
• Ranks findings from both by severity so nothing gets buried

Two scan types, one report, no account required.

Prioritization across both

When findings come from both SAST and SCA, the combined priority order:

1. SCA: KEV-listed + direct dependency + fix available — attackers are actively using this, you can fix it now
2. SAST: HIGH-confidence injection/RCE finding — user input confirmed flowing to a dangerous sink
3. SCA: HIGH CVSS + EPSS > 0.10 + fix available — elevated exploitation probability
4. SAST: hardcoded credential — immediate exposure risk if it reaches a repo
5. Everything else — triage by severity and confidence, don't block releases on MEDIUM/LOW

What DepWarden gives you

DepWarden combines both scanners in one tool, free and without an account:

• SCA across 11 package ecosystems (npm, PyPI, Maven, Gradle, Go, Cargo, Composer, RubyGems, NuGet, Dart, Swift) with OSV/KEV/EPSS enrichment and exploitability-first prioritization
• SAST across 15 languages and IaC formats, with 300+ security rules covering injection, XSS, secrets, weak crypto, framework-specific misconfigurations, and more
• A single GitHub Action that gates pull requests with both scanners in one step

The only scanner you need in CI to cover the two main attack paths against your application.

See also: what is SAST?, CVSS, EPSS and KEV guide, free Snyk alternative.

This is dependency confusion. It doesn't have a CVE because the vulnerability isn't in the package — it's in the resolution logic of package managers. And it's just one flavour of supply-chain attack that pure CVE-based scanners completely miss.

Typosquatting: catch the typo, own the build

Typosquatting exploits the fact that developers type package names by hand. Publish expresss to npm (with three s's) and anyone who makes that common typo in npm install pulls down whatever you put in the package. Publish it with a convincing README, a few hundred weekly downloads from bots, and a malicious postinstall script, and you have a stealthy credential-stealing payload reaching developer machines and CI pipelines.

Real examples from npm's history:

• crossenv — a typosquat of cross-env that stole environment variables (which often contain API keys and tokens).
• getcookies — embedded in a legitimate-looking utility, exfiltrated browser cookies.
• loadsh — typosquat of lodash, one of the most-downloaded npm packages.
• reqeusts / reqests — multiple typosquats of the Python requests library.

The postinstall script is the key mechanism: npm runs it automatically when the package installs, before you've had a chance to read the code. A malicious postinstall can exfiltrate environment variables, install persistent backdoors, or modify other packages in node_modules.

Dependency confusion: the namespace collision attack

Dependency confusion exploits a different logic flaw. Many companies use a private npm registry (Artifactory, Nexus, GitHub Packages) alongside the public npm registry. When a package manager is told to look up a package, most configurations check the public registry if the private one doesn't have it — or check both and take the highest version.

Birsan's attack: find the name of an internal package (often visible in job postings, leaked config files, or error messages), publish a public package with the same name at a version number higher than the internal one (e.g. 99.0.0), and wait for build systems to install the "newer" public version.

The fix at the package manager level is to scope all internal packages under a private namespace (@company/internal-lib rather than internal-lib) and configure the registry to only allow scoped packages from the private registry. But this requires intentional configuration that many teams never got around to.

What detection looks like

CVE-based scanners can't catch these attacks because there's no CVE. The signals that matter:

Typosquat detection uses edit distance algorithms (Levenshtein, Damerau-Levenshtein) to find packages in your dependency tree whose names are suspiciously close to popular packages but aren't those packages. A package one character transposition away from lodash, express or react with no established publishing history is a strong signal.

Install-script presence is a risk signal on its own. Legitimate packages rarely need to run code at install time. A package with a postinstall script from an unknown publisher warrants scrutiny, especially if it appeared recently in your tree.

Maintainer and publish history signals: a package published 3 days ago with 0 dependents and a postinstall script that matches a popular name is almost certainly malicious or a testing mistake. Package maintainer changes on established packages — the XZ Utils backdoor mechanism — are similarly high-signal.

Version anomalies: a version number that skips from 1.0.4 to 99.0.0 is a classic dependency confusion marker.

DepWarden's approach

DepWarden flags typosquats using a Damerau-Levenshtein edit-distance check against a curated list of the most popular packages in each ecosystem. A package one keystroke away from a popular one that isn't that package gets a supply-chain finding (HIGH severity) with the specific match it resembles.

Install-script presence, maintainer-change signals and version anomalies from the OpenSSF Scorecard and supply-chain metadata are also surfaced — the signals that have no CVE but matter enormously in the real attack landscape.

The important point: these attacks happen before a CVE is ever filed, if one ever is. By the time there's a CVE for loadsh, the attack has already run. The only defence is catching the suspicious signal upstream.

Curious how many of these look-alike names are actually live on the registry right now? We checked every single-character typo of the 30 most popular npm and PyPI packages against the real registries and cross-referenced the hits against OSV's malicious-package database — see the full data.

What SAST scans

Static Application Security Testing (SAST) reads your source code — the JavaScript, Python, Java, Go, Ruby files that your team writes — and looks for security flaws in the code itself. SQL injection in a database query. A hardcoded AWS key in a config file. An XSS vector in a template. A call to MD5 where bcrypt should be. An HTTP endpoint that passes user input to a shell command.

SAST doesn't know about or care about which npm packages you installed. It's analyzing your code logic. A SAST tool will flag this:

const result = db.query(`SELECT * FROM users WHERE id = ${req.params.id}`);

...because the user-controlled value req.params.id flows directly into a SQL query without parameterization. It doesn't matter which database library you're using or whether that library has any CVEs. The bug is in your code.

What SCA scans

Software Composition Analysis (SCA) reads your dependency manifest — package.json, requirements.txt, pom.xml, go.mod — and checks every package (direct and transitive) against a vulnerability database like OSV. If you're running lodash@4.17.4, which has a known prototype pollution CVE, SCA flags it.

SCA doesn't analyze your code at all. It's checking the versions of the packages you depend on against a list of known-vulnerable versions. A perfect SAST run with zero findings can coexist with fifty SCA findings in your dependencies — and vice versa.

The blind spots in each

What SAST can't see:

• Vulnerabilities introduced by the open-source packages you import

• Supply-chain attacks with no CVE (typosquatting, dependency confusion)

• Runtime configuration mistakes in cloud infrastructure

• Bugs that only manifest under specific execution conditions

What SCA can't see:

• Security bugs in the code your team writes

• Hardcoded credentials in your own source files

• Weak cryptographic choices in your own logic

• Framework misconfigurations (CSRF disabled, DEBUG mode on, CORS wildcard)

The blind spots are almost perfectly complementary. An attacker probing your application has two main paths: exploit a bug in your code (SAST territory) or exploit a bug in a library you imported (SCA territory). Both scanners, covering both paths.

A concrete example: two reports, two attack surfaces

Imagine a Node.js API with these two problems:

Problem A (SAST territory): In controllers/user.js, you build a MongoDB query with string interpolation from req.query.username. This is a NoSQL injection vulnerability. It's in your code. No CVE exists for it. SCA will never find it.

Problem B (SCA territory): You depend on jsonwebtoken@8.5.1, which has a known algorithm confusion vulnerability (CVE-2022-23529). Your code calls jwt.verify() correctly. SAST may not flag it because the call looks correct in isolation — the vulnerability is in the library's internal implementation.

These are two real attack vectors. One scanner catches Problem A; the other catches Problem B. Running only SCA leaves NoSQL injection open. Running only SAST leaves the JWT library vulnerability open.

The combined CI gate

The most effective CI configuration runs both in parallel:

# GitHub Actions — combined SCA + SAST gate
- uses: Rushabh5000/dep-warden/cli@main
  with:
    file: package-lock.json   # SCA: dependency scan
    sast-dir: ./src           # SAST: static analysis
    fail-on: high
    sast-fail-on: high

This single step:

• Parses package-lock.json, resolves the full transitive dependency tree, checks OSV/KEV/EPSS for vulnerabilities and typosquats

• Walks ./src, detects languages, runs pattern + taint analysis across all source files against 300+ security rules

• Fails the build if either scan produces a HIGH or CRITICAL finding

Two scan types, one gate, no account required.

Prioritization across both

When findings come from both SAST and SCA, the combined priority order:

1. SCA: KEV-listed + direct dependency + fix available — attackers are actively using this, you can fix it now

2. SAST: HIGH-confidence injection/RCE finding — user input confirmed flowing to a dangerous sink

3. SCA: HIGH CVSS + EPSS > 0.10 + fix available — elevated exploitation probability

4. SAST: hardcoded credential — immediate exposure risk if it reaches a repo

5. Everything else — triage by severity and confidence, don't block releases on MEDIUM/LOW

What DepWarden gives you

DepWarden combines both scanners in one tool, free and without an account:

• SCA across 11 package ecosystems (npm, PyPI, Maven, Gradle, Go, Cargo, Composer, RubyGems, NuGet, Dart, Swift) with OSV/KEV/EPSS enrichment and exploitability-first prioritization

• SAST across 15 languages and IaC formats, with 300+ security rules covering injection, XSS, secrets, weak crypto, framework-specific misconfigurations, and more

• A single GitHub Action that gates pull requests with both scanners in one step

The only scanner you need in CI to cover the two main attack paths against your application.

See also: what is SAST?, CVSS, EPSS and KEV guide, free Snyk alternative.