Paulo Victor Leite Lima Gomes

Posted on Apr 29

github failed at the only thing they should do: git

#git #github #devops #security

Yes, I know GitHub does a lot more than Git these days.
Actions, packages, security tooling, issue tracking, enterprise management, AI features, code search, and half the software industry glued into one UI.

But that is exactly why this story is so funny in the worst possible way.

When a company built around Git takes a critical hit in the git push pipeline, my reaction is pretty simple:

guys, this was the one thing you absolutely had to not mess up.

That is my opinion here, and I do not think it is unfair.
GitHub failed at the only thing they should do: Git.

what happened

On April 28, GitHub published two important posts about a serious incident and the vulnerability behind it.
Wiz also published its own breakdown of the issue, tracked as CVE-2026-3854.

The short version:

Wiz described it as a CVSS 8.7 remote code execution vulnerability
the affected area was GitHub’s git push pipeline
GitHub said it validated, fixed, and investigated the issue in under two hours
GitHub also said it found no evidence of exploitation
separately, GitHub published an availability update acknowledging customer-facing impact during the incident window

That is already enough to make engineers pay attention.
A critical RCE in the push path is not some side quest.
That is the bloodstream.

this is why the story matters more than the cve headline

A lot of people will read this as just another security incident.
That is too shallow.

The deeper issue is trust concentration.
GitHub is not just a code host anymore.
For a lot of teams, GitHub is now:

source control
CI/CD trigger point
release workflow anchor
access-control boundary
automation hub
policy surface
audit trail
developer identity checkpoint

That means a bug in the push pipeline is not just “one bug.”
It touches one of the highest-trust points in the entire software-delivery chain.

And that is why my reaction is stronger than “well, incidents happen.”
Of course incidents happen.
But some incidents hit the exact place where your credibility is supposed to be strongest.
This was one of those.

github’s response was fast, but that does not erase the failure

To be fair, GitHub’s own security post says it moved very quickly:

validate the report
mitigate the issue
investigate for exploitation
confirm no exploitation evidence

That is good.
That is exactly what they should do in incident response.

But fast response does not cancel the original problem.
It just means the recovery side looked competent.

And that distinction matters.
A good fire brigade does not mean you should stop asking why the building caught fire.

the platform expansion story is part of the problem

This is where I think the broader lesson sits.

GitHub has spent years becoming more than Git.
That was strategically obvious.
It became a platform on top of a protocol, then a workflow engine on top of a platform, then increasingly a software-operating environment.

That growth worked.
Commercially, it was a huge success.

But expansion has a tax.
Every layer of platform ambition increases complexity, and complexity has a way of drifting back into the supposedly foundational surfaces.

When you become the center of:

pushes
merges
bots
actions
enterprise controls
security scanning
AI assistance
policy enforcement

...your “core Git path” is no longer just a clean old-school plumbing layer sitting alone in a quiet corner.
It becomes part of a much more dangerous machine.

That is one reason I do not buy the very comfortable narrative that this is just one isolated bug.
It is also a reminder that platform sprawl eventually leaks back into the base layer.

availability matters too

GitHub’s availability post matters here because it makes the incident feel more real than a sterile CVE note.
The company was not just publishing a technical write-up after the fact.
It also had to talk publicly about service disruption.

That combination matters:

security issue
high-trust path
customer-visible impact

Once those three things line up, this stops being just an internal engineering embarrassment.
It becomes a reliability story too.

And reliability is part of the product.
Especially when the product is infrastructure for how other engineers ship software.

the market keeps forgetting what “boring critical infrastructure” really means

I think the market often rewards GitHub for looking exciting.
AI features, flashy demos, ecosystem gravity, all of that.

But the real value proposition is still much more boring.
It is something like:

your code lives here
your push lands here
your repo history is here
your automation starts here
your delivery chain trusts this place

That is not glamorous.
That is utility.
That is plumbing.
That is exactly why breaking trust there feels worse than some bug in a side feature.

If your core business is where software teams place their code and start their release motion, then your standard is not “generally impressive platform.”
Your standard is “this path must be extremely hard to break in dangerous ways.”

this is also why single-vendor convenience has a hidden cost

This incident is another reminder that centralization is efficient until it is not.

Putting source, CI, automation, access, and process gravity into one place makes life smoother on normal days.
But it also means that when something goes wrong in a core path, the blast radius is psychological even when the technical blast radius is contained.

Teams start asking:

what else is too centralized here?
what assumptions did we stop questioning?
how much of our delivery trust sits inside one commercial boundary?

Those are healthy questions.
Probably overdue ones.

my take

I think GitHub deserves credit for responding fast.
I also think that is not the main headline.

The main headline is simpler and harsher:

GitHub had a critical RCE problem in the git push pipeline.

And if you are GitHub, that is the kind of sentence you should find humiliating.
Because among all the things people can reasonably argue about in your product, this is the one surface where you are supposed to be boringly excellent.

That is why my opinion is what it is:

GitHub failed at the only thing they should do: Git.

Not because Git is literally the only feature they offer.
But because Git is the foundational trust contract that justifies the existence of the whole giant platform built on top of it.

When that layer cracks, the rest of the value proposition looks a little less sophisticated and a little more fragile.