GitPython: fehlerhafte Ablaufreihenfolge (CVE-2026-114145)

Zusammenfassung

create_submodule(name, path, url) kloniert ein Submodul in das .git-Verzeichnis des Repositories, bevor es den Pfad ablehnt. Ein Pfad von ".git/hooks" wird von der Vorabprüfung akzeptiert, sodass das Submodul direkt in das laufende Hooks-Verzeichnis geklont wird. Eine Datei namens post-checkout im Submodul wird zu einem ausführbaren .git/hooks/post-checkout. Ab Version 3.2.0+ löst die spätere Indexprüfung einen ValueError aus, aber nur nachdem das Klonen bereits auf die Festplatte geschrieben hat, und es entfernt das eingepflanzte Hook nicht; in Version 3.1.x gibt es keine solche Prüfung und der Aufruf schlägt stillschweigend fehl. In beiden Fällen wird der Hook bei der nächsten Git-Operation (z. B. Checkout) ausgeführt, was zur Code-Ausführung führt.

Details

Der Checkout-Pfad wird zu spät validiert, nachdem das Klonen bereits die Festplatte verändert hat. Dies bricht die "Validierung vor Mutation" Invariante, die der Commit 43a43cd8 ("Validierung von Submodul-Checkout- und Metadatenpfaden vor Mutation") durchsetzen wollte.

Submodule.add() ruft die permissive Pfadprüfung vor dem Klonen auf, und die strenge Prüfung erreicht das ".git"-Alias nur zur Indexzeit, nachdem _clone_repo auf die Festplatte geschrieben hat:

git/objects/submodule/base.py (Submodule.add) 599: path = cls._to_relative_path(repo, path) # akzeptiert ".git/hooks" 673: mrepo = cls._clone_repo(repo, url, path, name, ...) # kloniert in /.git/hooks 714: index.add([sm], write=True) # strenge Prüfung löst hier aus

git/index/base.py (IndexFile._preprocess_add_items) 732: _validate_repo_path(entry.path) # lehnt ".git" ab, aber zu spät

_to_relative_path blockiert nur ../absolute/out-of-tree-Pfade; .git-Aliasse werden nur durch _validate_repo_path abgelehnt, das in Version 3.2.0 (Commit a75aedf3) hinzugefügt wurde und an der Indexgrenze läuft. Der ValueError, den es auf Zeile 732 auslöst, rollt nicht zurück, was _clone_repo bereits geschrieben hat.

Versionsabhängiges Verhalten:

• 3.2.0 .. tip bda18e08: _validate_repo_path löst ValueError bei index.add aus, aber der Hook ist bereits auf der Festplatte und wird nicht entfernt (falsche Reihenfolge von Validierung vs. Klonen).
• 3.1.x (z. B. 3.1.59): _validate_repo_path existiert nicht und _to_relative_path lehnt .git nicht ab; create_submodule(path=".git/hooks", ...) gibt ohne Fehler zurück und pflanzt den Hook stillschweigend.

Proof of Concept

Einrichtung: evilsub/ : ein Git-Repository, dessen ROOT eine ausführbare Datei namens post-checkout enthält (die Payload) victim/ : ein Git-Repository mit mindestens einem Commit und einer zweiten Branch, dessen .git/hooks KEINE Beispiel-Hooks enthält (der Zustand eines minimalen/CI-Checkouts, oder git init mit einem leeren Template-Verzeichnis, oder GIT_TEMPLATE_DIR/init.templateDir leer)

import git, os.path as osp try: git.Repo("victim").create_submodule(name="x", path=".git/hooks", url=osp.abspath("evilsub")) except ValueError: pass # 3.2.0+: ".git" wird abgelehnt, aber nur NACH dem Klonen, sodass die Pflanzung bereits stattgefunden hat. # 3.1.x: es wird keine Ausnahme ausgelöst; der Aufruf schlägt fehl und pflanzt dennoch den Hook.

victim/.git/hooks/post-checkout existiert jetzt, Modus 0755, angreiferkontrolliert, in jeder

betroffenen Version. Jeder spätere Checkout führt ihn aus:

git -C victim checkout -> der Hook wird ausgeführt -> Code-Ausführung

Live verifiziert:

• tip bda18e08 (3.2.0 + 3 Commits): create_submodule löste ValueError aus von git/index/base.py:732, doch .git/hooks/post-checkout war vorhanden und ausführbar, und git checkout führte es aus.
• 3.1.59: create_submodule kehrte ohne Fehler zurück; .git/hooks/post-checkout wurde eingepflanzt und von git checkout ausgeführt.

Auswirkungen

Beliebige Code-Ausführung. Eine Bibliothek/App, die ein Submodul aus einem angreiferbeeinflussten path erstellt, endet mit einer angreiferkontrollierten ausführbaren Datei in .git/hooks, die Git bei normalen späteren Operationen ausführt. Dies betrifft jeden Dienst, der einen Submodul-Checkout-Pfad aus nicht vertrauenswürdigen Daten ableitet, z. B. einen, der ein Submodul-Spezifikation (name/path/url) aus einer von einem Benutzer bereitgestellten Manifest- oder API-Anfrage aufnimmt und path in create_submodule einfügt. Ab Version 3.2.0+ ist die Validierung der Bibliothek selbst das, was fehlschlägt: Sie lehnt den .git-Pfad korrekt ab, aber nur nachdem das Submodul bereits geklont wurde, sodass eine App, die den ValueError abfängt, vernünftigerweise glaubt, dass der unsichere Pfad blockiert wurde.

Voraussetzungen (daher AC:H): (1) die App gibt einen angreiferbeeinflussten Submodul path weiter; (2) der Ziel-Hook-Name ist in .git/hooks frei, was für minimale/CI/Container-Checkouts und immer dann zutrifft, wenn init.templateDir/GIT_TEMPLATE_DIR leer ist. Mit den Standard-Beispiel-Hooks vorhanden, lehnt git clone das nicht leere Ziel ab und keine Pflanzung erfolgt.

Betroffen: alle getesteten Versionen von 3.1.x (3.1.59) bis zum aktuellen tip bda18e08 (3.2.0 + 3 Commits). 3.1.x pflanzt stillschweigend; 3.2.0+ pflanzt trotz Auslösen von ValueError.