Git 2.56.1 schließt sechs Sicherheitslücken – und Ihre CI-Runner brauchen das Update dringender als Ihr Laptop

Am 10. November hat das Git-Projekt Git 2.56.1 veröffentlicht, dazu gepatchte Releases für ältere Wartungszweige: 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 und 2.50.2. Zusammen schließen sie sechs CVEs: CVE-2026-111760, CVE-2026-113408, CVE-2026-114467, CVE-2026-114469, CVE-2026-105437 und CVE-2026-114466. Das Projekt spricht von koordinierten Security-Fix-Releases und bittet darum, so bald wie möglich zu aktualisieren. Gefunden haben die Fehler Luke Martin und pwn2addr.

Relevant ist vor allem CVE-2026-111760, im Security Advisory des Projekts als High mit CVSS 8.0 eingestuft. Die Kurzfassung: Im Index-Code von Git gibt es einen Integer-Truncation-Fehler. Ein sehr langer Pfad wird unter seinem vollen Namen geprüft, landet aber unter einem kürzeren auf der Platte. Mit dieser Diskrepanz kann ein Angreifer die .git-Datei eines Submoduls durch einen Symlink ersetzen, der auf ein Verzeichnis unter seiner Kontrolle zeigt – gefüllt mit eigener Konfiguration oder eigenen Hooks. Hooks sind Code. Ein rekursiver Clone des falschen Repositorys kann also damit enden, dass fremder Code auf Ihrer Maschine läuft. Laut Advisory ist das vermutlich nur erreichbar, wenn Sie --recurse-submodules verwenden.

GitHub hat github.com, GitHub Enterprise Cloud und Enterprise Cloud mit Datenresidenz bereits gepatcht. Wenn Sie GitHub Enterprise Server selbst betreiben, lauten die korrigierten Versionen 3.19.15, 3.20.11, 3.21.9 und 3.22.4.

Der Score unterschätzt das Risiko für die meisten Teams

Wer den CVSS-Vektor liest, lehnt sich vielleicht zurück: hohe Angriffskomplexität, niedrige Rechte, Nutzerinteraktion erforderlich. Auf einem Entwickler-Laptop stimmt das: Jemand muss ein feindliches Repository rekursiv klonen.

Aber überlegen Sie, wer in Ihrer Organisation tatsächlich git clone ausführt. Meistens sind es keine Menschen, sondern CI-Runner, hunderte Male am Tag, ohne dass jemand zuschaut, mit Deploy-Keys und Cloud-Zugangsdaten in Umgebungsvariablen. „Nutzerinteraktion erforderlich“ bedeutet wenig, wenn der Nutzer eine YAML-Datei ist.

Wenn wir Cloud-native-Apps für Unternehmenskunden bauen, ist das relevante Git selten das auf irgendeinem Laptop. Es ist das Git im Docker-Base-Image, das vor eineinhalb Jahren jemand ausgewählt hat, das auf dem selbst gehosteten Runner, das im Deploy-Container. Ein Paket-Update auf Ihrem Mac berührt nichts davon. Aus unserer PHP- und Docker-Arbeit schätze ich ehrlich: Die meisten Teams haben drei oder vier verschiedene Git-Versionen in ihren Build- und Deploy-Pfaden und könnten sie nicht aufzählen, ohne nachzusehen.

Mobile-Teams kennen ihre eigene Variante. In unseren nativen iOS- und Android-Projekten sind Submodule weiterhin ein gängiger Weg, gemeinsame SDKs, mitgelieferte native Bibliotheken oder ein internes UI-Kit einzubinden. Die Build-Maschinen sind oft langlebige Macs, die seit Ewigkeiten niemand neu aufgesetzt hat. Außerdem empfiehlt das Git-Projekt ausdrücklich, jede Anwendung zu aktualisieren, die eine eigene Git-Kopie mitbringt – das betrifft einige IDEs und Desktop-Clients. Das System-Git zu aktualisieren, behebt das dort nicht.

Sicherheitstechnisch passt das zu einem Muster, das uns immer wieder begegnet. In unseren Pentests ist die Build-Pipeline regelmäßig der einfachste Einstieg, weil sie Dingen vertraut, die niemand in die Nähe der Produktion lassen würde: dem Fork eines Auftragnehmers, dem Beispielprojekt eines Anbieters, einer Open-Source-Abhängigkeit als Submodul. Man vergisst gern, dass Hooks ausführbar sind. Angreifer vergessen das nicht.

Ich gebe zu, ich habe gemischte Gefühle. Sechs CVEs auf einmal, in einem so alten und so vertrauten Tool, sind etwas beunruhigend. Gleichzeitig sind koordinierte Fixes über sieben Release-Linien genau die unspektakuläre, kompetente Wartung, die man von einem Projekt erwartet, von dem alle abhängen. Der Fix ist da. Der schwierige Teil liegt bei uns: jede Kopie finden.

Was ich diese Woche tun würde

1. Inventarisieren Sie jedes Git-Binary, nicht nur Laptops. Führen Sie git --version in Ihren CI-Images, Dockerfiles, selbst gehosteten Runnern und Build-Macs aus. Sie wollen 2.56.1 oder das gepatchte Release Ihrer Serie (2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 oder 2.50.2).
2. Bauen Sie Base-Images gezielt neu. Verlassen Sie sich nicht darauf, dass der nächste geplante Rebuild ein korrigiertes Git enthält. Prüfen Sie die Version im gebauten Image.
3. Wenn Sie GitHub Enterprise Server selbst hosten, wechseln Sie auf 3.19.15, 3.20.11, 3.21.9 oder 3.22.4.
4. Durchsuchen Sie Ihre Pipeline-Konfiguration nach rekursiven Submodul-Checkouts. Wo das Eltern-Repository oder ein Submodul nicht vollständig unter Ihrer Kontrolle steht, schalten Sie die Rekursion ab, bis der Runner gepatcht ist.
5. Solange nicht alles aktualisiert ist, befolgen Sie die Zwischenempfehlung des Projekts: nur von vertrauenswürdigen Servern klonen, nicht vertrauenswürdige Repositorys nicht rekursiv klonen und vorsichtig sein beim Mergen fremder Inhalte oder Tags, beim Anwenden von Binär-Patches und beim Einspeisen von fast-import-Streams aus Quellen, die Sie nicht kontrollieren.

Für unsere Schweizer Kunden mit Compliance-Anforderungen würde ich einen sechsten Schritt ergänzen: Dokumentieren Sie, was Sie wann gepatcht haben. Auditoren mögen Nachweise, und bei einem so verbreiteten Patch halten Sie diese besser bereit, statt sie später zu rekonstruieren. Solche Pipeline-Hygiene behandeln wir, wenn wir Build- und Deploy-Infrastruktur aufsetzen, und sie kommt ständig in unseren Security-Reviews vor.

Wenn Sie nicht sicher sind, wie viele Git-Kopien sich in Ihrer Build-Pipeline verstecken, sprechen Sie uns an.