Dear GitHub,

So, here's the thing; there's a security problem that's been an open secret for a while now. People talk about it in issue trackers. It comes up in security disclosures. It gets discussed in Slack threads that inevitably end with "...but we'd need GitHub to actually expose that data." 

I'm bringing this to your attention because I'm tired of watching that conversation end the same way. The security community is only asking for visibility into data you already have. Without it, we're stuck. Package registries can't warn users. Security tools can't flag suspicious references. Attackers, meanwhile, understand this blind spot perfectly well. They're already exploiting it, just like Shai Hulud did.

We’re coming up to the holiday period. And I like to think I’ve been pretty good this year. My only wish is that you give us the tools to protect the ecosystem better. I hope that’s not too much to ask!

What’s the issue?

Package managers like your very own npm, along with third parties like Bun and PyPI, allow developers to install a GitHub repository directly as a dependency. Your own GitHub Actions relies on this same primitive.

npm install github:trusted-org/trusted-package#commit-sha

bun install github:trusted-org/trusted-package#commit-sha‍

pip install git+https://github.com/trusted-org/trusted-package#commit

- uses: trusted-org/trusted-package@commit-sha

Most people would look at this and think: "Where's the security issue? I'm literally specifying the exact repository."

Yeah. I thought the same thing.

But here's what happens: if that commit SHA exists in a fork of the repository, you'll pull code from the fork. Not the repository in your URL. The fork. What the hell?

Let that sink in for a second. I’ll wait…. The URL says trusted-org/trusted-package. But if an attacker forked that repo, added a malicious commit, and got you to reference that commit's SHA, you just installed their code. Not the code you thought. Not the repo you specified. Theirs.

Why does this happen?

This happens because of GitHub's "Fork Network."

Odds are you've never heard of it. Here's the deal: when you fork a repository, you don't get a fully independent copy. Your fork joins a network, sharing the underlying git object store with the original and every other fork. That's how GitHub handles scale. They're not storing a million copies of the same commits. Makes sense.

It's also why this attack works.

The commands above ultimately hit GitHub's "Download a repository archive (tar)" endpoint. The docs say this about the owner parameter:

There are no guarantees the code belongs to the repository directly, or warnings about it potentially pulling from a fork. Honestly? Given the architecture, this behavior makes sense. The commit exists in the shared graph. GitHub serves it. That's not wrong.

What is a problem is that this creates ambiguity that nobody else can see through. You ask for trusted-org. You get code from attacker. GitHub fulfilled your request. You just didn't get what you thought you were asking for. And no tool outside of GitHub can tell the difference.

The asymmetry 

Look, we genuinely appreciated it when you added that warning banner on GitHub.com. Seeing a warning for commits like these? That's useful. It shows you know this is a problem worth surfacing.

But here's the thing: package managers don't look at your website. They call your API. And the API gives them zero indication that anything unusual is going on. No flag, no metadata, nothing documented. So npm can't warn users. PyPI can't warn users. Bun can't warn users. The information exists. You're already surfacing it on the frontend. But the ecosystem can't access it.

Why not?

Time to get strict

Remember that "Download a repository archive (tar)" endpoint we talked about? Right now, it's the weakest link. But it's also the obvious place to fix this.

Here's one idea: add a strict parameter. When it's set, the request fails if the commit only exists in a fork, not in the actual repository specified. Package managers opt in, everyone else keeps the current behavior, nothing breaks.

You're already doing this check on the frontend for that warning banner. Just give the API the same capability. Of course, it’d be ideal if you could expose more fork network information in your API in general, but this at least solves the most blatant problem.

Happy holidays!

I’m not writing this as a complaint. I’m writing because we’re all aligned on wanting a secure and dependable ecosystem. You’ve already acknowledged the issue by surfacing the warning on GitHub.com. Now it would make a world of difference to expose that same signal through the API so the ecosystem can act on it.

A small improvement on your end would enable a significant improvement across the ecosystem at large. Isn’t that the best type of improvement? 

And since it is the holiday season, I want to share something I’ve been hearing behind the scenes. In the past few weeks, I’ve spoken with some of the bigger actors in the ecosystem, and there’s a quiet, shared worry that something might go wrong while everyone’s trying to take time off to spend time with their loved ones. Fixing this one issue won’t eliminate that risk, of course, but the concern is real and widely felt.

Happy holidays, GitHub. Here’s to a calm end of the year.

‍