Sechs Git-Schwachstellen: Aktualisieren Sie mehr als nur die Kommandozeile

Wenn Sie Git im Terminal aktualisiert haben, ist die Arbeit noch nicht erledigt: Einzelne Anwendungen und Build-Umgebungen können ihre eigene Kopie ausführen. Am 10. November 2026 veröffentlichte das Git-Projekt Korrekturen für sechs Schwachstellen – von der Codeausführung beim rekursiven Klonen bis hin zu Speicherbeschädigung beim Zusammenführen. Deshalb sollten Sie jede Umgebung prüfen, die Repositories oder deren Inhalte verarbeitet, und nicht nur die Ausgabe von git --version in Ihrer Shell.

Was sich mit dem Update geändert hat

Die Korrekturen sind in Git 2.56.1 enthalten und wurden auf unterstützte Zweige zurückportiert: 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 und 2.50.2. Das Update behebt sechs Probleme in verschiedenen Bereichen von Git – bei der Verarbeitung von Pfaden, Links, Signaturen, Binär-Patches, Zusammenführungen und Import-Streams. GitHub veröffentlichte am 10. November eine Analyse der Schwachstellen und die Update-Empfehlung; die Versionshinweise zu Git 2.56.1 führen die in dieser Reihe behobenen CVEs auf.

In der Praxis bedeutet das: Aktualisieren Sie Git an drei Orten – auf Arbeitscomputern, in Automatisierungen und in Anwendungen, die eine eigene Git-Version enthalten. Gerade der letzte Punkt wird leicht übersehen: Ein Update des Systempakets ändert nicht automatisch die Version in jedem Client oder Build-Image.

Warum rekursives Klonen besondere Aufmerksamkeit verdient

Die anschaulichste Angriffskette beginnt mit dem rekursiven Klonen eines nicht vertrauenswürdigen Repositorys. Durch eine Kürzung der Pfadlänge konnte ein sehr langer Pfad zunächst unter einem Namen die Prüfung bestehen und anschließend unter einem gekürzten Namen auf dem Datenträger landen. Im beschriebenen Git-Szenario ließ sich dadurch die Datei .git eines Submoduls durch einen symbolischen Link auf ein Verzeichnis mit schädlicher Konfiguration oder Hooks ersetzen. Beim nächsten Zugriff konnte Git den vom Angreifer vorgegebenen Code ausführen.

Für die Praxis ist wichtig: Es geht um ein speziell präpariertes Repository und eine entsprechende Operation. Teams, die regelmäßig Projekte aus externen Quellen mit dem Parameter --recurse-submodules klonen, sollten ihre Client- und Automatisierungsumgebungen vorrangig aktualisieren. Die Korrektur weist übermäßig lange Pfade zurück, bevor ihre Länge gekürzt wird.

Weitere Stellen, an denen Git nicht vertrauenswürdige Daten verarbeitet

Ein weiteres Problem tritt beim Klonen eines leeren Repositorys über Git Protocol v2 auf. Der Server konnte einen Verweis HEAD mit einem Branchnamen übermitteln, der Pfadkomponenten zur Verzeichnisumgehung enthielt; bei einer späteren Aktualisierung des Branchnamens konnte dann eine Datei außerhalb des erwarteten Verweisverzeichnisses geschrieben werden. In korrigierten Git-Versionen wird ein solches Ziel ebenso wie andere über das Protokoll empfangene Verweisnamen geprüft.

Weitere Schwachstellen betrafen Zusammenführungen und Patches. Bei der Verarbeitung von Signaturen war ein festes Array für höchstens zwei Signaturen ausgelegt; eine speziell präparierte Nachricht mit mehr Signaturen konnte einen Schreibzugriff über die Array-Grenzen hinaus und eine Speicherbeschädigung auslösen. Beim Anwenden eines Binär-Patches berücksichtigte die Größenprüfung die ursprüngliche Darstellung, obwohl komprimierte Daten sich zu einem wesentlich größeren Umfang entfalten können. Git prüft jetzt die angegebene unkomprimierte Größe vor der Verarbeitung.

Auch umfangreiche Zusammenführungen konnten beim Berechnen des benötigten Puffers einen Überlauf und anschließend einen Schreibzugriff über dessen Grenzen hinaus verursachen. Das betrifft unter anderem Hosting-Anbieter und Anwendungen, die nicht vertrauenswürdige Inhalte zusammenführen. Schließlich wurden drei Funktionen von git fast-import für Befehle aus dem Eingabestream eingeschränkt: rewrite-submodules-from und rewrite-submodules-to konnten beliebige Dateien lesen, während export-pack-edges Dateien erstellen oder Daten an bestehende Dateien anhängen konnte. Diese Funktionen sind nun gesperrt, sofern nicht ausdrücklich das Flag --allow-unsafe-features angegeben wird. Es sollte nur für einen vertrauenswürdigen Stream-Generator verwendet werden.

Wo Sie separate Git-Kopien finden

Entwickler können mit einer Bestandsaufnahme der Stellen beginnen, von denen Git gestartet wird. Prüfen Sie die Version im Terminal und nutzen Sie die integrierte Update-Prüfung Ihrer IDE und Ihrer Desktop-Git-Clients. Prüfen Sie anschließend CI-Images, Container, Runner und Server-Jobs, die klonen, zusammenführen, Binär-Patches anwenden oder fast-import ausführen. Dass auf dem Host ein aktuelles Git installiert ist, garantiert nicht, dass eine Anwendung genau diese Version verwendet.

In Unternehmen empfiehlt es sich, nicht nur die Quell-Images, sondern auch bereits bereitgestellte Umgebungen zu prüfen: Ein dauerhaft laufender Runner oder ein interner Dienst kann nach der Aktualisierung des Basis-Images noch eine alte Binärdatei verwenden. Für GitHub Enterprise Server nennt GitHub die korrigierten Versionen 3.19.15, 3.20.11, 3.21.9 und 3.22.4. Das Unternehmen teilte mit, dass die Korrekturen bereits auf github.com und GitHub Enterprise Cloud ausgerollt wurden, einschließlich der Varianten mit Datenresidenz. Die Veröffentlichung korrigierter Versionen von GitHub Desktop und der GitHub Copilot App wird koordiniert; korrigierte Versionen für Codespaces und GitHub Actions sollen ebenfalls noch erscheinen.

So senken Sie das Risiko vor dem Update

Wenn sich die Korrektur nicht sofort installieren lässt, schränken Sie vorübergehend Operationen mit nicht vertrauenswürdigen Daten ein: Klonen Sie Repositorys nur von vertrauenswürdigen Servern, vermeiden Sie rekursives Klonen ungeprüfter Projekte, führen Sie deren Inhalte nicht zusammen und wenden Sie keine von ihnen bezogenen Binär-Patches oder fast-import-Streams an. Diese Maßnahmen verringern den Kontakt mit den konkreten anfälligen Szenarien, ersetzen aber kein Update.

Die wichtigste praktische Erkenntnis ist einfach: Sie müssen Git dort aktualisieren, wo ein Programm Git tatsächlich ausführt. Der Befehl im Terminal ist nur eine dieser Stellen; Entwicklungs-Clients, CI-Systeme und Dienste zur Verarbeitung von Repositorys müssen separat geprüft werden.