Repojacking

Expanded Definition

Repojacking is a supply chain attack that exploits trust in a repository’s historical name, path, or namespace after the original owner has deleted or renamed it. The attacker registers the abandoned identifier and publishes code that appears to come from the legitimate source, which can mislead dependency managers, package installers, and human reviewers. In practice, the risk is not limited to one platform. Any ecosystem that resolves packages or code references by name can be exposed when namespace reuse is allowed or when old links remain embedded in build scripts, documentation, or pinned dependencies.

At NHI Management Group, repojacking is best understood as a trust continuity problem. The issue is not simply that a repository exists, but that downstream systems continue to trust a label that no longer has the same ownership. That makes it closely related to software provenance, dependency integrity, and release governance. Standards-based control thinking, including NIST SP 800-53 Rev 5 Security and Privacy Controls, helps teams treat repository references as controlled assets rather than informal shortcuts. The most common misapplication is assuming that deleting or renaming a repository ends the security obligation, when the old namespace may still be actively trusted by downstream consumers.

Examples and Use Cases

Implementing protections against repojacking rigorously often introduces release and coordination overhead, requiring organisations to weigh namespace flexibility against the cost of preserving trust in external references.

• A public GitHub repository is renamed, but package manifests in downstream projects still point to the old path, allowing an attacker to claim the freed namespace and serve altered code.
• A closed-source project deletes an old repository after a migration, but documentation, CI pipelines, and dependency locks still reference the original location, leaving a long-lived trust gap.
• An open-source maintainer transfers ownership incorrectly, and a third party acquires a similar or previously used repository name, creating confusion during automated builds and manual code review.
• A software team embeds a VCS URL in deployment tooling without monitoring namespace status, so a later namespace reallocation goes unnoticed until new builds fetch malicious content.
• Security and platform teams track repository ownership, rename history, and dependency provenance using controls aligned with NIST SP 800-53 Rev 5 Security and Privacy Controls and internal software supply chain policy.

Repojacking is often easier to exploit where dependency resolution is automated but ownership verification is weak, especially in fast-moving development environments that prioritise convenience over namespace governance.

Why It Matters for Security Teams

Repojacking matters because it turns a routine repository lifecycle event into an integrity problem for the broader software supply chain. If security teams do not track deleted, renamed, or transferred repositories, they can lose control of the trust path while downstream systems continue to install, build, or deploy from the old reference. That creates a channel for malicious code insertion, credential theft, or backdoored updates without needing to compromise the original maintainer account.

The governance lesson is that repository names must be treated as security-relevant identifiers, not disposable labels. Teams should monitor namespace reuse, maintain redirect and deprecation controls, review dependency provenance, and remove stale source references from build systems and package metadata. Supply chain assurance guidance also connects to broader control sets such as NIST SP 800-53 Rev 5 Security and Privacy Controls and software integrity practices. Organisations typically encounter the impact only after a build starts pulling from a hijacked path, at which point repojacking becomes operationally unavoidable to address.