91% of Malicious Open Source Packages Now Use Realistic Names, Not Typos

Traditional typosquatting — registering a package with a misspelled name to catch developers who make typing errors — now represents only 9% of malicious open source packages. The remaining 91% use realistic naming variants: suffixes like -plugin, -config, or -sdk; internal tool impersonation; dependency confusion; and version mimicry. Sonatype researchers analyzing 4,309 malicious packages published findings in May 2026 that confirm a fundamental shift in how supply chain attackers reach developer machines — and why defenses built around detecting misspelled names are now largely ineffective.

// 01 Package Impersonation: Technical Details

The shift from typosquatting to naming-variant attacks represents a maturing of the attacker playbook. Typosquatting required developers to make an error — mistyping lodash as lodahs. Naming-variant attacks target developers doing everything correctly: searching for a plugin, configuration helper, or SDK wrapper for a library they already use and trust.

Sonatype’s security research team analyzed 4,309 confirmed malicious packages across npm (Node Package Manager — the primary package registry for JavaScript and Node.js) and PyPI (Python Package Index — the primary package registry for Python) and found the following distribution of attack strategies:

• Suffix addition (43.6%): Appending -plugin, -config, -sdk, -cli, or -utils to a legitimate package name. Example: eslint-plugin-security-audit registering alongside the real eslint-plugin-security. Developers searching for security tooling in an ESLint ecosystem would find this package in search results.
• Dependency confusion (23%): Registering a public package name identical to a private internal package. Package managers may resolve the public registry version in preference to an organization’s private registry — particularly in environments without explicit scoping configured. This technique was originally described by security researcher Alex Birsan in 2021 and remains effective in many CI/CD pipelines.
• Internal tool impersonation: Registering names that match known internal tooling conventions of specific organizations. Sonatype found packages mimicking Asurion, PayPal Zettle, and Airbnb internal dependencies — suggesting targeted reconnaissance into specific organizations’ dependency trees before registration.
• Version mimicry: Publishing packages like @bitwarden/cli at version 2026.4.0 alongside the real Bitwarden CLI under the correct @bitwarden/ scope, exploiting developers who verify the package name but not the publisher scope or NPM account backing it.

Once installed, the malicious packages perform host and secret exfiltration (most common), drop further-stage payloads, or install persistent backdoors. Specific campaigns found packages targeting Windows systems with RAT (Remote Access Trojan — malware giving an attacker remote control over an infected machine) malware and wallet stealers targeting cryptocurrency credentials. npm is the primary target, with PyPI as a secondary affected registry.

The packages targeting React (540 malicious packages identified) and ESLint plugins indicate attackers study which frameworks have the most active plugin ecosystems, then seed those namespaces with plausible-sounding additions that appear in search results alongside legitimate tools.

// 02 Exploitation Status and Threat Landscape

This is not a theoretical risk. In April 2026, DPRK-linked hackers distributed over 1,700 malicious packages across npm, PyPI, Go, and Rust using naming-variant conventions, targeting cryptocurrency firms and blockchain developers. The Mini Shai-Hulud worm (May 2026) compromised TanStack, Mistral AI, and Guardrails AI packages on npm, demonstrating that naming-variant attacks can achieve worm-like propagation through the npm dependency graph — packages that depend on a compromised package become vectors for further spread.

MITRE ATT&CK technique T1195.001 (Compromise Software Supply Chain — Software Dependencies and Development Tools) categorizes this attack pattern. It has become one of the most productive infection vectors for both financially motivated actors and state-sponsored groups because a single malicious package can persist undetected in a CI/CD pipeline, running on production infrastructure with every build — without any additional attacker interaction.

The economics favor attackers: register dozens of plausible package names, wait for organic installs driven by search results or documentation discovery, and receive a notification when the payload fires. No active targeting required.

// 03 Who Is Affected

Any development team that:

• Uses npm or PyPI packages in production software or CI/CD pipelines
• Has team members who install new packages based on search results for plugin or configuration helpers
• Has large dependency trees without strict package allowlisting (JavaScript and TypeScript ecosystems are particularly exposed)
• Has weak code review processes for changes to package.json or requirements.txt

Risk is elevated for organizations whose internal package naming conventions have been exposed through public repositories, leaked CI/CD configuration files, or employee LinkedIn posts referencing internal tooling — because internal tool impersonation requires that reconnaissance.

// 04 What You Should Do Right Now

• Verify publisher scope, not just package name. Before installing any npm package, confirm the publisher scope matches the expected organization (e.g., @angular/ vs. an unscoped angular-*). Check the package’s publish history and author list on npmjs.com before installation.
• Add friction for first-seen dependencies in CI/CD. Configure your package manager or CI system to flag packages that have never appeared in your dependency tree before. A human review step for net-new dependencies catches impersonation before it reaches production.
• Maintain an allowlist for framework-adjacent packages. For major frameworks (React, ESLint, Tailwind, Vue), maintain an approved package list and block installation of any framework-adjacent package not on it.
• Scan with SCA tools in every CI pipeline. SCA (Software Composition Analysis — automated scanning of your dependency graph for known vulnerabilities and malicious packages) tools like Sonatype Lifecycle, Snyk, or Socket detect behavioral signals (post-install scripts, network calls, obfuscated code) that naming heuristics miss.
• Alert on post-install scripts. Malicious packages commonly use npm postinstall hooks to execute payloads immediately on installation. Audit and block packages that run arbitrary commands at install time unless explicitly reviewed.
• Implement a private registry proxy. Route all npm and PyPI traffic through a private registry (Artifactory, AWS CodeArtifact, Nexus) and allowlist only reviewed packages. This eliminates dependency confusion attacks and limits exposure to newly registered malicious packages.

// 05 Background: Understanding the Risk

The shift to realistic naming is a direct response to improved typosquatting detection. Package registries and security tools have gotten better at catching lodahs-style registrations through edit-distance matching. Naming-variant attacks defeat those heuristics because the package names are spelled correctly — they are simply plausible additions to a legitimate namespace, and edit-distance algorithms score them as distinct packages, not near-duplicates.

The Sonatype research recommends assessing suspicious packages at the campaign and publisher level, not individually. If a publisher has registered ten packages within 48 hours that share payload infrastructure, the entire publisher account is malicious — including packages that currently appear clean. Traditional one-package-at-a-time review misses this signal.

The 2026 data also reveals increasing specificity in targeting. Internal tool impersonation requires knowing the target organization’s private package naming conventions — information that leaks through public GitHub repositories, accidentally committed CI/CD configuration files, and job postings that reference internal tooling by name. This suggests some campaigns now have a reconnaissance phase preceding package registration, moving the threat closer to targeted supply chain attacks than opportunistic squatting.

Broader context: Sonatype’s 2026 research identifies 454,000+ total malicious packages discovered across registries — a 75% increase year over year. The open source supply chain has become one of the primary attack surfaces for both commodity malware distribution and sophisticated nation-state campaigns precisely because it sits upstream of everything: a malicious dependency runs in development environments, CI systems, container images, and production services simultaneously.

// 06 Conclusion

Sonatype’s analysis of 4,309 malicious packages confirms that the supply chain attack playbook has fundamentally changed: 91% of malicious packages now use realistic naming variants rather than typosquatting. Teams whose defenses rely on detecting misspelled names are now exposed to the overwhelming majority of the threat. Implement publisher scope verification, enforce allowlists for framework-adjacent packages, add CI friction for first-seen dependencies, and route all package traffic through a private registry proxy.