Repo jacking on bundler.io: open supply chain attack

What happened

A researcher reported on HackerOne that bundler.io — the official documentation site for Bundler, Ruby's dependency manager — was linking to two GitHub repositories (`rubygems/bundler-site` and `rubygems/bundler.github.io`) whose original username had been freed after an ownership change in the organization.

The bug class is repo jacking (*dependency repository hijacking*, a form of *supply chain attack* — an attack that compromises the software supply chain rather than the final target directly). The mechanism is straightforward: when a GitHub user or organization changes their name, the old username immediately becomes available for anyone to register. If authoritative sites — like official documentation for a dependency manager — keep pointing to that old URL, anyone who claims that username can *replace the content that every link in the ecosystem references*.

The report also identified an open redirect (a trusted-domain URL that bounces users to any destination the attacker chooses) on the bundler.io domain itself, chaining both vectors to amplify potential impact.

Why it matters

This pattern isn't unique to RubyGems. The same vector exists in any project whose documentation, README, or website links to GitHub repos under usernames that have changed hands at some point. The repo doesn't even need to contain directly executable code: serving install scripts, copy-pasteable snippets, or being listed as a trusted source is enough.

The attack surface is large. Thousands of open source projects have gone through merges, renames, or account abandonments. IOCs (technical indicators that reveal an attack — here, claimed repos with unexpected content) are hard to detect unless you actively monitor what sits behind the links you publish.

The open redirect adds another angle: even without a full repo jacking, an attacker can abuse redirects on trusted domains to bypass anti-phishing filters or chain into social engineering campaigns.

The bug class combines a low barrier to entry (registering a GitHub username is free and trivial) with potentially critical impact (code injection into projects that trust those references). It's the kind of finding that bug bounty programs tend to underestimate until someone exploits it in production.

What to do

If you maintain documentation or a project site:

• Audit every external GitHub link in your docs, README, and website today. Verify that usernames are still active and belong to the right entity.
• Set up alerts (GitHub Dependabot, monitoring scripts) to detect unexpected changes in repositories you reference.
• Migrate links to commit-hash URLs or forks under your own organization for any externally-referenced repo that is critical to your trust chain.

If you hunt bugs:

• Search `web.archive.org` or `github.com/search` for usernames referenced in popular project docs that no longer exist as active organizations.
• Check if the target domain has endpoints with parameters like `?url=`, `?redirect=`, `?next=`, `?return_to=` — prime candidates for open redirect.
• Chain repo jacking + open redirect to raise severity: the redirect can make the official site serve as a bridge to the malicious repo.

If you run a SOC (Security Operations Center — the team that monitors for active threats):

• Include dependency repository monitoring in your threat model for internal projects that use GitHub-based package managers.

Repo jacking has been documented for years but keeps showing up in mature programs. The reason: teams audit code, not links. A link in docs carries the same damage potential as a direct dependency if it sits in the trust chain.