Typosquatting is now a well-known exploit, whereby malicious actors register domains or package names that are visually similar to popular ones. Examples include misspelling express as “expresss” - a mistake we’ve all made when typing too fast under pressure. Normally, when you make a typo retrieving a software package, you just get a build error since the package doesn’t exist. However, adversaries pick up on these subtle behaviours and in the process publish package names, deliberately containing malware, knowing someone is inevitably going to make this mistake at some point.

We just saw this threat has escalated. Instead of just mimicking individual package names in ecosystems like npm or PyPI, attackers are squatting on entire container registry domains!

This really is an easy mistake to make

An alarming post by Bruno Schaatsbergen on Hacker News highlights this issue. A user discovered an active container registry at ghrc.io, not ghcr.io, which is the GitHub Container Registry. The poster warns: “I'm not sure who owns it, but be careful”. And it makes sense, unless investigated further, it’s unclear what is currently being distributed via this fake registry. Funny side note, if you go to the fake (ghrc.io) instead of the correct Github Container Registry address, it displays one of those generic default Nginx web server pages instead of the expected Github redirect (https://github.com/features/actions).

Again, simple typo, swapping the positions of “r” and “c” leads to a completely different registry. Given that container workflows often operate in scripts or automated pipelines, a single-character mistake can redirect your push or pull operations to an attacker-controlled endpoint.

Why Developers Should Be Alarmed

While it might seem unlikely that this is happening right now in any organisation, a simple Github Search would show you that this typo has been made on quite a number of occasions. If your CI/CD workflow is also scripted to push to ghrc.io/... instead of ghcr.io/..., those images will never reach GitHub, and instead will end up elsewhere. In doing so, the adversaries operating ghrc.io could intercept or modify container images. They might serve backdoored images, leak credentials, or inject exploits. But this stuff is easy to make mistakes with. In logs or configuration files, ghcr.io and ghrc.io basically look identical at a glance. Developers may not notice the swap until something breaks, or even worse, when the damage is already done.

But you can take action. As an immediate first step, you can carefully review your registry URLs, especially in automation files like Dockerfiles, CI pipelines, docker push or docker pull commands. Additionally, you could enforce DNS or host-level protections to prevent access to known malicious or typo versions like GHRC. Explicitly only allow the registries that you expect to work with.

Closing Remarks

1. ghrc.io exists as a live container registry masquerading behind a one-letter typo of ghcr.io.
2. This reflects an escalation from typosquatting individual package names to targeting entire registries.
3. The implications are severe. As the story evolves, it is worth adopting some vigilance when working with your container registries.
4. Brandon Mitchell later clarified that while the 401 response and www-authenticate header are standard parts of the OCI spec, in this case they’re being returned by a server that isn’t a registry at all. The fact that only the /v2/ endpoint mimics OCI behavior, while the rest of the site is a default nginx install, suggests the setup is intentionally crafted to lure OCI clients into sending credentials to a fake token API.
5. This scenario highlights why companies should prefer providing developers a registry within their organisation. Having a control plane (like Cloudsmith) in front of registries in which to verify and block things like this fake registry, backed-up by a powerful audit trail for post-incident forensics.