Sechs Git-Sicherheitslücken: Warum Entwickler und CI/CD-Teams jetzt aktualisieren sollten

Sechs Git-Sicherheitslücken: Was am 10. November passiert ist

Das Git-Projekt hat am 10. November 2026 Sicherheitsupdates für sechs Schwachstellen veröffentlicht. Betroffen sind nicht nur ungewöhnliche Spezialbefehle: Auch rekursives Klonen, das Verarbeiten von Referenzen, Merge-Vorgänge und Binär-Patches gehören zu den Angriffsflächen. In einem Szenario kann ein manipuliertes Repository beim Klonen sogar die Ausführung fremden Codes auslösen. Für Entwickler ist das ein guter Anlass, die lokale Git-Version zu prüfen. Für Unternehmen ist die Lage komplexer, denn Git steckt ebenso in Build-Servern, Hosting-Diensten und Entwicklungswerkzeugen.

Die Korrekturen stehen in Git 2.56.1 bereit. Wer eine ältere Wartungslinie nutzt, kann auf die ebenfalls korrigierten Versionen 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 oder 2.50.2 wechseln. Die Veröffentlichung bedeutet nicht, dass jeder Git-Nutzer bereits angegriffen wurde. Sie zeigt aber, dass die Verarbeitung fremder Repository-Daten eine Sicherheitsgrenze ist, die bei der Risikobewertung häufig unterschätzt wird.

Die gefährlichste Konstellation: rekursives Klonen

Besonders relevant ist CVE-2026-111760. Bei extrem langen Pfaden kann eine Ganzzahlverkürzung dazu führen, dass Git einen Pfad unter einem anderen Namen überprüft, als es ihn anschließend verarbeitet. Dadurch kann ein Angreifer unter bestimmten Bedingungen die .git-Datei eines Submoduls durch einen symbolischen Link ersetzen. Verweist dieser auf ein Verzeichnis mit manipulierter Git-Konfiguration oder Hooks, droht während eines rekursiven Klonvorgangs die Ausführung von Angreifercode.

Entscheidend ist der Kontext: Nicht jeder normale Clone führt automatisch zu einer Kompromittierung. Die Schwachstelle erfordert speziell präparierte Daten und einen passenden Ablauf. Dennoch sind rekursive Klone in automatisierten Projekten verbreitet, beispielsweise wenn Submodule als Teil eines Build-Prozesses ausgecheckt werden. Wer fremde Projekte testet, sollte den Updatebedarf deshalb nicht allein anhand der vermeintlichen Vertrauenswürdigkeit des Hauptrepositorys bewerten.

Referenzen und Signaturen: zwei weitere Angriffsflächen

CVE-2026-113408 betrifft die Behandlung einer vom Server angekündigten HEAD-Referenz beim Klonen eines leeren Repositorys über Git-Protokollversion 2. Ein bösartiger Server kann einen ungültigen Referenznamen mit Pfad-Traversal-Bestandteilen liefern. Bei späteren Operationen kann dies beim dateibasierten Referenz-Backend zu Schreibzugriffen außerhalb des vorgesehenen Verzeichnisses führen. Die aktualisierte Git-Version prüft diese Namen vor der Übernahme und verschärft die Validierung weiterer Referenzen.

Bei CVE-2026-114467 geht es um die Verarbeitung von Signaturen. Git nahm beim Entfernen von GPG-Signaturen an, dass höchstens zwei Signaturen vorkommen. Eine speziell aufgebaute Nachricht mit mehr Signaturen konnte über das Ende eines festen Stack-Arrays hinausschreiben. Unter anderem beim Zusammenführen entsprechend manipulierter Tags drohen Speicherbeschädigung und möglicherweise ein Absturz. Für Betreiber automatisierter Merge-Dienste ist diese Unterscheidung wichtig: Auch Daten, die nicht als ausführbarer Code erscheinen, können gefährlich sein.

Binär-Patches und große Merges können Git abstürzen lassen

Die Schwachstelle CVE-2026-114469 betrifft Binär-Patches. Git begrenzte deren Größe, prüfte dabei aber zunächst nur die gelieferte, komprimierte beziehungsweise kodierte Eingabe. Ein kleiner erscheinender Patch konnte sich bei der Verarbeitung über die vorgesehene Grenze hinaus ausdehnen. Das Ergebnis war ein Zugriff außerhalb des erlaubten Speicherbereichs, der Git zum Absturz bringen kann. Die Korrektur prüft zusätzlich die angegebene unkomprimierte Größe.

CVE-2026-105437 betrifft die Speicherberechnung bei sehr großen Merge-Ergebnissen. Unter anderem eine Kombination vieler Konflikte und großer Konfliktmarker kann zu einem arithmetischen Überlauf führen. Dann wird möglicherweise ein zu kleiner Speicherbereich reserviert und beim Schreiben beschädigt. Die Reparatur setzt auf geeignete Datentypen und überprüfte Berechnungen. Praktisch relevant ist dies insbesondere dort, wo Dienste Merge-Vorgänge mit nicht vollständig vertrauenswürdigen Eingaben automatisch ausführen.

Fast-Import: fremde Datenströme dürfen keine Dateien steuern

Mit CVE-2026-114466 schließt das Projekt Lücken im Befehl git fast-import. Dieser verarbeitet Datenströme, um Repository-Inhalte aufzubauen. Bestimmte Funktionen waren bereits als potenziell unsicher bekannt und deshalb eingeschränkt. Drei weitere Möglichkeiten waren jedoch nicht ausreichend geschützt: rewrite-submodules-from und rewrite-submodules-to konnten Dateien lesen, während export-pack-edges Dateien anlegen oder ergänzen konnte.

Die neue Version weist solche Anweisungen aus dem Eingabestrom zurück, solange sie nicht ausdrücklich über --allow-unsafe-features erlaubt werden. Diese Freigabe sollte nur erfolgen, wenn die Quelle des Streams vertrauenswürdig ist. Für Migrationen zwischen Versionsverwaltungssystemen, Archivimporte und selbst entwickelte Importdienste folgt daraus eine klare Regel: Ein Importformat ist nicht automatisch harmlos, nur weil es keinen offensichtlichen Programmcode enthält.

Welche Git-Versionen sind korrigiert?

Laut der Mitteilung vom 10. November sind Git 2.56.1 sowie die Wartungsversionen 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 und 2.50.2 korrigiert. Die Nummern sollten nicht als einfache Mindestversion über alle Zweige hinweg interpretiert werden: Ein älterer Wartungszweig kann einen eigenen Sicherheits-Backport erhalten haben. Entscheidend ist, ob der jeweilige Distributor die Patches tatsächlich ausgeliefert hat.

Die lokale Version lässt sich mit git --version ermitteln. Unter Windows, macOS und Linux muss außerdem geprüft werden, welche Git-Binärdatei die Anwendung wirklich verwendet. Ein aktualisiertes Terminal-Git bedeutet nicht zwangsläufig, dass eine IDE, ein Desktop-Client oder ein Build-Agent seine eingebettete Version ebenfalls erneuert hat. Auch Container-Images und langlebige Runner verdienen eine gesonderte Prüfung.

Warum CI/CD und Hosting-Dienste besonders genau hinschauen sollten

Eine Entwickler-Workstation verarbeitet häufig bewusst ausgewählte Repositories. CI-Systeme und Hosting-Plattformen dagegen arbeiten oft automatisch mit Pull Requests, Branches, Tags, Submodulen oder Importdaten unterschiedlicher Herkunft. Damit treffen potenziell manipulierte Daten auf Prozesse, die Zugriff auf Build-Geheimnisse, interne Netzwerke oder Veröffentlichungsrechte haben können. Ob daraus ein ausnutzbarer Angriff wird, hängt von der konkreten Konfiguration und dem betroffenen Git-Pfad ab.

Als technische Vorsorge empfiehlt sich ein Inventar der Git-Installationen auf Runnern und Servern. Darüber hinaus sollten unnötige Schreibrechte, dauerhaft gespeicherte Tokens und weitreichende Netzwerkzugriffe reduziert werden. Diese Maßnahmen sind kein Ersatz für das Sicherheitsupdate. Sie können aber mögliche Folgen begrenzen, falls ein Verarbeitungspfad erneut eine Schwachstelle aufweist.

GitHub Enterprise und gebündelte Anwendungen

GitHub erklärt, die Korrekturen für github.com, GitHub Enterprise Cloud und die Cloud-Variante mit Datenresidenz bereits eingespielt zu haben. Für GitHub Enterprise Server nennt die Ankündigung die korrigierten Versionen 3.19.15, 3.20.11, 3.21.9 und 3.22.4. Administratoren selbst betriebener Installationen sollten ihre jeweilige Release-Linie prüfen und die passende Aktualisierung zeitnah planen.

Für GitHub Desktop und die GitHub-Copilot-App wurden zum Zeitpunkt der Ankündigung aktualisierte Pakete koordiniert. Auch Codespaces und Actions sollen gepatchte Git-Versionen erhalten. Daraus folgt ausdrücklich nicht, dass jede lokal installierte Anwendung bereits aktuell ist. Wer solche Werkzeuge einsetzt, sollte deren eigene Update-Hinweise prüfen und sich nicht allein auf die Aktualisierung der GitHub-Webplattform verlassen.

Praxischeck: So priorisieren Teams die nächsten Schritte

Zuerst sollten Teams ermitteln, wo Git tatsächlich ausgeführt wird: auf Entwicklerrechnern, in IDEs, in CI-Runnern, in Docker-Images, auf Deployment-Servern und in selbst betriebenen Git-Diensten. Anschließend werden Versionsstände mit den korrigierten Releases oder den Sicherheitshinweisen der jeweiligen Distribution abgeglichen. Ein Test auf einer Staging-Umgebung ist sinnvoll, insbesondere wenn Automationen spezielle Import-, Merge- oder Submodul-Workflows nutzen.

Nach dem Rollout sollten Pipeline-Protokolle auf fehlgeschlagene Checkouts, verändertes Importverhalten und unerwartete Versionsabweichungen kontrolliert werden. Ein festgelegter Verantwortlicher für Runner-Images und Toolchains verhindert, dass nur Arbeitsplatzrechner aktualisiert werden. Bei regulierten Umgebungen gehören Zeitpunkt, getestete Version und verbleibende Ausnahmen in die Änderungsdokumentation.

Was tun, wenn ein Update noch nicht möglich ist?

Bis die Korrektur installiert werden kann, empfiehlt GitHub, nur vertrauenswürdige Server als Quelle zu verwenden und rekursive Klone unbekannter Repositories zu vermeiden. Ebenso sollten untrusted Tags und Inhalte nicht unnötig zusammengeführt sowie Binär-Patches und Fast-Import-Datenströme fremder Herkunft nicht verarbeitet werden. Das reduziert die Exposition, beseitigt aber keine der beschriebenen Schwachstellen.

Eine weitere sinnvolle Maßnahme ist die Isolation besonders riskanter Verarbeitungsschritte in kurzlebigen, möglichst privilegienarmen Umgebungen. Tokens sollten nur für den konkreten Job bereitstehen und anschließend ungültig werden. Diese zusätzlichen Schutzmaßnahmen sind allgemeine Sicherheitsprinzipien, keine Garantie gegen alle sechs CVEs. Sobald gepatchte Pakete verfügbar sind, bleibt deren Installation der zentrale Schritt.

Fazit: Git ist Infrastruktur, nicht nur ein Entwicklerwerkzeug

Die sechs am 10. November veröffentlichten Schwachstellen machen deutlich, dass Versionsverwaltung selbst zur Angriffsfläche werden kann. Das betrifft nicht nur das Klonen eines fremden Projekts, sondern auch Referenzen, Signaturen, Binär-Patches, Merge-Berechnungen und Importströme. Die Risiken unterscheiden sich erheblich; nicht jede Lücke erlaubt unmittelbar Codeausführung. Gemeinsam ist ihnen jedoch, dass vermeintlich passive Repository-Daten sicher verarbeitet werden müssen.

Für Website-Betreiber, Agenturen und Softwareteams lautet die praktische Konsequenz: Git-Versionen inventarisieren, korrigierte Releases installieren und automatisierte Prozesse gesondert prüfen. Wer Git nur als Entwicklerkomfort betrachtet, übersieht leicht die Installationen in seiner Lieferkette. Die aktuelle Sicherheitsrunde ist deshalb auch eine Gelegenheit, Zuständigkeiten und Updateprozesse für Entwicklungsinfrastruktur dauerhaft zu verbessern.