GitHub schreibt Geschichte um. Was geht da ab?

29. April 2026

Auf GitHub findet ein erheblicher Teil der weltweiten Softwareentwicklung statt. Rund 100 Millionen Entwickler verlassen sich darauf, dass ihre Commit-History stimmt und dass Secrets dort bleiben, wo sie hingehören. CI/CD soll bitte auch laufen. Eigentlich keine wahnsinnige Anforderung an eine Plattform, die seit 2018 zu Microsoft gehört.

Im April 2026 hat GitHub das an mehreren Stellen gleichzeitig vergeigt.

Der Merge-Queue-Bug: Git lügt jetzt

Am 23. April 2026, zwischen 16:05 und 20:43 UTC, lief die Merge-Queue Amok. Wer in diesem Zeitfenster Squash-Merges oder Rebases nutzte, bekam hinterher die Quittung: 658 Repositories und 2.092 Pull Requests waren betroffen. Das Feature, das eigentlich für saubere Merges sorgen soll, hat stattdessen still vorher gemergte Commits zurückgerollt. Details und Diskussion in der GitHub Community.

Ein Pull Request mit 150 geänderten Zeilen erzeugte dabei einen Commit mit knapp 15.000 Zeilen Diff, weil 20 vorherige PRs implizit revertiert wurden. Wer robuste End-to-End-Tests hatte, hat das gemerkt. Alle anderen erst in Production.

Git verspricht seit jeher, dass die History unveränderlich ist. Darauf basiert das gesamte Konzept von versioniertem Code. GitHub hat dieses Versprechen für knapp zwei Stunden gebrochen, ohne jemanden aktiv zu informieren. Datenverlust gab es keinen. Vertrauensverlust schon.

Vier Tage später: die Suche fällt aus

Man könnte meinen, nach einem solchen Vorfall wäre Vollalarm. Stattdessen kollabierte am 27. April das Elasticsearch-Subsystem hinter Pull-Request-Suche, Issues und Projects. Ursache war offenbar ein Botnet-Angriff, der den Cluster überlastet hat. Git-Operationen blieben stabil, die Oberfläche zeigte vielerorts schlicht nichts mehr an.

Laut unabhängigem Monitoring lag die Verfügbarkeit in den letzten 30 Tagen bei 94,90%, allein in den letzten sieben Tagen gab es fünf Incidents. Ernstzunehmende SaaS-Plattformen versprechen 99,9%. Das wären 8,7 Stunden Ausfallzeit pro Jahr. Bei 94,9% sind es über 18 Tage.

Die Sicherheitslücke obendrauf

Der April hatte noch Platz. Forscher von Tenable entdeckten am 22. April eine kritische Remote-Code-Execution-Schwachstelle in einem Microsoft-GitHub-Repository, CVSSv4-Score 9,3. Sie ermöglichte unautorisierten Zugriff auf Repository-Secrets. Wer CI/CD betreibt und Secrets in GitHub Actions hinterlegt, war theoretisch angreifbar. Das ist praktisch jeder.

Dazu CVE-2026-5921 im GitHub Enterprise Server mit CVSS 8,9 High, gemeldet am 28. April. Eine weitere Schwachstelle im gh-CLI hat unter bestimmten Bedingungen Authentication-Tokens an externe Hosts weitergegeben, wenn Repositories mit Git-Submodulen geklont wurden. Übersicht der CVEs bei OpenCVE. Update auf Version 2.63.0 oder höher, falls noch nicht geschehen.

Warum gerade jetzt?

GitHubs CTO Vladimir Fedorov hat dazu ein erstaunlich ehrliches Statement veröffentlicht: Das Wachstum durch Agentic Development Workflows seit Ende 2025 hat die Kapazitätsplanung pulverisiert. Man plante für den 10-fachen Bedarf, im Februar 2026 stellte man fest, dass es eher der 30-fache wird. Parallel läuft eine Migration aus eigenen Rechenzentren in die Azure-Cloud, die naturgemäß neue Instabilitäten bringt.

Ein ernstes strukturelles Problem. Andererseits sollte ausgerechnet Microsoft mit Azure und einem quasi unbegrenzten Infrastrukturbudget so etwas lösen können. Letztes Quartal: über 60 Milliarden Dollar Umsatz. GitHub kracht trotzdem unter einer 30x-Last zusammen, die seit Februar bekannt ist.

Was GitHub jetzt tun will

GitHub hat eine Prioritätenliste veröffentlicht, die klingt, als wäre sie aus einem SRE-Lehrbuch abgeschrieben:

Webhooks aus MySQL auslagern, Session-Caches neu designen
Git-Operationen und GitHub Actions von anderen Workloads isolieren
Multi-Cloud-Strategie für mehr Resilienz
Status-Page um Verfügbarkeitszahlen erweitern, auch kleinere Incidents melden
Motto: "Availability first, then capacity, then new features"

Klingt vernünftig. Klingt auch nach Dingen, die bei einer Plattform dieser Größenordnung längst da sein sollten.

Was man jetzt tun sollte

Konkret für alle, die GitHub in Production nutzen:

Merge-Queue mit Squash-Merges: Commit-History nach dem 23. April prüfen, betroffene Branches reparieren
gh CLI: Update auf mindestens 2.63.0, Authentication-Tokens rotieren
GitHub Enterprise Server: CVE-2026-5921 patchen
Secrets in Actions: prüfen, ob unerwünschte Zugriffe stattgefunden haben

GitHub wird das Schiff vermutlich wieder ausrichten. Es bleibt das ungute Gefühl, dass ein Konzern, der 7,5 Milliarden Dollar für die Plattform bezahlt hat, sie auch am Laufen halten können sollte. Solange das nicht klappt, ist ein zweites Remote für die kritischsten Repositories keine Paranoia, sondern Wartung.

Wer hat's verbrochen? Die KI war's

Vielleicht ist es am Ende auch ganz einfach: Wenn KI-Agenten rund um die Uhr PRs öffnen und Workflows triggern, kommt halt selbst Microsoft nicht mehr hinterher. Die Maschinen arbeiten schneller als die Infrastruktur, die sie bedient. Die einen freuen sich über den Produktivitätssprung, die anderen patchen am Wochenende eine Merge-Queue, die plötzlich Geschichte umschreibt. Die KI selbst hat davon natürlich nichts mitbekommen. Sie hat währenddessen den nächsten PR aufgemacht. ;-)

Anmerkung: irgendwie geht das gerade alles etwas zu schnell.