Git: Bösartige Repositories können beim rekursiven Klonen Code ausführen (CVE-2026-111760)

Was ist passiert

Am 11. November 2026 hat das Git-Projekt neue Versionen veröffentlicht, die sechs Sicherheitslücken beheben. Die gravierendste ist CVE-2026-111760. Das rekursive Klonen eines bösartigen Repositorys, also zusammen mit seinen Submodulen, kann den Code des Angreifers auf dem Rechner ausführen, der den Klon erstellt.

Ursache ist ein Integer-Abschneiden (Integer Truncation) bei der Verarbeitung des Index durch Git. Ein sehr langer Pfad besteht die Sicherheitsprüfung von Git, doch Git schreibt ihn anschließend unter einem kürzeren Namen auf die Festplatte. Diesen kürzeren Namen kann ein Angreifer wählen. So kann er die .git-Datei eines Submoduls durch einen symbolischen Link auf ein Verzeichnis ersetzen, das bösartige Hooks oder Konfigurationen enthält. Verwendet Git dieses Verzeichnis anschließend, läuft der Code des Angreifers. Die Korrektur sorgt dafür, dass Git solche sehr langen Pfade ablehnt, bevor ihre Länge gekürzt werden kann.

Dieselben Versionen beheben fünf weitere Schwachstellen:

• CVE-2026-113408: Wenn jemand ein leeres Repository über das Git-Protokoll v2 klont, kann ein bösartiger Server einen Branch-Namen mit Path Traversal senden. Mit dem Referenz-Backend „files“ kann ein späteres Update dieses Branches dann außerhalb des Referenzverzeichnisses von Git schreiben.
• CVE-2026-114467: Das Zusammenführen eines Tags mit mehr als zwei GPG-Signaturen beschädigt den Stack-Speicher und kann einen Denial of Service auslösen. Hosting-Dienste, die solche Zusammenführungen für ihre Nutzer ausführen, können ebenfalls betroffen sein.
• CVE-2026-114469: Ein Binary Patch, der sich auf eine sehr große Größe ausdehnt, kann die Patch-Größenbegrenzung von Git von etwa 1 GiB umgehen und Git mit einem Out-of-Bounds-Read zum Absturz bringen.
• CVE-2026-105437: Eine sehr große Zusammenführung mit vielen Konflikten und einem großen Attribut conflict-marker-size kann dazu führen, dass Git über das Ende eines Heap-Puffers hinaus schreibt. GitLab nennt Code-Hosting-Server als wahrscheinlichste Ziele, und zwar über git merge-tree, das Server ausführen, um zu prüfen, ob ein Pull- oder Merge-Request zusammengeführt werden kann.
• CVE-2026-114466: Drei Funktionen von git fast-import (rewrite-submodules-from, rewrite-submodules-to und export-pack-edges) konnten genutzt werden, um beliebige Dateien zu lesen oder Dateien zu erstellen und Daten in sie zu schreiben. Git lehnt sie nun in einem Eingabestrom ab, sofern --allow-unsafe-features nicht gesetzt ist.

Bislang meldet keine der Quellen Angriffe.

Wer betroffen ist

Betroffen ist jedes System, auf dem eine Git-Version vor diesen korrigierten Versionen läuft: 2.56.1, 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 und 2.50.2. Auf Servern sind vor allem folgende betroffen:

• Build-, CI- und Deployment-Server, die Repositories rekursiv klonen (git clone --recursive, --recurse-submodules oder git submodule update --init), insbesondere Repositories oder Submodule von Drittanbietern. Damit CVE-2026-111760 funktioniert, muss das geklonte Repository bösartig sein. Wenn Sie nur eigene, vertrauenswürdige Repositories klonen, ist das Risiko deutlich geringer, dennoch sollten Sie aktualisieren.
• Selbst gehostete Git-Hosting-Server, die Zusammenführungen oder Merge-Prüfungen für Inhalte ausführen, die Nutzer hochladen (CVE-2026-105437, CVE-2026-114467).
• GitHub Enterprise Server: Die Korrekturen stehen in den Versionen 3.19.15, 3.20.11, 3.21.9 und 3.22.4 bereit.
• Anwendungen, die eine eigene Git-Kopie mitliefern. Sie benötigen ein Update von ihrem Hersteller.

Nicht betroffen: github.com und GitHub Enterprise Cloud. GitHub hat die Korrekturen dort bereits eingespielt. Webserver mit installiertem Git, die jedoch nie Inhalte von außen klonen oder zusammenführen, sind für die Klon-Lücke in der Praxis nicht angreifbar. Aktualisieren Sie sie trotzdem bei der nächsten Wartung.

Für Git for Windows gab es am 10. November 2026 um 19:09 UTC noch keine Version auf Basis von Git 2.56.1. Windows-Administratoren sollten auf diese Veröffentlichung achten.

Was jetzt zu tun ist

1. Prüfen Sie die installierte Version auf jedem Server mit git --version.
2. Installieren Sie eine korrigierte Version über den Paketmanager Ihres Betriebssystems (zum Beispiel apt update && apt install --only-upgrade git oder dnf upgrade git). Distributionen übernehmen Korrekturen häufig in ihre eigenen Paketversionen. Prüfen Sie daher die Sicherheitshinweise Ihrer Distribution, um das korrigierte Paket zu finden. Wenn Sie Git selbst bauen, aktualisieren Sie auf 2.56.1 oder auf die korrigierte Version Ihrer Reihe.
3. Aktualisieren Sie GitHub Enterprise Server je nach Release-Linie auf 3.19.15, 3.20.11, 3.21.9 oder 3.22.4. Aktualisieren Sie andere Anwendungen, die eine eigene Git-Kopie mitliefern, sobald ihr Hersteller eine Korrektur veröffentlicht.
4. Bis alle Systeme aktualisiert sind, folgen Sie der vorläufigen Empfehlung von GitHub. Diese Schritte ersetzen das Update nicht:
   • Klonen Sie nur von Servern, denen Sie vertrauen.
   • Klonen Sie keine Repositories rekursiv, denen Sie nicht vertrauen.
   • Führen Sie keine Inhalte oder Tags zusammen, denen Sie nicht vertrauen.
   • Verarbeiten Sie keine Binary Patches oder fast-import-Streams aus nicht vertrauenswürdigen Quellen.
5. Schützen Sie Git-Hosting-Server, die noch nicht aktualisiert werden können, vor CVE-2026-105437. Fügen Sie conflict-marker-size=7 in die Datei info/attributes jedes Repositorys ein oder deaktivieren Sie Merge-Prüfungen für nicht vertrauenswürdige Repositories.
6. Starten Sie langlaufende Dienste neu, die Git aufrufen, etwa CI-Runner oder Git-Hosting-Daemons, damit sie die neue Binärdatei verwenden.

So prüfen Sie, ob Sie betroffen sind

• Führen Sie git --version aus. Versionen, die älter als die korrigierte Version ihrer Reihe sind, sind betroffen: 2.50.2, 2.51.3, 2.52.1, 2.53.1, 2.54.1, 2.55.1 oder 2.56.1. Bei Distributionspaketen vergleichen Sie die Paketversion mit dem Sicherheitshinweis Ihrer Distribution, nicht mit der Upstream-Versionsnummer.
• Durchsuchen Sie Ihre Build- und Deployment-Skripte sowie CI-Konfigurationen nach --recursive, --recurse-submodules und submodule update. Prüfen Sie, welche der geklonten Repositories von Drittanbietern stammen.
• Suchen Sie nach Git-Kopien außerhalb des Paketmanagers, zum Beispiel mit which -a git. Prüfen Sie außerdem das Git, das in CI-Runnern, Containern und anderen Anwendungen enthalten ist.

Quellen

• https://nvd.nist.gov/vuln/detail/CVE-2026-111760
• https://thehackernews.com/2026/11/git-patches-flaw-that-lets-malicious.html