GitHub: Kritische Sicherheitslücke bei git push schnell geschlossen

Am 4. März 2026 meldete das Wiz-Forschungsteam über das Bug-Bounty-Programm von GitHub eine kritische Sicherheitslücke, die eine Remote-Code-Ausführung über den git push-Befehl ermöglichte. Betroffen waren nicht nur github.com, sondern auch mehrere Enterprise-Versionen des Dienstes. Das GitHub-Team handelte prompt: Innerhalb von nur zwei Stunden wurde der Fehler validiert, eine Lösung implementiert und eine forensische Untersuchung eingeleitet – die ergab, dass die Schwachstelle zu keinem Zeitpunkt ausgenutzt worden war.

Wie die Meldung einging und die Schwachstelle bestätigt wurde

Die Sicherheitsforscher beschrieben einen Angriff, bei dem Nutzer mit Push-Berechtigungen durch einen gezielt manipulierten git push-Befehl beliebigen Code auf den GitHub-Servern ausführen könnten. Der Angriff erforderte lediglich einen einzigen Befehl: einen Push mit einer speziell präparierten Option, die ein unsaniertes Zeichen ausnutzte.

Das GitHub-Sicherheitsteam begann unverzüglich mit der Validierung des Berichts. Bereits 40 Minuten später konnte die Schwachstelle intern reproduziert und ihre Kritikalität bestätigt werden. Angesichts der potenziellen Auswirkungen handelte es sich um einen Notfall, der eine sofortige Reaktion erforderte.

Die technische Ursache: Wie die Schwachstelle funktionierte

Jeder git push-Vorgang durchläuft bei GitHub mehrere interne Dienste, die Metadaten wie Repository-Typ oder Zielumgebung austauschen. Ein zentraler Bestandteil dieser Kommunikation ist ein internes Protokoll, das die Push-Optionen des Nutzers verarbeitet. Push-Optionen sind ein legitimes Feature von Git, das es Clients ermöglicht, während eines Push-Vorgangs Schlüssel-Wert-Paare an den Server zu senden.

Doch genau hier lag die Schwachstelle: Die vom Nutzer bereitgestellten Werte wurden ohne ausreichende Bereinigung in die interne Metadatenstruktur übernommen. Da das interne Format ein Trennzeichen verwendete, das auch in Nutzerdaten vorkommen konnte, war es möglich, zusätzliche Felder einzuschleusen. Diese wurden von nachgelagerten Diensten als vertrauenswürdige interne Werte interpretiert.

Durch die Verkettung mehrerer dieser injizierten Werte gelang es den Forschern, die Zielumgebung des Push-Vorgangs zu überschreiben. Dadurch wurden Sandbox-Mechanismen umgangen, die normalerweise die Ausführung von Hooks einschränken. Letztlich ermöglichte dies die Ausführung beliebigen Codes auf dem Server.

Schnelle Reaktion: Patch innerhalb von zwei Stunden

Noch am selben Tag, um 17:45 Uhr UTC, identifizierte das GitHub-Team die Ursache der Schwachstelle. Bereits um 19:00 Uhr UTC desselben Tages wurde ein Fix für github.com ausgerollt. Dieser stellt sicher, dass Nutzeroptionen bei Push-Vorgängen nun korrekt bereinigt werden und keine Kontrolle mehr über interne Metadatenfelder erlangen können.

Für GitHub Enterprise Server (GHES) wurden Patches für alle unterstützten Versionen veröffentlicht, beginnend mit den Releases 3.14.25 bis 3.20.0. Die Schwachstelle ist unter der CVE-Nummer CVE-2026-3854 erfasst. GitHub empfiehlt allen GHES-Kunden dringend, die Updates umgehend einzuspielen.

Keine Ausnutzung nachweisbar

Nach dem Rollout des Patches stellte sich die Frage, ob die Schwachstelle vor der Meldung durch Wiz bereits von Dritten ausgenutzt worden war. Ein entscheidender Hinweis ergab sich aus der Art des Angriffs: Die Ausnutzung zwingt den Server, einen Codepfad zu durchlaufen, der unter normalen Umständen auf github.com nie genutzt wird. Dieser Pfad ist eine direkte Folge der Injizierung und kann vom Angreifer nicht unterdrückt werden.

GitHub durchsuchte seine Telemetriedaten nach Spuren dieses ungewöhnlichen Codepfads. Die Ergebnisse waren eindeutig:

• - Alle gefundenen Vorkommen ließen sich auf die eigenen Tests der Wiz-Forscher zurückführen.
• - Keine anderen Nutzer oder Konten hatten diesen Pfad ausgelöst.
• - Es gab keine Anzeichen für den Zugriff, die Änderung oder das Abfließen von Kundendaten.

Für GHES-Kunden wäre eine Ausnutzung nur mit einem authentifizierten Nutzer mit Push-Berechtigungen auf der jeweiligen Instanz möglich. GitHub rät dennoch zur Überprüfung der Zugriffsprotokolle aus Vorsicht.

Tiefere Verteidigung: Zusätzliche Maßnahmen

Die Untersuchung brachte einen weiteren wichtigen Befund zutage. Die Schwachstelle funktionierte auch deshalb, weil der Server Zugriff auf einen Codepfad hatte, der für seine aktuelle Umgebung nicht vorgesehen war. Dieser Pfad existierte zwar in der Container-Image-Datei des Servers, sollte aber eigentlich nur in einer anderen Produktkonfiguration genutzt werden.

Ein älteres Bereitstellungsverfahren hatte diesen Pfad korrekt ausgeschlossen. Als sich das Bereitstellungsmodell änderte, wurde dieser Ausschluss jedoch nicht angepasst. Dies unterstreicht die Bedeutung von Defense-in-Depth-Strategien: Neben der direkten Behebung der Eingabebereinigung wurde der unnötige Codepfad aus allen betroffenen Umgebungen entfernt. Selbst bei zukünftigen ähnlichen Schwachstellen würde diese zusätzliche Härtung den möglichen Schaden begrenzen.

Was Nutzer jetzt tun sollten

Nutzer von GitHub Enterprise Cloud, GitHub Enterprise Cloud mit Enterprise Managed Users und GitHub Enterprise Cloud mit Data Residency müssen keine weiteren Maßnahmen ergreifen, da diese Dienste bereits am 4. März 2026 gepatcht wurden.

Für GitHub Enterprise Server ist eine Ausnutzung nur mit Push-Berechtigungen möglich. GitHub empfiehlt, die Protokolldatei /var/log/github-audit.log nach Push-Vorgängen mit ; in den Push-Optionen zu durchsuchen. Die verfügbaren Updates umfassen folgende Versionen:

• - GitHub Enterprise Server 3.14.25 oder höher
• - GitHub Enterprise Server 3.15.20 oder höher
• - GitHub Enterprise Server 3.16.16 oder höher
• - GitHub Enterprise Server 3.17.13 oder höher
• - GitHub Enterprise Server 3.18.7 oder höher
• - GitHub Enterprise Server 3.19.4 oder höher

GitHub wird auch weiterhin eng mit der Sicherheitscommunity zusammenarbeiten, um solche Vorfälle in Zukunft frühzeitig zu erkennen und zu verhindern. Die schnelle Reaktion auf diese Schwachstelle zeigt, wie wichtig eine robuste Sicherheitskultur und proaktive Überwachung sind – ein Standard, den das Unternehmen auch künftig hochhalten wird.