Ing. Calogero Bono
Das Git-Projekt hat die Version 2.56.1 veröffentlicht, um sechs Sicherheitslücken zu schließen. Eine davon erlaubt es, fremden Code auszuführen, wenn du ein bösartiges Repository rekursiv klonst. Die anderen betreffen Schreibvorgänge in nicht vorgesehene Dateien und Speicherschäden bei Merges und Binär-Patches. Das ist wichtig, weil Git in Editoren, Automatisierungswerkzeugen und Servern vieler Unternehmen steckt und überall aktualisiert werden muss.
Ein paar Begriffe, bevor wir zu den Fakten kommen Rekursiver Klon ist das Kopieren eines Repositorys samt seiner Submodule. Ein Submodul ist ein Repository innerhalb eines anderen Repositorys. Hooks sind Programme, die Git zu bestimmten Zeitpunkten startet. Path Traversal nutzt Pfade mit speziellen Komponenten, um aus dem erlaubten Ordner auszubrechen. Eine CVE ist die Kennung, mit der eine öffentlich bekannte Sicherheitslücke geführt wird.
Was hat das Git-Projekt veröffentlicht?
Laut dem GitHub-Blog stecken die Korrekturen in Version 2.56.1. Es gibt außerdem Backports für die Reihen 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 und 2.50.2.
GitHub rät, auf 2.56.1 oder die korrigierte Version deiner Reihe zu wechseln und auch Anwendungen zu aktualisieren, die eine Git-Kopie enthalten. Wer unseren Lernpfad zu Git für Entwickler gelesen hat, weiß, wie verbreitet das Werkzeug im Alltag ist.
Wie kommt man mit einem rekursiven Klon zur Codeausführung?
Der Fehler ist als CVE-2026-111760 erfasst. Es handelt sich um eine Ganzzahl-Kürzung bei der Indexverwaltung. Ein extrem langer Pfad besteht Gits Prüfung, wird aber danach mit einem kürzeren Namen auf die Festplatte geschrieben, den ein Angreifer zu .git machen kann.
So lässt sich die Datei .git eines Submoduls durch einen symbolischen Link auf einen Ordner mit feindlichen Hooks oder Konfigurationen ersetzen. Wie The Hacker News erklärt, weigert sich Git, einen .git-Ordner durch einen symbolischen Link zu ersetzen, aber in einem frisch geklonten Submodul ist .git eine Datei. Sobald Git diesen Ordner verwendet, kann der Code des Angreifers starten.
Die Korrektur verwirft zu lange Pfade, bevor die Länge gekürzt wird.
Welche fünf weiteren Lücken gibt es?
- CVE-2026-113408. Beim Klonen eines leeren Repositorys mit dem Protokoll v2 kann ein bösartiger Server einen Namen mit Path Traversal angeben. Mit dem Referenz-Backend für Dateien kann ein späteres Update dann außerhalb des vorgesehenen Ordners schreiben.
- CVE-2026-114467. Ein Tag mit mehr als zwei GPG-Signaturen beschädigt beim Merge den Stack und kann einen Dienstausfall verursachen.
- CVE-2026-114469. Ein kleiner Binär-Patch, der sich stark ausdehnt, umgeht die Grenze von etwa 1 GiB und bringt Git zum Absturz.
- CVE-2026-105437. Ein sehr großer Merge mit vielen Konflikten und einem hohen Wert des Attributs conflict-marker-size beschädigt den Heap-Speicher.
- CVE-2026-114466. Drei Funktionen von fast-import können beliebige Dateien lesen oder neue erstellen und Daten daran anhängen.
Für den letzten Fall lehnt Git diese Funktionen in eingehenden Streams nun ab, außer mit der Option --allow-unsafe-features, die nur verwendet werden sollte, wenn du dem Programm vertraust, das den Stream erzeugt.
Wer ist am stärksten gefährdet, und was hat GitHub bereits aktualisiert?
Am stärksten gefährdet sind Server, die Merges im Auftrag der Nutzer ausführen. GitLab, das CVE-2026-105437 vergeben hat, nennt git merge-tree als wahrscheinliches Ziel, weil ein Server es verwenden kann, um zu prüfen, ob sich ein Merge Request zusammenführen lässt. Das Attribut wird in einer Datei .gitattributes im Repository gesetzt, deshalb könnte schon jemand, der einen Merge Request öffnen darf, den Fehler auslösen.
GitHub erklärt, github.com und GitHub Enterprise Cloud korrigiert zu haben. Für Enterprise Server werden die Versionen 3.19.15, 3.20.11, 3.21.9 oder 3.22.4 benötigt. GitHub Desktop, die Copilot-App, Codespaces und Actions erhalten ein korrigiertes Git.
Grenzen, die du kennen solltest
Die Quellen nennen weder aktive Exploits noch einen Schweregrad für jede CVE. Wir wissen nicht, ob die Fehler bereits ausgenutzt wurden. Laut The Hacker News gab es am Dienstag um 19.09 UTC für Git for Windows noch keine Version auf Basis der 2.56.1, daher können sich die Termine für diese Plattform noch verschieben. Auch Zeitpläne für GitHub Desktop, Copilot, Codespaces und Actions fehlen.
Was sich für alle ändert, die digital arbeiten
Der erste Schritt ist, zu erfassen, wo Git überall läuft. Nicht nur auf deinem Rechner, sondern auch in Programmen, die eine eigene Kopie mitbringen, in Systemen zur kontinuierlichen Integration und in Diensten, die fremde Repositorys verarbeiten. Wer Server mit Repositorys Dritter betreibt, muss auch die Automatisierungen aktualisieren. Wenn du nicht sofort aktualisieren kannst, ist der Workaround von GitLab, in der Datei info/attributes jedes Repositorys conflict-marker-size=7 einzutragen oder die Prüfungen bei nicht vertrauenswürdigen Repositorys abzuschalten. Wer auf einen Hosting-Anbieter mit verwalteten Sicherheitsupdates setzt, gibt einen Teil dieser Arbeit ab.
Unsere Einschätzung
Es sind sechs Lücken, aber die Botschaft ist eine. Git muss als Software behandelt werden, die nicht vertrauenswürdige Eingaben verarbeitet, nicht als harmloses lokales Werkzeug. Wir klonen, mergen und wenden Patches aus externen Quellen an, ohne darüber nachzudenken, und Automatisierungen tun es in unserem Namen. Das konkreteste Risiko liegt in den Git-Kopien, die in anderen Programmen versteckt sind und die niemand aktualisiert, bis er sich daran erinnert. Die Vorsichtsmaßnahmen von GitHub sind als Notlösung brauchbar, bleiben aber genau das. Zu Werkzeugen, die Git intensiv nutzen, haben wir über GitHub Rubicon geschrieben, wo das Thema nicht vertrauenswürdiger Eingaben noch mehr Gewicht hat.
Häufige Fragen
Welche Git-Version sollte ich installieren?
Installiere 2.56.1 oder die korrigierte Version deiner Reihe, also 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 oder 2.50.2. Aktualisiere auch Anwendungen, die eine eigene Git-Kopie mitbringen.
Reicht es, keine unbekannten Repositorys zu klonen?
Es hilft, reicht aber nicht. GitHub empfiehlt, nur von vertrauenswürdigen Servern zu klonen und rekursive Klone, Merges und Binär-Patches aus nicht vertrauenswürdigen Quellen zu vermeiden. Diese Vorsichtsmaßnahmen ersetzen aber keine Updates.
Welche Sicherheitslücke ist die schwerwiegendste?
Die Quellen nennen keine Rangliste. Die Lücke, die Codeausführung bei einem rekursiven Klon ermöglicht, ist CVE-2026-111760, und auf sie konzentriert sich die Berichterstattung.
Ist Git for Windows schon aktualisiert?
Laut dem letzten Stand von The Hacker News noch nicht. Am Dienstag um 19.09 UTC war unter den Release-Tags keine Version auf Basis der 2.56.1 zu finden.
Müssen GitHub-Nutzer etwas tun?
Das hängt davon ab. GitHub hat github.com und die Enterprise-Cloud-Versionen bereits korrigiert. Wer Enterprise Server nutzt, muss auf eine der genannten Versionen wechseln, und wer lokale Werkzeuge verwendet, muss Git aktualisieren.
Git-Updates, die du in den nächsten Tagen im Auge behalten solltest
Die Korrektur existiert, aber ihre Verteilung läuft noch auseinander. Am besten verfolgst du, wer seine Version noch veröffentlichen muss.
- Prüfe, wann Git for Windows einen Build auf Basis der 2.56.1 veröffentlicht, und aktualisiere dann sofort.
- Achte darauf, wann korrigierte Versionen von GitHub Desktop, Copilot, Codespaces und Actions erscheinen.
- Wenn du einen Code-Hosting-Server betreibst, prüfe den Workaround von GitLab, bis du aktualisieren kannst.
