Package name confusion is a software supply chain attack where a developer installs the wrong package because its name closely resembles a legitimate one. It exploits typos, lookalike names or namespace mistakes in package registries, leading to malicious code being pulled into a build or runtime.
What package name confusion is
Package name confusion is a supply chain attack on software dependency resolution. The attacker relies on developers, build systems, or package managers selecting the wrong artifact because the name is close to a legitimate package, so malicious code can enter a build, test environment, or production runtime before anyone notices the mistake.
Unlike direct compromise of a trusted package, the attack abuses human expectation and registry search behaviour. The danger is that the package may look plausibly correct, especially in large ecosystems where many packages, namespaces, and mirrors exist.
How it happens in package registries
Confusion can be created through typos, lookalike names, namespace slippage, or small changes that are easy to miss during dependency review. A developer may copy a package name from documentation, autocomplete, or a search result and install an imposter that is registered and available, but not the intended component.
This is why registry hygiene matters. Package naming rules, namespace ownership, publishing workflows, and search ranking all influence whether a misleading package can be discovered and pulled into a project. The same weakness can affect dependency manifests, lockfiles, and container builds when names are resolved automatically.
Why package name confusion is dangerous
Once the wrong package is pulled in, the malicious code can run with the same trust that the build or runtime grants to any dependency. That can expose source code, environment variables, signing material, API tokens, or other secrets, and it can also create persistence inside build pipelines or deployed applications.
Because the package may be installed during routine development work, the compromise path can look normal in logs and dependency graphs. The attack is especially damaging when the fake package reaches a CI pipeline, because the resulting artifact may be distributed widely before the mistake is detected.
How to reduce and detect the risk
Exposure starts with inventory and verification: know which registries, namespaces, and dependency sources your teams are allowed to use, and check package provenance before installation. For high-value software supply chain controls, OpenSSF is a useful authority for secure open source consumption and supply chain hardening practices.
Teams should also review package name changes, maintain allowlists for approved dependencies, and use build controls that pin exact artifacts rather than relying on vague search behaviour. The broader lesson is to treat dependency selection as a trust decision, not a convenience action. NHIMG’s LiteLLM PyPI package breach shows how a misleading package event can turn into credential theft and downstream supply chain exposure.
When a suspicious package is discovered, investigate whether it was installed in development, CI, or production, then review whether any secrets, tokens, or signing keys may have been exposed through that dependency path. If compromise is confirmed, rotate the material the package could access and verify the integrity of the affected builds and releases.
Risk and Threat Considerations
Package name confusion is dangerous because it turns ordinary dependency handling into a trust-abuse path. Attackers do not need to break a cryptographic control if they can get a developer or automated pipeline to choose the wrong package name and execute the attacker-controlled code.
Failure mechanism: A lookalike package is registered, discovered, and installed through a naming mistake, search confusion, or namespace assumption, after which the malicious payload executes with normal build or runtime privileges.
Impact: The result can be source code theft, secret exposure, compromised build integrity, poisoned releases, or a wider software supply chain incident if the package is reused across projects.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5, SLSA and OWASP SAMM set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-15 — Service Provider Management | Package registries are third-party software sources that require supplier and dependency governance. |
| Recommendation — Approve and monitor software suppliers and dependency sources before use. | ||
| NIST SP 800-53 Rev 5 | SA-12 — Supply Chain Protection | Package name confusion is a software supply chain integrity problem involving sourced code and artifacts. |
| Recommendation — Verify dependency provenance and restrict software acquisition to trusted sources. | ||
| SLSA | Supply chain integrity | The term concerns artifact provenance and trusted build inputs across the software supply chain. |
| Recommendation — Strengthen build provenance and require trusted artifact lineage for dependencies. | ||
| OWASP SAMM | Software Assurance Maturity Model | Teams need maturity practices for dependency governance and secure software acquisition. |
| Recommendation — Embed dependency review and supply chain assurance into the development lifecycle. | ||
| MITRE ATT&CK | T1195 — Supply Chain Compromise | The attack pattern is a form of adversarial software supply chain compromise. |
| Recommendation — Map suspicious dependency activity to supply chain compromise and investigate affected builds. | ||
Practitioner Guidance
Why practitioners should care: Dependency resolution is one of the easiest places for a supply chain attack to enter a software estate because the wrong package can look legitimate enough to pass casual review. Treat package selection as an approval step, especially for new dependencies, rarely used namespaces, and registry searches that return similarly named results.
What to watch for: Unexpected package renames, new maintainers, unusual download spikes, and dependencies that differ from documentation by only one character or namespace segment should be treated as warning signs. Where package ecosystems are heavily used, teams should also be alert to autocomplete and copy-paste errors that silently change the resolved artifact.
Related resources from NHI Mgmt Group
- Why do package hallucinations and dependency confusion increase supply chain risk?
- Why do package impersonation and dependency confusion still work against mature teams?
- Should organisations allow package execution based on name similarity alone?
- Who is accountable when a public package hijacks an internal dependency name?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org