Repojacking

Repojacking (repository hijacking) is a supply chain attack that exploits what happens to a code repository's address after its owner renames or deletes their account. On platforms like GitHub, when a user or organization changes its name, the old name eventually becomes available for anyone to register. An attacker who claims it can recreate the original repository path — and everything that still points at that path now fetches code the attacker controls.

How it works

Software references repositories by URL in thousands of places that nobody revisits: dependency manifests that install straight from GitHub, build scripts, container files, documentation, CI workflows, even go get import paths. When the original project moves — a maintainer renames their handle, a company gets acquired, an open source project migrates — those stale references keep working because the platform redirects the old URL to the new one. But the redirect breaks the moment someone registers the abandoned old name. The attacker does exactly that, recreates a repository with the expected name, and fills it with a backdoored copy of the original code. Builds that "worked yesterday" now pull from the hijacked location, and the compromise inherits all the trust of the original project.

The pattern is a cousin of dependency confusion: both weaponize the gap between what a name meant when it was written down and what it resolves to today. Platforms have added partial protections — popular namespaces may be retired rather than released — but research teams keep finding thousands of vulnerable references, because the stale links live in the victims' own files, not on the platform.

How to defend against it

• Audit direct repository references. Find dependencies installed from URLs rather than registries, and replace them with registry packages or pinned commit hashes — a hash cannot be silently swapped.
• Keep retired names. When your organization renames its account or archives a project, retain ownership of the old namespace indefinitely.
• Watch your own footprint. Treat renamed handles and migrated projects as security events, not housekeeping — the same lifecycle discipline that catches orphaned accounts.
• Include it in developer training. Engineers who review dependencies should know that a familiar URL is not a guarantee of a familiar owner; see our guide to security awareness for developers.