What Is Package Name Squatting? Definition & Examples

Package name squatting is when an attacker registers a software package name that looks legitimate, hoping developers will install it by mistake. In software supply chain security, this can lead to malicious code being pulled into builds or environments through package managers, dependencies, or typosquatting of trusted package names.

What package name squatting is

Package name squatting is a software supply chain attack pattern where an actor registers a package name that looks legitimate so developers or automation install it by mistake. The risk comes from trust placed in package registries, dependency resolution, and developer habit rather than from the package name itself.

Why package name squatting works

The technique succeeds because package ecosystems reward convenience: search, autocomplete, dependency managers, and copy-paste workflows make it easy to pick a near-match name. A typo, an abandoned internal reference, or a rushed dependency review can be enough for a malicious package to enter a build, test environment, or even a production release pipeline.

In practice, the attacker only needs the package to look plausible long enough for installation to occur. Once that happens, malicious code can run during install, import, build, or runtime depending on the ecosystem and package lifecycle.

How package name squatting affects builds and environments

When a squatted package is pulled into a build, it can compromise source integrity, inject malicious behavior, or exfiltrate secrets from the development environment. That makes the impact broader than a single workstation, because modern pipelines often reuse credentials, access tokens, and build artifacts across multiple systems.

Package managers and transitive dependencies also widen the blast radius. A malicious dependency can be introduced indirectly, which means the package that looks suspicious is not always the one that is actually imported by the application.

Security teams often treat this as a supply chain integrity issue first and an application compromise issue second. The same package name can be harmless in one registry and dangerous in another, so provenance and namespace awareness matter as much as code review.

How to assess and reduce exposure

Exposure checks should start with a complete inventory of the packages your organisation actually uses, including direct and transitive dependencies, internal namespaces, and any private registries. If a package name appears in source code, lockfiles, build manifests, or automation scripts, verify that it resolves to the expected publisher and repository before trusting it.

Public guidance from OpenSSF is useful here because the problem is rooted in open source package trust, namespace hygiene, and supply chain hardening. If you already know a package has been abused, the most practical next step is to compare your dependency inventory against registry metadata and vendor advisories rather than relying on name recognition alone.

Teams should also watch for internet exposure of developer endpoints, build runners, and package mirror infrastructure, because squatting attacks become more dangerous when attackers can also reach the systems that consume the malicious package. If a package can be installed automatically, it can also be introduced automatically.

Response, detection, and recovery after suspected installation

If a squatted package was installed, treat the event as a potential compromise of the build or developer environment. Review install logs, dependency lockfiles, package hashes, CI/CD job history, and any network or file activity that occurred during installation or build execution.

The response should focus on containment first: remove the suspicious package, isolate affected build agents or developer machines, and verify whether the package executed code or accessed secrets. If the package touched credentials, tokens, signing material, or deployment access, rotate those secrets and reissue any trust material that may have been exposed.

Post-incident review should confirm whether the package entered through a typo, an abandoned namespace, a dependency confusion path, or a mirrored registry. That distinction matters because each failure mode points to a different control gap in naming, publishing, review, or dependency governance.

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 CSF 2.0, OWASP ASVS and OWASP SAMM set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
SLSA	Software supply chain integrity	Package name squatting threatens build provenance and artifact integrity through malicious dependencies.
Recommendation — Strengthen dependency provenance checks and validate build inputs before promoting artifacts.
CIS Controls v8	CIS-15 — Service Provider Management	Package registries and third-party packages introduce supplier risk into the software supply chain.
Recommendation — Assess third-party package sources and restrict trusted publishers for dependency intake.
NIST CSF 2.0	PR.DS-08 — Integrity checking mechanisms are used to verify software, firmware, and information integrity	Squatted packages undermine software integrity and require verification of dependency authenticity.
Recommendation — Verify package integrity and provenance before allowing dependencies into builds.
OWASP ASVS	V15 — Secure Coding and Architecture	Developer workflows that accept untrusted packages belong to secure software architecture and dependency handling.
Recommendation — Design dependency intake to reject unexpected or untrusted packages by default.
OWASP SAMM	Software Deployment	Package squatting is prevented through secure release and dependency practices in the software delivery lifecycle.
Recommendation — Embed dependency review and release validation into software delivery practices.

Package Name Squatting