Git CVE-2026-111760: Ein zu langer Pfad schrumpft beim Auschecken auf die .git-Datei eines Submoduls

TL;DR — 90 Sekunden

• Was: Ein präpariertes Repository kann Git beim rekursiven Clone dazu bringen, die .git-Datei eines Submoduls durch einen Symlink auf ein Verzeichnis mit fremder Konfiguration und fremden Hooks zu ersetzen. Git führt danach Code des Angreifers aus.
• Schwere: Amazon bewertet die Lücke mit CVSS 8.8 (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H), für das GitHub-Advisory nennt SecurityOnline 8.0. Ein öffentlicher Exploit ist nicht bekannt, die Lücke steht nicht im CISA-KEV-Katalog.
• Wen es trifft: Jeden Rechner und jeden Dienst, der Repositories mit Submodulen rekursiv klont, deren Inhalt er nicht kontrolliert. Dazu gehören Entwicklerrechner, CI-Jobs mit rekursiver Submodul-Strategie und Argo CD, dessen repo-server Submodule ab Werk rekursiv aktualisiert.
• Was zu tun ist: Git auf 2.56.1 oder die passende Wartungsversion 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 oder 2.50.2 heben. Mitgelieferte Git-Kopien in Container-Images und Werkzeugen brauchen ein eigenes Update.
• Was vorher geschützt hätte: keine rekursiven Clones fremder Repositories, eine Objektprüfung beim Fetch mit harter Grenze für Pfadnamen und ein klonender Prozess mit wenig Rechten und wenig Netz. Ein globaler core.hooksPath und Container-Härtung verhindern die Ausführung dagegen nicht.

Wie ein geprüfter Pfad beim Schreiben kürzer wird

Git hält den Stand des Arbeitsverzeichnisses im Index fest, und jeder Eintrag dort ist im Code eine struct cache_entry. Sie enthält den Pfad als nullterminierte Zeichenkette und daneben seine Länge im Feld ce_namelen, das in read-cache-ll.h als unsigned int deklariert und damit auf gängigen Plattformen 32 Bit breit ist. Beim Auschecken baut Git aus den Tree-Objekten eines Commits solche Einträge, prüft jeden Pfad und schreibt die Dateien anschließend ins Arbeitsverzeichnis. Die Tree-Objekte selbst kennen diese Grenze nicht, ein Eintrag darin darf einen beliebig langen Namen tragen.

Heikel wird das durch Submodule. Ein geklontes Submodul hat in seinem Arbeitsverzeichnis kein eigenes .git-Verzeichnis, sondern eine kleine Datei namens .git, die mit einer Zeile gitdir: auf das eigentliche Repository unter .git/modules/ des übergeordneten Projekts verweist. Die Git-Doku nennt das ein gitfile. Diese eine Datei entscheidet also, welches Verzeichnis Git als Repository des Submoduls behandelt, und mit dem Verzeichnis kommen dessen config und dessen hooks. Zeigt sie auf ein Verzeichnis, das ein Angreifer im Arbeitsbaum mitgeliefert hat, liest Git dessen Konfiguration und startet dessen Hooks, und beide können beliebige Befehle enthalten.

Deshalb achtet Git seit Jahren darauf, dass kein Eintrag aus einem fremden Repository auf .git landet. Die Funktion verify_path_internal() in read-cache.c lehnt jeden Pfad ab, der eine Komponente .git enthält, auch in den Schreibweisen, die unter Windows gleichbedeutend sind. Sie arbeitet dabei mit der vollständigen Zeichenkette, während der Code in entry.c, der die Datei später anlegt, den Zielpfad aus ce->name und ce_namelen zusammensetzt. Solange beide Angaben übereinstimmen, fällt dieser Unterschied nicht ins Gewicht.

Genau hier lag der Fehler. In create_ce_entry() in unpack-trees.c berechnete Git die Länge des Pfads korrekt als size_t, reservierte genug Speicher und kopierte den vollen Namen, schrieb die Länge dann aber in das 32-Bit-Feld. Bei einem Pfad mit mehr als 2³² Bytes bleiben dort nur die unteren 32 Bit übrig. Die Prüfung sah den langen Namen und fand nichts zu beanstanden, geschrieben wurde aber nur sein Anfang. Laut Advisory kann der Angreifer diesen Anfang so wählen, dass er auf dem gitfile eines Submoduls endet. Ist der Eintrag als Symlink angelegt, ersetzt Git die Datei durch einen Verweis auf ein Verzeichnis des Angreifers. Warum ein solcher Symlink durchgeht, erklärt The Hacker News: Git fängt Symlinks über einem .git-Verzeichnis ab, in einem frisch geklonten Submodul ist .git aber eine Datei.

Das Muster ist nicht neu. Schon CVE-2024-32002 nutzte Submodule und Symlinks, um beim rekursiven Clone frisch geklonten Code auszuführen, damals über Dateisysteme, die Groß- und Kleinschreibung nicht unterscheiden. Auch diesmal treffen zwei Annahmen aufeinander, die einzeln harmlos wirken: dass der geprüfte Name derselbe ist wie der geschriebene, und dass kein Pfad so lang wird, dass seine Länge nicht mehr in ihr Feld passt.

Was der Fix ändert

Weil ich bis zum 11. November keinen einzelnen öffentlichen Fix-Commit abrufen konnte, habe ich die Quelltext-Tarballs von Git 2.50.1 und 2.50.2 von kernel.org verglichen. Der Kern steckt in read-cache.c. Eine neue Funktion verify_ce_namelen() bricht mit der Meldung „index entry path is too long“ ab, sobald eine Länge größer als INT_MAX ist, und die Funktionen, über die Git Speicher für Index-Einträge anlegt, rufen sie vor der Allokation auf. Ein Pfad, dessen Länge nicht in das Feld passt, wird damit gar nicht erst zum Eintrag.

Daneben ersetzt der Patch an mehreren Stellen int durch size_t und addiert Längen mit st_add(), das bei einem Überlauf abbricht, statt still umzubrechen, etwa in read_one_entry_opt() und in update_some() in builtin/checkout.c. Zusätzlich lehnt verify_path_internal() nun Pfade ab, die länger sind als die neue Einstellung index.maxPathLen. Ihr Standard liegt laut Doku bei 1073740799 Bytes, Werte über 2147483647 weist Git zurück. Die Release Notes führen diese Grenze ausdrücklich als zusätzliche Absicherung.

Am meisten verraten die neuen Tests in t/t1600-index.sh. Einer baut einen Tree-Pfad, dessen Länge auf einen kleinen Wert umbricht, andere prüfen, dass checkout, restore und ls-files ihn ablehnen, bevor seine Länge gekürzt wird. Das Problem war also keine einzelne vergessene Prüfung, sondern ein Datentyp, der an vielen Stellen schmaler war als die Werte, die durch ihn liefen. Deshalb setzt der Fix dort an, wo jeder Eintrag entsteht, und nicht an den vielen Stellen, an denen Git ihn später benutzt.

Vom fremden Repository zum Hook im eigenen Clone

Für den Angriff braucht es ein Repository mit Submodul, dessen Inhalt der Angreifer bestimmt, und ein Opfer, das es rekursiv klont, etwa mit git clone --recurse-submodules. Rechte auf dem Zielsystem braucht der Angreifer nicht, die nötige Nutzerinteraktion ist das Klonen selbst. Ab Werk ist ein einfaches git clone nicht betroffen, denn Git holt Submodule nur auf ausdrücklichen Wunsch, und auch die Einstellung submodule.recurse wirkt laut Doku nicht auf clone. Release Notes und GitHub-Blog nennen ausschließlich rekursive Clones als Auslöser. Ob schon ein nicht-rekursives git submodule update --init reicht, lassen beide offen, und das GitHub-Advisory selbst ließ sich bis zum 12. November nicht abrufen.

Konzeptionell besteht die Kette aus drei Gliedern. Das Repository enthält einen Tree mit einem überlangen Pfad, dessen gekürzte Form auf das gitfile eines Submoduls zeigt, und daneben ein Verzeichnis mit vorbereiteter Konfiguration und Hooks. Beim Auschecken ersetzt Git das gitfile durch den Symlink. Sobald Git danach im Submodul arbeitet, behandelt es das Verzeichnis des Angreifers als dessen Repository und führt aus, was dort hinterlegt ist. Lange, gleichförmige Namen lassen sich gut komprimieren, der Angreifer muss also nach meiner Einschätzung keine großen Datenmengen übertragen. Auf dem Opfer entsteht der Pfad aber vollständig im Speicher. Container mit knappem Speicherlimit dürften deshalb eher abbrechen, als den Angriff zu Ende zu führen. Das leite ich aus dem Code ab, und es ist kein Schutz, auf den du dich verlassen solltest.

Was dann passiert, läuft mit den Rechten des Prozesses, der klont. Auf einem Entwicklerrechner erreicht dieser Code SSH-Schlüssel, Cloud-Zugangsdaten und Tokens im Home-Verzeichnis. In einem CI-Job sind es die Variablen und Tokens dieses Jobs, und auf Runnern, die mehrere Jobs nacheinander auf demselben Host ausführen, womöglich mehr. Am heikelsten ist Argo CD. Sein repo-server ruft laut Quellcode bei jedem Checkout git submodule update --init --recursive auf, solange ARGOCD_GIT_MODULES_ENABLED nicht auf false steht, und der Standard ist true. Der repo-server bekommt die Zugangsdaten der Repositories, die er klont, und rendert die Manifeste, die Argo CD ausrollt. Wer ein Repository kontrolliert, das Argo CD synchronisiert, könnte nach meiner Einschätzung über diesen Weg Code im repo-server ausführen und gerenderte Manifeste beeinflussen.

Wirklich betroffen bist du also, wenn ein Prozess rekursiv Repositories klont, deren Inhalt nicht vollständig unter deiner Kontrolle steht. Dazu zählen auch eigene Repositories, deren Submodule auf Projekte Dritter zeigen, denn ein kompromittiertes Upstream-Projekt reicht als Einfallstor. Wer nur flache Clones ohne Submodule fährt, kann gelassen bleiben, sollte aber prüfen, ob ein Werkzeug nicht doch per Voreinstellung Submodule holt. GitLab-Betreiber sollten aus derselben Release-Welle vor allem CVE-2026-105437 im Blick haben, denn GitLab nennt in seinem Patch-Release vom 10. November nur diese Lücke und stuft sie als kritisch ein.

Bei den CVSS-Werten weichen die Quellen ab. Amazon vergibt 8.8 ohne erhöhte Angriffskomplexität, SecurityOnline nennt für das GitHub-Advisory 8.0, das ich selbst nicht abrufen konnte. Einen offiziellen Score der CNA gibt es noch nicht, denn die CVE-ID ist bei cve.org am 12. November weiterhin nur reserviert. Einen öffentlichen Exploit nennt bis zum 11. November keine der geprüften Quellen, Angriffe sind nicht bekannt, und im CISA-KEV-Katalog steht die Lücke nicht. Einen EPSS-Wert gibt es noch nicht, weil der CVE-Datensatz weder bei NVD noch in der CVE-Liste veröffentlicht ist. Die Tests im Patch zeigen allerdings recht genau, wo die Grenze liegt, und das senkt den Aufwand für einen Nachbau.

Git 2.56.1, die Wartungsversionen und die vergessenen Kopien

Das Git-Projekt hat am 10. November Git 2.56.1 veröffentlicht und den Fix in 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 und 2.50.2 zurückportiert. Wer einen älteren Zweig betreibt, bekommt upstream keinen Fix und ist auf seine Distribution angewiesen. Für GitHub Enterprise Server sind 3.19.15, 3.20.11, 3.21.9 und 3.22.4 erschienen, GitHub.com ist laut GitHub bereits gepatcht. Git for Windows hat 2.56.1 ebenfalls ausgeliefert.

Bei den Distributionen sah es am 11. November noch dünn aus. Das Amazon Linux Security Center führt das Paket git für Amazon Linux 2 und Amazon Linux 2023 als „Pending Fix“, ein ALAS gibt es noch nicht. Der Debian-Tracker markiert bookworm, trixie, forky und sid als verwundbar. Im Wolfi-Paketindex steht seit dem 11. November git 2.56.1-r0 für x86_64 und aarch64. Als behoben führt Wolfi die CVE in seinem Security-Feed aber noch nicht, und das öffentliche Paketrezept nannte am 12. November weiterhin 2.56.0. Welche Version in deinem Image steckt, zeigt apk info git. Nachtrag vom 12. November 2026: Amazon Linux 2 und Amazon Linux 2023 stehen im ALAS weiterhin auf „Pending Fix“, und Debian führt alle Zweige noch als verwundbar.

Die eigentliche Stolperfalle liegt woanders. Git steckt als eigene Kopie in vielen Container-Images und Werkzeugen, etwa im Argo-CD-Image, in CI-Base-Images, im Helper-Image eines GitLab Runners und in GitHub Desktop. Ein Update des Host-Pakets ändert an keiner dieser Kopien etwas. GitHub kündigt gepatchte Versionen für Actions, Codespaces, Desktop und die Copilot-App an. Für alle anderen Images musst du selbst sorgen, indem du sie neu baust, sobald das Base-Image das gepatchte Paket enthält.

Das Release ändert außerdem Verhalten, das mit dieser Lücke nichts zu tun hat. git fast-import lehnt die Funktionen rewrite-submodules-from, rewrite-submodules-to und export-pack-edges jetzt ab, solange du nicht --allow-unsafe-features setzt, was Migrationsskripte brechen kann. Die neue Grenze index.maxPathLen ist mit rund einem Gibibyte so hoch angesetzt, dass sie im Alltag niemand bemerkt.

Härtung, die schon vor dem Patch gegriffen hätte

Zuerst lohnt eine Einordnung, welche Maßnahmen gegen diesen Mechanismus überhaupt wirken können. Der Angriff verwandelt Daten aus einem Repository in Code, der beim Klonen startet, und das mit den ganz normalen Mitteln von Git: Konfiguration lesen und Hooks ausführen. Wirksam sind deshalb drei Ansätze: verhindern, dass fremde Repositories überhaupt rekursiv verarbeitet werden, missgebildete Objekte abweisen, bevor Git sie auscheckt, und begrenzen, was der klonende Prozess erreicht, falls doch fremder Code läuft. Container-Härtung gehört allein zum dritten Ansatz. Sie senkt den Schaden, die Ausführung selbst verhindert sie nicht.

Submodule nur dort, wo du sie brauchst

Die Lücke braucht einen rekursiven Clone, und die wirksamste Maßnahme ist deshalb, keine Submodule zu holen, wo sie niemand braucht. In Argo CD steuert der Schlüssel reposerver.enable.git.submodule in der ConfigMap argocd-cmd-params-cm das Verhalten des repo-servers, für den ApplicationSet-Controller gibt es applicationsetcontroller.enable.git.submodule. Beide stehen ab Werk auf "true". Der repo-server liest den Wert laut Quellcode beim Start aus der Umgebung, nach einer Änderung brauchst du also einen Neustart. Im GitLab Runner holt GIT_SUBMODULE_STRATEGY mit none keine Submodule, normal nur die oberste Ebene und recursive alle, und mit GIT_SUBMODULE_PATHS grenzt du die Auswahl ein. Die GitHub-Aktion actions/checkout holt Submodule nur mit submodules: true oder recursive, Standard ist false.

An ihre Grenze stößt die Maßnahme dort, wo Submodule tatsächlich gebraucht werden. Dann hilft es, Submodule nur aus eigenen, kontrollierten Quellen einzubinden und Inhalte Dritter lieber zu vendoren, also als geprüften Stand ins eigene Repository zu übernehmen. Denn ein Submodul, das auf ein fremdes Projekt zeigt, holt mit jedem Update Code, den du nicht gesehen hast, in einen Prozess, der beim Klonen Befehle ausführen kann.

Objektprüfung beim Fetch mit harter Grenze für Pfadnamen

Git kann empfangene Objekte prüfen, bevor es sie übernimmt. Mit transfer.fsckObjects=true bricht ein Fetch laut Doku bei missgebildeten Objekten ab, und die einzelnen Befunde lassen sich über fetch.fsck.<msg-id> schärfer stellen. Für diesen Fall interessant ist der Befund largePathname, der Tree-Einträge mit Namen über 4096 Bytes meldet, ab Werk aber nur als Warnung und damit folgenlos. Erst mit fetch.fsck.largePathname=error wird daraus ein Abbruch.

Warum das gegen genau diesen Mechanismus wirkt, ergibt sich aus einer zweiten Grenze. core.maxTreeDepth begrenzt die Verschachtelungstiefe beim Durchlaufen eines Trees, ab Werk auf 2048 Ebenen. Darf kein Name länger als 4096 Bytes sein und kein Pfad tiefer als 2048 Ebenen, bleibt jeder Pfad unter etwa 8,4 Megabyte und damit weit unter den vier Gibibyte, die der Überlauf braucht. Das ist meine Ableitung aus Doku und Quelltext und keine Aussage des Advisories. Bevor du dich darauf verlässt, prüfst du die Regel am besten mit einem eigenen Test-Repository und einer niedrigen Grenze wie error:100.

Die Maßnahme hat Grenzen und kostet etwas. Sie greift nur beim Übertragen über das Netz, lokale Clones aus einem Pfad prüft sie nach meinem Verständnis nicht. Ältere Repositories enthalten manchmal harmlose Formfehler, an denen eine strenge Prüfung ebenfalls scheitert. Solche Objekte nimmst du dann über fetch.fsck.skipList aus. Außerdem muss die Einstellung dort stehen, wo der klonende Prozess sie liest. Argo CD setzt laut Doku HOME auf /dev/null und unterstützt keine globale Git-Konfiguration, deshalb gehört sie dort in die Systemkonfiguration, die du per ConfigMap einhängst oder ins Image baust. Submodul-Clones lesen dieselbe System- und Nutzerkonfiguration wie der Clone, der sie anstößt, die Regel gilt also auch für sie.

index.maxPathLen nach dem Update enger stellen

Nach dem Update kannst du die neue Grenze selbst setzen. Linux begrenzt Pfade bei Dateisystemaufrufen über PATH_MAX ohnehin auf 4096 Bytes, ein längerer Eintrag ließe sich nach meinem Verständnis auf einem üblichen Linux-System also gar nicht auschecken. Ein systemweites index.maxPathLen=4096 kostet dort deshalb nach meiner Einschätzung nichts und zieht eine zweite Linie unterhalb der eingebauten. Für Builds unter Windows oder macOS solltest du den Wert vorher testen. Vor dem Update kennt Git die Einstellung nicht, sie ersetzt also weder den Patch noch die fsck-Regel.

Der klonende Prozess mit wenig Rechten und wenig Netz

Läuft doch fremder Code, entscheidet die Umgebung über den Schaden. CI-Jobs, die fremde Repositories bauen, gehören auf kurzlebige Runner, die nach jedem Job verworfen werden, ohne Docker-Socket und ohne privilegierten Modus. Im Kubernetes-Executor heißt das runAsNonRoot: true, allowPrivilegeEscalation: false, entzogene Capabilities und automountServiceAccountToken: false, damit ein Hook kein Token für die Kubernetes-API findet. Eine Egress-Regel, die nur Git-Hoster, Paketquellen und DNS erlaubt, erschwert das Abfließen von Zugangsdaten und den Aufbau einer Gegenverbindung. Für den Argo-CD-repo-server gilt dasselbe Prinzip. Ausgehend braucht er deine Git-, Helm- und OCI-Quellen sowie den Redis-Cache von Argo CD, aber keinen freien Weg ins Internet.

Den Code selbst stoppt keine dieser Maßnahmen. Ein Hook startet als gewöhnlicher Kindprozess von Git, und das ist ein Vorgang, den jede Pod-Security-Einstellung zulassen muss, weil Git ohne ihn nicht funktioniert. Die Maßnahmen sorgen aber dafür, dass die Beute klein bleibt, weil im Prozess wenige Geheimnisse liegen, kein Weg ins Cluster führt und die Umgebung nach dem Job verschwindet. Mehr zu Egress-Regeln und Pod-Sicherheit findest du in der Serie TYPO3 auf Kubernetes unter IT-Grundschutz.

Was hier nicht hilft

Ein globaler core.hooksPath auf ein leeres Verzeichnis klingt nach einer schnellen Abhilfe, greift hier aber nicht. Die Konfiguration des Angreifers liegt im Repository-Verzeichnis, und Git wertet die Repository-Konfiguration nach der globalen aus, sie gewinnt also. Außerdem kennt die Git-Konfiguration weitere Wege, Befehle zu starten, etwa über core.fsmonitor. Auch safe.directory hilft nicht, denn es prüft nur, wem ein Repository gehört, und frisch geklonte Dateien gehören dir selbst.

seccomp, entzogene Capabilities und readOnlyRootFilesystem bleiben richtig, sind gegen die Ausführung aber wirkungslos, weil das Starten eines Hooks ein normaler execve ist und das Arbeitsverzeichnis schreibbar sein muss. Signierte Commits schützen ebenfalls nicht, weil die Signatur in der Regel erst geprüft wird, wenn der Checkout schon gelaufen ist. Ein CVE-Gate in der Pipeline schlägt erst an, wenn der Scanner die Lücke kennt, und weil der CVE-Datensatz am 11. November weder bei NVD noch bei OSV stand, dürften viele Scanner sie noch nicht melden. Wer sich allein darauf verlässt, erfährt in dieser Zeit nur aus den Release Notes davon.

Erkennung und Prüfung

Ob du betroffen bist, zeigt zuerst git --version, und zwar überall dort, wo Git läuft: auf Hosts, in jedem Image, das klont, im Argo-CD-Image und im Helper-Image deiner Runner. Danach lohnt der Blick auf die Konfiguration. Suche in Pipelines nach --recurse-submodules, nach GIT_SUBMODULE_STRATEGY mit normal oder recursive und nach submodules: in Checkout-Schritten, und prüfe in Argo CD die Werte in argocd-cmd-params-cm. Ein Prozess mit verwundbarem Git und rekursivem Clone fremder Inhalte ist ein Fall für sofortiges Handeln.

Ob jemand die Lücke ausgenutzt hat, lässt sich schwerer sagen, und Advisory wie Release Notes nennen keine Indikatoren. Aus dem Mechanismus leite ich zwei Hinweise ab. Ein Submodul, dessen .git ein Symlink statt einer Datei ist, ist kein normaler Zustand. Du findest solche Fälle, indem du in Arbeitsverzeichnissen und im Cache des repo-servers nach Einträgen namens .git vom Typ Symlink suchst. Nach dem Update bricht Git außerdem mit „index entry path is too long“ ab, wenn ihm ein solcher Pfad begegnet. Weil kein gewöhnliches Projekt Pfade dieser Länge enthält, ist diese Meldung in Job-Logs ein starkes Zeichen für ein präpariertes Repository. Abbrüche wegen Speichermangel beim Klonen eines kleinen Repositories sind ein schwächeres Signal in dieselbe Richtung.

Bei einem Verdacht behandelst du die Umgebung, die geklont hat, als kompromittiert. Verwirf den Runner oder Pod, rotiere alle Zugangsdaten, die der Prozess sehen konnte, also SSH-Schlüssel, CI-Tokens und die Repository-Credentials von Argo CD, und prüfe, welche Artefakte, Commits oder Manifeste aus dieser Umgebung stammen. Ein betroffener Entwicklerrechner verdient dieselbe Sorgfalt wie jeder andere Rechner mit fremdem Code.

Betreiberempfehlung

Akut handeln solltest du, wenn Argo CD mit Standardeinstellungen Repositories synchronisiert, die nicht allein dein Plattform-Team pflegt, oder wenn CI-Jobs Repositories Dritter rekursiv klonen. Schalte dort die Submodul-Unterstützung ab, wo sie niemand braucht, setze die fsck-Regel in die Systemkonfiguration und baue die betroffenen Images neu, sobald gepatchtes Git verfügbar ist. Entwickler, die regelmäßig fremde Projekte mit Submodulen klonen, sollten ihr lokales Git noch heute aktualisieren.

Beobachten genügt, wenn du ausschließlich eigene Repositories ohne Submodule klonst und nirgends eine rekursive Strategie aktiv ist. Das Update gehört trotzdem ins nächste Wartungsfenster, schon weil dasselbe Release fünf weitere Lücken schließt, darunter den Heap-Überlauf beim Mergen, der Git-Server trifft.

Unabhängig vom Einzelfall gilt, was ich bei jeder Lücke sage: Patches und Updates gehören automatisiert. Gerade Git zeigt, warum das bis in die Images reichen muss, denn die verwundbare Kopie steckt selten im Host-Paket und fast immer in einem Base-Image, das seit Monaten niemand neu gebaut hat. Wenn Renovate oder Dependabot neue Base-Images, Image-Digests und Helm-Charts wie das von Argo CD selbstständig als Merge Request vorschlagen und die Pipeline sie gegen Staging testet, ist ein Security-Release wie Git 2.56.1 eine Sache von Stunden statt Wochen. Eine Karenzzeit für Routine-Updates schützt vor kompromittierten Releases, Sicherheitsupdates nimmst du davon aus. Und falls die strengere fast-import-Prüfung ein Migrationsskript bricht, fällt das im Test auf und nicht in Produktion. Wer von Hand aktualisiert, hat in der Urlaubszeit schnell Wochen ohne Patch und danach ein Sammel-Update, bei dem niemand mehr weiß, welche Änderung was ausgelöst hat.

Fazit

CVE-2026-111760 ist eine Lücke zwischen Prüfen und Benutzen. Git prüfte einen Namen und schrieb einen anderen, weil die Länge auf dem Weg dorthin in ein zu schmales Feld fiel. Lehrreich ist vor allem der Fix. Er sorgt dafür, dass ein Eintrag, dessen Länge nicht darstellbar ist, gar nicht erst entsteht, statt an jeder späteren Stelle nachzuprüfen. Die Lehre reicht weit über Git hinaus. Wo immer ein System eine Eingabe in einer Form prüft und in einer anderen verarbeitet, liegt dieselbe Klasse von Fehlern bereit, wie in derselben Woche der Signatur-Bypass in Keycloak zeigt. Für den Betrieb bleibt eine einfache Regel: Ein rekursiver Clone fremder Inhalte ist das Ausführen fremder Daten, und er verdient dieselbe Vorsicht wie jeder andere fremde Code.

Quellen

• Git Advisory GHSA-vp2w-7xxj-jvxr (CVE-2026-111760)
• Git v2.50.2 Release Notes
• kernel.org: Git-Quelltext-Tarballs 2.50.1 und 2.50.2 (Vergleich von read-cache.c, unpack-trees.c, builtin/checkout.c, t/t1600-index.sh)
• GitHub Blog: Git security vulnerabilities announced
• Git for Windows 2.56.1
• Amazon Linux Security Center: CVE-2026-111760
• Debian Security Tracker: CVE-2026-111760
• CVE.org: CVE-2026-111760 (Status reserviert)
• GitLab Critical Patch Release 19.5.4, 19.4.6, 19.3.8
• GitHub Advisory GHSA-m7r7-8v36-j77r (CVE-2026-105437)
• The Hacker News: Git Patches Flaw That Lets Malicious Repositories Execute Code During Recursive Clones
• SecurityOnline: Git 2.56.1 Patches Six Security Flaws
• Git Docs: git-config (index.maxPathLen, core.maxTreeDepth, transfer.fsckObjects, fetch.fsck, submodule.recurse)
• Git Docs: git-fsck, Message-ID largePathname
• Git Docs: gitsubmodules
• Argo CD: util/git/client.go (Submodul-Update)
• Argo CD: argocd-cmd-params-cm.yaml
• Argo CD Docs: Git Configuration
• GitLab Docs: Configure runners, GIT_SUBMODULE_STRATEGY
• actions/checkout: action.yml