Package Name Masquerading is a software supply chain attack where a malicious package is given a name that closely resembles a legitimate one. The attacker relies on typos, lookalike naming, or namespace confusion so developers or build systems install the wrong package and import untrusted code.
What Package Name Masquerading Means in Practice
Package name masquerading is a supply chain deception technique, not just a typo problem. The attacker chooses a package name that is close enough to a trusted one, then depends on search, copy-paste, autocomplete, human review gaps, or build automation to pull in the malicious dependency.
The danger comes from the trust developers place in package registries and dependency graphs. Once a wrong package is installed, untrusted code can enter the build, test, or runtime environment with the same legitimacy as a normal dependency.
Why Name Similarity Is Effective
Name similarity works because package ecosystems are optimised for speed and reuse. Small changes, such as a swapped letter, added prefix, altered namespace, or visually confusable character, can be enough to mislead a person or tool that is not validating the source carefully.
This is especially effective when teams consume many third-party packages, rely on indirect dependencies, or approve packages based on name recognition alone. A malicious package does not need to look perfect, it only needs to look plausible at the point of selection.
NHIMG’s T1036 Masquerading Defensive Guide is the most direct internal reference for how lookalike naming and related masquerading patterns are detected and stopped.
How Teams Check Exposure and Reduce the Chance of Mistakes
Exposure starts with knowing which registries, mirrors, package feeds, and build pipelines are allowed to source software. If package selection depends on manual search or ad hoc developer judgement, the chance of choosing a lookalike name rises sharply.
Practical checking focuses on inventory and provenance: which packages are approved, which versions are in use, which projects pull them in transitively, and whether the package source matches the expected publisher or namespace. The right control question is not only “Does this name exist?” but “Is this the exact package we intended to trust?”
Open source supply chain guidance from OpenSSF is useful here because it centers the broader trust problem around package integrity, provenance, and ecosystem hygiene.
Remediation, Detection, and Post-Install Review
When a suspicious package has already been installed, response should assume the code may have executed and may have touched build artifacts, secrets, or developer credentials. The immediate question is whether the package was only downloaded or whether it was imported, built, or run in a context with broader access.
Detection should look for abnormal package metadata, unexpected maintainers, recent namespace lookalikes, suspicious post-install scripts, and file or network activity that does not match the expected dependency. After removal, review the affected environment for altered artifacts, leaked tokens, poisoned caches, and any downstream systems that may have consumed the tainted build output.
NHIMG’s LiteLLM PyPI package breach is a direct example of why malicious packages are not just a naming issue, but a concrete path to credential theft and wider supply chain harm.
How to Think About Package Name Masquerading Operationally
Package name masquerading is best treated as a trust boundary problem. The core control objective is to make package selection deterministic, verifiable, and resistant to visual confusion, rather than depending on memory or convenience.
Teams that manage dependencies well usually combine naming scrutiny with source allowlisting, dependency review, and build-time verification. That approach reduces the chance that a package gets trusted simply because it resembles a legitimate one.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA, CIS Controls v8, NIST SP 800-53 Rev 5, OWASP ASVS and OWASP SAMM set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply chain integrity | Package name masquerading undermines artifact provenance and dependency trust. |
| Recommendation — Require verified provenance for dependencies before they enter the build pipeline. | ||
| CIS Controls v8 | CIS-15 — Service Provider Management | Third-party package trust depends on controlling external software sources and dependencies. |
| Recommendation — Vet and continuously monitor third-party software sources before allowing them into production. | ||
| NIST SP 800-53 Rev 5 | SA-12 — Supply Chain Protection | This attack is a software supply chain deception that targets trusted acquisition paths. |
| Recommendation — Apply supply chain protection controls to verify the origin and integrity of acquired software. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Developers must avoid unsafe dependency selection and trust assumptions in software architecture. |
| Recommendation — Design dependency workflows that verify package identity before code is accepted. | ||
| OWASP SAMM | Architecture Assessment — Architecture Assessment | Secure software development must assess dependency trust and package-selection risk. |
| Recommendation — Assess dependency acquisition paths for lookalike and substitution risk during design reviews. | ||
Related resources from NHI Mgmt Group
- Should organisations allow package execution based on name similarity alone?
- Who is accountable when a public package hijacks an internal dependency name?
- How should security teams respond when a Node package uses autostart persistence and process masquerading on Windows endpoints?
- What should organisations do when they find a hallucinated package name in an agent skill or automation script?
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