Git corrige une faille critique d'exécution de code dans les clones récursifs

Le projet Git a publié des correctifs d'urgence pour combler une vulnérabilité critique permettant aux attaquants d'exécuter du code arbitraire sur la machine d'un développeur. Cette faille, identifiée sous le nom de CVE-2026-111760, est déclenchée lorsqu'un utilisateur clone récursivement un dépôt contenant des sous-modules malveillants. Les correctifs ont été publiés cette semaine sur plusieurs versions supportées, nécessitant une attention immédiate de la part des équipes d'ingénierie qui utilisent Git pour le contrôle de version.

Ce qui s'est passé

Le problème fondamental réside dans la manière dont Git gère les chemins de fichiers au sein de son index. Un attaquant peut concevoir un dépôt avec un chemin extrêmement long qui passe les vérifications de sécurité initiales mais subit une troncature d'entier lors de l'écriture sur le disque. Cette troncature raccourcit le nom du chemin, permettant à l'attaquant de manipuler le nom de fichier final pour qu'il corresponde à .git. Dans un sous-module fraîchement cloné, .git existe en tant que fichier plutôt que comme répertoire. L'attaquant remplace ce fichier par un lien symbolique pointant vers un dossier contenant des hooks ou des fichiers de configuration malveillants. Puisque Git exécute des hooks à des points spécifiques de son flux de travail, le lien vers ce dossier contrôlé permet l'exécution de code à distance.

Le projet Git a traité ce problème dans la version 2.56.1 et a rétroporté les correctifs aux séries 2.50 à 2.55, spécifiquement les versions 2.50.2, 2.51.3, 2.52.1, 2.53.1, 2.54.1 et 2.55.1. GitHub a confirmé avoir appliqué ces correctifs à github.com et GitHub Enterprise Cloud. Pour les instances auto-hébergées, les versions de GitHub Enterprise Server 3.19.15, 3.20.11, 3.21.9 et 3.22.4 incluent le correctif. Des mises à jour pour GitHub Desktop, GitHub Copilot, Codespaces et Actions sont en préparation. Cependant, mardi à 19:09 UTC, Git for Windows n'avait pas encore publié de version basée sur la branche corrigée 2.56.1.

Comment cela fonctionne

Cette vulnérabilité exploite une divergence entre la validation interne des chemins de Git et la gestion des noms longs par le système de fichiers. Lorsque Git traite l'index, il vérifie la longueur du chemin. Si le chemin est excessivement long, une erreur de troncature d'entier se produit, amenant Git à écrire le fichier sous un nom plus court et prévisible. En construisant soigneusement le chemin, un attaquant s'assure que ce nom raccourci se résout en .git au sein d'un répertoire de sous-module.

Les sous-modules sont particulièrement vulnérables car leur entrée .git est initialement un fichier contenant une référence au répertoire git réel, et non le répertoire lui-même. Git empêche généralement le remplacement d'un répertoire .git par un lien symbolique, mais ne bloque pas le remplacement du fichier .git. Une fois le lien symbolique en place, toute opération Git ultérieure déclenchant des hooks exécutera des scripts depuis l'emplacement contrôlé par l'attaquant. Les versions corrigées rejettent désormais ces chemins extrêmement longs avant que la troncature ne puisse se produire, empêchant ainsi entièrement la collision de noms.

Détails clés

• Vulnérabilité principale : CVE-2026-111760 implique une troncature d'entier dans la gestion de l'index de Git, permettant l'exécution de code via des sous-modules malveillants.
• Versions corrigées : Git 2.56.1, ainsi que 2.50.2, 2.51.3, 2.52.1, 2.53.1, 2.54.1 et 2.55.1.
• Correctifs GitHub Enterprise : Disponibles dans les versions serveur 3.19.15, 3.20.11, 3.21.9 et 3.22.4.
• Autres failles : Cinq autres CVE ont été corrigées, notamment une traversée de chemin dans les dépôts vides (CVE-2026-113408) et une corruption de tas via de grosses fusions (CVE-2026-105437).
• Statut Windows : Git for Windows n'avait pas publié de version corrigée basée sur 2.56.1 au moment du rapport.
• Solutions de contournement : Évitez les clones récursifs de dépôts non fiables et ne traitez pas les patches binaires provenant de sources inconnues jusqu'à la mise à jour.

Pourquoi c'est important

Pour les ingénieurs logiciels et les responsables techniques, cette vulnérabilité met en lumière les risques inhérents aux dépendances de la chaîne d'approvisionnement. Le clonage récursif est une pratique courante dans les monorepos et les projets comportant de nombreux sous-modules. Si un seul sous-module est compromis ou si un développeur clone un fork malveillant, l'environnement de développement entier pourrait être compromis. Il ne s'agit pas seulement d'un risque théorique ; les pipelines CI/CD automatisés clonent souvent les dépôts récursivement, exposant potentiellement les serveurs de build à la même exploitation.

La présence de cinq vulnérabilités supplémentaires dans la même publication souligne la complexité du maintien de systèmes de contrôle de version sécurisés. Des problèmes tels que la corruption de tas due aux grosses fusions ou la traversée de chemin dans le protocole v2 affectent aussi bien les services d'hébergement que les clients locaux. Les équipes gérant des instances privées GitLab ou GitHub Enterprise doivent prioriser ces mises à jour, car les serveurs exécutant git merge-tree pour valider les pull requests sont spécifiquement ciblés par CVE-2026-105437. Retarder les correctifs laisse l'infrastructure ouverte aux attaques par déni de service et aux exfiltrations potentielles de données.

Ce que vous pouvez faire

• Mettez à niveau votre installation Git locale vers l'une des versions corrigées immédiatement, en vérifiant le gestionnaire de paquets de votre OS ou votre distributeur Git.
• Si vous gérez GitHub Enterprise Server, effectuez la mise à niveau vers la version 3.19.15, 3.20.11, 3.21.9 ou 3.22.4.
• Évitez d'utiliser git clone --recursive sur des dépôts provenant de sources non fiables tant que tous les systèmes ne sont pas patchés.
• Configurez vos pipelines CI/CD pour sauter l'initialisation récursive des sous-modules pour les dépendances externes ou non vérifiées.
• Pour les serveurs GitLab incapables de mettre à niveau immédiatement, définissez conflict-marker-size=7 dans le fichier info/attributes du dépôt pour atténuer CVE-2026-105437.
• Surveillez les tags de release pour Git for Windows et mettez à jour dès qu'une version basée sur 2.56.1 devient disponible.