GitHub automatically redirects renamed usernames — until someone claims the old one. I built a scanner to find and hijack those links.

This post builds on my earlier write-up about scanning GitHub repositories for broken links using Bash scripts and local cloning. If you haven’t seen it yet, check out:

👉 How I Made $20K+ From Broken Link Hijacking on GitHub Repos

While running my broken link scanner on GitHub repositories, I came across a strange case.

Some links like:

https://github.com/olduser/oldrepo

would redirect to a new username, such as:

https://github.com/newuser/oldrepo

But when I visited just:

https://github.com/olduser

it returned a 404 — indicating the old username was unclaimed.

That’s when I realized something subtle but dangerous:

GitHub redirects repository links after a username rename — but only while the old username stays unclaimed.

If someone registers the old username, the redirect breaks silently, and the old link now points to your own profile and repo.

This meant that any repo link using the old format was now hijackable.

was returning a 404, even though I knew the repo still existed under a different username. Manually visiting the new profile showed the repo was alive.

That’s when I discovered something interesting — and exploitable.

This opened up a sneaky vector:

Register the old username, recreate the repo name, and serve your own content.

If the old username and repo were still referenced in:

• READMEs
• Helm or Docker install commands
• CI/CD pipelines
• Build scripts
• Third-party documentation

…you now had control over a live dependency link.

I modified my earlier Bash-based scanner to:

I used this simple one liner to format the github urls

cat urls.txt | grep github.com | awk -F[/] ‘{print $1"//”$3"/”$4}’ | sort | uniq

1. Extract all GitHub links from cloned repos.
2. Reduce them to just the username part (github.com/username). I did that using the above one liner command.
3. Check if the profile returns a 404.
4. If yes → try to register the username.
5. Recreate any repos previously referenced under that name.

Once registered, I’d add a simple README.md like:

“This repo was taken over for responsible disclosure. No malicious content is served.”

This gave me safe, repeatable proof-of-concepts for reporting.

This method helped me find and responsibly report multiple hijackable GitHub usernames across popular orgs. Some were small projects, but others were:

• Critical internal tools
• Installer scripts used in automation
• Dependencies referenced across dozens of other projects

Several of these were accepted as high severity, with bounties ranging from $500 to $10,000, depending on the context.

If you search GitHub for:

“Takeover by codermak”

…you’ll still find traces of this technique from back then.

This method became one of my most successful strategies — and it all started from a single redirect that shouldn’t have worked.

This attack vector is still very much alive. Many GitHub repositories continue to rely on URLs tied to old usernames that now return 404 or silently redirect. If those old usernames are released and claimed by someone else, it opens the door for malicious code injection, credential harvesting, and supply chain compromise. Several companies remain affected even today, making this a high-impact issue worth continuous monitoring — and still rewarding for bounty hunters who know where to look.