Repojacking

Repojacking is a software supply chain attack in which a threat actor claims an abandoned or renamed repository namespace to distribute malicious code to unsuspecting downstream consumers. Because open-source ecosystems depend on shared, publicly accessible packages, a single hijacked namespace can compromise thousands of projects simultaneously.

The threat is especially dangerous because it exploits trust rather than technical vulnerabilities. Developers, build systems, and CI/CD pipelines all assume that a familiar package name still points to legitimate code. Organizations of all sizes that rely on open-source dependencies are at risk.

What Is Repojacking?

Repojacking occurs when a public repository username or package name is abandoned, deleted, or freed by a username change, and a malicious actor re-registers it. Most version control platforms and package registries permit namespace reuse once a name becomes available, creating an exploitable window.

The core mechanism is straightforward. Downstream projects that still reference the old namespace will automatically resolve to the attacker-controlled repository. No code change is needed on the victim's side, making this a passive and particularly insidious form of supply chain compromise.

How Repojacking Attacks Work

The attack follows a predictable lifecycle:

• Identify an abandoned or renamed namespace that still has active downstream dependents
• Register the freed username or package name on the target platform
• Publish a malicious package that mimics the original in structure and naming
• Wait passively as automated dependency resolution delivers the payload to victims

Attackers rely on automated dependency resolution to scale their reach without ongoing effort. Once the name is claimed and the package published, every downstream project that fetches the dependency becomes a potential victim.

Popularity metrics like download counts, GitHub stars, and reverse-dependency graphs help attackers prioritize high-value targets. A namespace with millions of weekly downloads delivers far greater impact than an obscure one.

Why Repojacking Is Difficult to Detect

Malicious packages in repojacking attacks are typically crafted to mirror the legitimate original in directory structure, file naming, and even partial functionality. This makes casual manual inspection unreliable as a detection method.

CI/CD pipelines and automated build systems fetch dependencies programmatically, with no human reviewing what is actually downloaded. By the time malicious code executes, it may have already exfiltrated credentials or introduced backdoors into the build artifact.

The deepest challenge is misplaced trust. Developers assume a package that has safely resolved dozens of times before remains safe. This assumption breaks silently when namespace ownership changes, with no visible warning during installation or build execution.

How to Protect Against Repojacking

Several practical controls reduce repojacking exposure:

• Pin dependencies to specific commit hashes or cryptographic digests rather than mutable version tags or branch names
• Use software composition analysis tools that detect namespace ownership changes or unexpected publisher transfers in your dependency graph
• Monitor upstream repositories for ownership activity and configure alerts through dependency management platforms such as Dependabot or Renovate
• Audit your dependency tree regularly to identify packages referencing accounts that no longer exist on the original platform

Repojacking vs. Other Supply Chain Attacks

Repojacking is frequently confused with related attack types, but the distinctions matter for applying the right defenses.

• Typosquatting uses a deliberately misspelled name to trick developers into installing the wrong package
• Dependency confusion exploits the priority logic of package managers to substitute a public package for a private internal one
• Repojacking occupies the exact legitimate namespace, meaning no developer error or configuration flaw is required to become a victim

Understanding these distinctions enables security teams to apply targeted mitigations. Typosquatting is addressed through allowlists; dependency confusion through private registry scoping; repojacking through namespace monitoring and digest pinning.

FAQ

What is the difference between repojacking and typosquatting?

Typosquatting registers a name that looks similar to a legitimate package, relying on developer error to attract installs. Repojacking claims the exact legitimate namespace after it is abandoned. No spelling mistake is involved in repojacking, making it harder to catch through simple name-inspection practices or automated typo-detection tools.

Which package ecosystems are most vulnerable to repojacking?

npm, PyPI, and GitHub are frequently cited as high-risk ecosystems due to their permissive namespace reuse policies and massive scale. Any registry that allows re-registration of previously used names without additional verification creates conditions where repojacking attacks can succeed against projects with lingering references to old namespaces.

How can I check if any of my dependencies have been repojacked?

Use software composition analysis tools such as Socket, Snyk, or OWASP Dependency-Check to audit your dependency graph. Cross-reference package ownership against historical records and watch for unexpected publisher changes. Reviewing your lock files against known-good digests also reveals tampering before malicious code reaches your build environment.

Does pinning dependency versions fully protect against repojacking?

Version pinning alone is not sufficient. A pinned version tag can still resolve to attacker-controlled code if the namespace has changed ownership. Pinning to cryptographic digests or specific commit hashes provides stronger protection, but must be combined with regular audits and SCA tooling to be effective.

What are package registries doing to prevent repojacking?

Some registries, including npm, have introduced policies that reserve popular package namespaces after deletion to prevent immediate re-registration. Others require additional verification for high-download packages. However, protections vary widely across ecosystems, and no registry has fully eliminated the risk, making client-side controls essential.

‍