Git korrigiert CVE-2026-111760, die Code Ausführung in Submodulen während des Klonens erlaubt

In dieser Woche veröffentlichte das Git-Projekt eine Korrektur für ernsthafte Sicherheitslücke (CVE-2026-111760), die es einem schädlichen Repository ermöglicht, die Ausführung von Code in der Maschine zu verursachen, die es rekursiv zusammen mit seinen Submodulen klonen. Das Problem wurde in Git 2.56.1 gelöst und für die Zweige 2.50 bis 2.55 passende Patches veröffentlicht. Die Korrekturen verhindern, dass zu lange Dateiwege durch Sicherheitskontrollen passieren und werden dann beim Schreiben auf Festplatte mit einem Namen, dass ein Angreifer auf .git drücken kann, abgeschnitten, der die Tür zum Austausch der .git-Datei eines Submoduls durch eine symbolische Verbindung zu einem Ort öffnet, der vom Angreifer gesteuert wird. Einmal da, Git kann Haken oder Konfigurationsdateien von diesem Ort lesen und beliebigen Code zu Zeiten ausführen, die durch den normalen Git-Flow gesteuert werden.

Was geschah (bestätigte Fakten): das Git-Projekt weiß von einem ganzen Unterbrechungsfehler in der Verwaltung des Index, der eine extrem lange Strecke erlaubt, die durch die Sicherheitskontrollen blockiert werden sollte, passieren und dann wird es mit einem kürzeren Namen geschrieben. Dieser Unterschied zwischen der Prüfung und dem Schreiben erlaubt dem resultierenden Namen genau ".git". Seit Git behandelt ein .git-Verzeichnis und eine .git-Datei unterschiedlich innerhalb eines neu geklonten Submoduls, ein Angreifer kann dieses Verhalten verwenden, um eine .git-Datei zu verlassen, die tatsächlich eine symbolische Verbindung zu einem angreifenden Ordner mit Haken oder anderen ausführbaren Dateien ist. Git führt Haken an bestimmten Punkten (z.B. Post-Check, Pre-Commit, etc.), so dass die Aktivierung dieser Haken von einem vom Angreifer gesteuerten Ort die Route zur Remote-Code-Ausführung ist. Die angegebene Korrektur lehnt solche langen Strecken ab, bevor es eine Möglichkeit gibt, dass der Name gekürzt wird und .gitto werden kann. Diese Korrekturen sind in Git's Release Note verfügbar 2.56.1: https: / / github.com / git / git / releases / tag / v2.56.1.

Wie es technisch funktioniert (Erklärung): vulnerability ist eine Bedingung der Verknüpfung von Ganzzahlen in Logik, die Einträge im Git-Index validiert und schreibt. Während einer rekursiven Klonierung mit Submodulen führt Git Sicherheitsüberprüfungen auf den Routen durch, die er vom entfernten Repository erhält. Wenn eine Route eine bestimmte Größe überschreitet, sollte sie ungültig gemacht werden. Allerdings wird in diesem Fall die Überprüfung mit einem Wert durchgeführt, der später (durch Abkürzung) reduziert wird, wenn Git entscheidet, wie man die Datei auf dem Datenträger erstellt. Ein langer Name kann, nachdem er gekürzt wurde, mit .git übereinstimmen. In neu erstellten Submodulen ist .git kein Standard-Verzeichnis, sondern eine Datei, die den Standort des Git-Objekts angibt; diese Datei kann durch einen symbolischen Link ersetzt werden, weil Git keinen Link in einem neu geklonten Submodul erwartet. Wenn der Link auf einen Ordner mit schädlichen Haken oder Konfigurationsdateien zeigt, können später normale Git-Operationen diesen Code ausführen oder Einstellungen lesen, die das Verhalten des Kunden ändern.

Wer betroffen ist und was das reale Risiko ist (bestätigt vs geschätzt): Geräte und Dienstleistungen, die vorkorrigiert werden Git-Versionen und die Durchführung von rekursiven Klonierungsoperationen von nicht zuverlässigen Repositories sind betroffen. Git-Client-Nutzer, die von dritten Anwendungen (IDE, Grafik-Kunden, Git-Kopien innerhalb von Apps) verpackt sind, sind potenziell gefährdet, wenn diese Anwendungen die integrierte Kopie nicht aktualisieren. GitHub hat die Korrekturen auf seine öffentliche Infrastruktur und auf GitHub Enterprise Cloud angewendet, und hat berichtet, dass Versionen von GitHub Enterprise Server und einigen GitHub-Anwendungen erhalten oder bereits Updates erhalten haben; Git-Betreuer für Windows und andere Distributionen nahmen jedoch Zeit, Binaries basierend auf 2.56.1 zum Zeitpunkt der ersten Ankündigung zu veröffentlichen. Das heißt, bis jede verteilte Plattform oder Paket aktualisiert Ihre Git copy, das Risiko bleibt bestehen für diejenigen, die nicht oder nicht bereit sind, zu aktualisieren.

Es ist wichtig zu betonen, was nicht öffentlich bestätigt wird: Es gibt keinen klaren Hinweis in den offiziellen Anmerkungen zur aktiven Ausbeutung in der Natur (es gab keine weit verifizierten öffentlichen Proben oder Forensberichte zum Zeitpunkt des Patches). Angesichts des Vektors - Repositories, die rekursiv kloniert werden - und der Leichtigkeit, Submodule einzubetten, ist das Missbrauchsrisiko theoretisch hoch, vor allem gegen Entwickler und Server, die Klone und Drittprojekte automatisieren. Dienstleistungen, die im Auftrag von Benutzern Zusammenführungen oder Überprüfungen durchführen (z.B. Überprüfungen auf kontinuierlichen Integrationsservern oder Hosts, die von Benutzern bereitgestellte Codeoperationen ausführen) sind Gruppen, die nach GitLab bevorzugt Ziele für Exploits sein können, die auf den Befehl git merge-tree fokussiert sind.

Sonstige Korrekturen einschließlich: Neben der CVE-2026-111760, die letzte Runde der Patches fixiert mehrere Fehler mit Potenzial für Speicher Korruption, Off-Limits Lesen und Missbrauch von schnellen Importfunktionen. Unter ihnen sind Schwachstellen, die ein Schreiben außerhalb des Referenzbaums nach einem leeren Klon durch Protokoll v2, korrupte Etiketten mit mehreren GPG-Signaturen, binäre Patches, die die Grenze überschreiten und Off-Limit-Lesen verursachen, Überschreiben von Puffer in sehr großen Zusammenführungen mit modifizierten Konfliktmarker-Größe-Attributen und die Möglichkeit, beliebige Dateien durch bestimmte Merkmale von Git Fast-Import zu lesen oder zu erstellen; Letztere sind jetzt gesperrt, es ist nicht explizit. Die zusätzlichen technischen Details und Minderungen wurden vom Git-Projekt und von Unternehmungsteams wie GitHub und GitLab dokumentiert.

Was sollte der Leser jetzt tun (betonte Aktionen): Überprüfen Sie zunächst die Git-Version auf den Maschinen, die Sie ausführen Git lokal (z.B. mit git --version). Wenn Sie eine Version vor 2.56.1 oder die geparched Versionen der 2.50-2.55 Filialen verwenden, aktualisieren Sie so schnell wie möglich von der offiziellen Quelle oder Paketmanager Ihres Systems. Wenn Ihre Organisation GitHub Enterprise Server-Instanzen verwendet, überprüfen Sie die Versionshinweise für die geparched Versionen (die Unternehmensversionen, die die Korrekturen bereits erhalten haben, werden von GitHub aufgelistet) und wenden Sie die Plattform-Updates entsprechend dem Wartungsplan an. Auch, wenn Sie Anwendungen verwenden, die Ihre eigene Kopie von Git enthalten (Desktop-Kunden, IDs, Container oder Drittanbieter-Apps), fragen oder überprüfen mit dem Lieferanten, wenn sie die korrigierte Version eingeben und Ihre Updates anwenden. GitHub veröffentlicht auch vorläufige Empfehlungen: Klon nur aus Ursprüngen, die Sie vertrauen und vermeiden die Verwendung von rekursiven Klonen in nicht verifizierten Repositories; nicht vermischen Inhalte oder Etiketten aus unzuverlässigen Quellen; und verarbeiten nicht binäre Patches oder Fast-Import-Flows aus unzuverlässigen Quellen. Weitere Details zum Git-Update finden Sie in der offiziellen Dokumentation: https: / / docs.github.com / en / get-started / use-git / update-git. Um zu verstehen, wie die Haken, die missbraucht werden können, Gits offizielle Dokumentation auf Haken ist nützlich: https: / / git-scm.com / docs / githouks.

Als zusätzliche Maßnahme für Serveradministratoren, die noch nicht aktualisiert werden können, haben GitLab und andere temporäre Minderungen für bestimmte Fehler vorgeschlagen (z.B. die Einstellung von Konflikt-Marker-Größe in Info / Attribute der Repositories oder die Deaktivierung von Merge@-Baum für unzuverlässige Repos). Diese spezifischen Maßnahmen entsprechen bestimmten Schwachstellen zwischen den korrigierten und sind in Kontexten anwendbar, in denen eine sofortige Aktualisierung nicht möglich ist.

Abstract: Schwachstelle legt einen praktischen Vektor frei, um Code in bösartigen Submodulen enthalten während des rekursiven Klonens auszuführen. Die offizielle Lösung ist bereits veröffentlicht; die unmittelbare Verantwortung besteht darin, die in eigenen Systemen und Dienstleistungen verteilten Kopien von Git zu aktualisieren und automatisierte Operationen auf Lagerstätten mit zweifelhaftem Ursprung zu vermeiden, bis alle Teile des Ökosystems (Betriebssysteme, Kunden und Dienstleistungen) die Korrektur einschließen.