Yes, I know GitHub does a lot more than Git these days. 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. On April 28, GitHub published two important posts about a serious incident and the vulnerability behind it. 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 lot of people will read this as just another security incident. The deeper issue is trust concentration. 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.” And that is why my reaction is stronger than “well, incidents happen.” 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. But fast response does not cancel the original problem. And that distinction matters. This is where I think the broader lesson sits. GitHub has spent years becoming more than Git. That growth worked. But expansion has a tax. 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. That is one reason I do not buy the very comfortable narrative that this is just one isolated bug. GitHub’s availability post matters here because it makes the incident feel more real than a sterile CVE note. 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. And reliability is part of the product. I think the market often rewards GitHub for looking exciting. But the real value proposition is still much more boring. 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. If your core business is where software teams place their code and start their release motion, then your standard is not “generally impressive platform.” 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. 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. I think GitHub deserves credit for responding fast. 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. 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. When that layer cracks, the rest of the value proposition looks a little less sophisticated and a little more fragile. Wiz, GitHub RCE Vulnerability: CVE-2026-3854 Breakdown — https://www.wiz.io/blog/github-rce-vulnerability-cve-2026-3854 GitHub, An update on GitHub availability — https://github.blog/news-insights/company-news/an-update-on-github-availability/ GitHub, Securing the git push pipeline: Responding to a critical remote code execution vulnerability — https://github.blog/security/securing-the-git-push-pipeline-responding-to-a-critical-remote-code-execution-vulnerability/