En bref. Le 10 novembre 2026, le projet Git a publié des versions corrigeant six vulnérabilités. La plus grave, CVE-2026-111760 (score CVSS 8,0), permet à un dépôt malveillant d'exécuter du code sur la machine qui le clone avec ses sous-modules (git clone --recurse-submodules). Mettez à jour vers Git 2.56.1 ou la version corrigée de votre branche de maintenance, sans oublier les copies de Git embarquées dans vos outils et vos runners de CI. En attendant, ne clonez pas récursivement un dépôt dont vous ne connaissez pas la source.
Ce qui s'est passé
GitHub a publié le 10 novembre 2026 un billet d'Elijah Newren, ingénieur chez GitHub et contributeur de Git, qui détaille six vulnérabilités corrigées dans Git :
- CVE-2026-111760 : exécution de code lors d'un clone récursif ;
- CVE-2026-113408 : traversée de chemin via la branche HEAD annoncée par un serveur ;
- CVE-2026-114467 : corruption de pile lors de la suppression de signatures ;
- CVE-2026-114469 : lectures hors limites lors de l'application de patchs binaires ;
- CVE-2026-105437 : corruption du tas lors de fusions volumineuses ;
- CVE-2026-114466 : accès au système de fichiers via les flux
fast-import.
Les correctifs sont dans Git 2.56.1, avec des rétroportages dans 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 et 2.50.2.
L'avis de sécurité du projet Git (GHSA-vp2w-7xxj-jvxr) classe CVE-2026-111760 en sévérité élevée, avec un score CVSS 3.1 de 8,0 (vecteur AV:N/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:H). Le CVSS (Common Vulnerability Scoring System) note la gravité d'une faille de 0 à 10. Ici, le vecteur indique une attaque à distance, de complexité élevée, qui demande une action de l'utilisateur (le clone), avec un impact fort sur la confidentialité, l'intégrité et la disponibilité.
Comment fonctionne CVE-2026-111760 (principe)
Avant d'écrire des fichiers dans le répertoire de travail, Git vérifie les chemins. Il refuse notamment ceux qui écraseraient ses propres métadonnées, comme le fichier .git d'un sous-module. Ce fichier indique à Git où se trouve le dépôt du sous-module.
Le billet de GitHub décrit le défaut : une troncature d'entier dans la gestion de l'index de Git. Un chemin extrêmement long passe la validation sous un nom, puis il est écrit sur le disque sous un nom plus court, choisi par l'attaquant. Ce décalage permet de remplacer le fichier .git d'un sous-module par un lien symbolique vers un répertoire qui contient une configuration ou des hooks malveillants (les hooks sont des scripts que Git exécute automatiquement à certaines étapes). Quand Git utilise ensuite ce répertoire pendant le clone récursif, il exécute le code de l'attaquant.
L'avis du projet Git précise deux conditions. Le dépôt doit être contrôlé par l'attaquant et hébergé par lui, et non sur une plateforme d'hébergement habituelle. Les mainteneurs estiment par ailleurs que la faille ne se déclenche qu'avec l'option --recurse-submodules.
Le correctif rejette les chemins d'index trop longs avant que leur longueur puisse être tronquée. La version ajoute aussi des contrôles de dépassement sur les allocations liées aux entrées d'index pendant le checkout et le traitement des arbres.
Les cinq autres failles en une ligne chacune
- CVE-2026-113408 : lors du clone d'un dépôt vide en protocole v2, un serveur malveillant peut annoncer une branche dont le nom contient des composants de traversée de chemin. Une opération ultérieure peut alors écrire en dehors du répertoire des références.
- CVE-2026-114467 : Git supposait au plus deux signatures GPG dans un message. Un tag qui en contient plus, fusionné, peut corrompre la mémoire et provoquer un déni de service. Les services d'hébergement qui font ces fusions pour leurs utilisateurs sont aussi concernés.
- CVE-2026-114469 : un patch binaire compressé peut passer la limite de taille d'environ 1 Gio puis dépasser cette limite une fois décompressé, ce qui provoque une lecture hors limites et un plantage.
- CVE-2026-105437 : le calcul de la mémoire nécessaire au résultat d'une fusion peut déborder sur de très grandes fusions, ce qui corrompt le tas. Les applications et services qui fusionnent du contenu non fiable sont visés, ainsi que les fusions locales.
- CVE-2026-114466 : trois fonctions de
git fast-import(rewrite-submodules-from,rewrite-submodules-to,export-pack-edges) pouvaient lire ou écrire des fichiers hors du dépôt. Elles sont désormais refusées dans un flux d'entrée, sauf si l'appelant active explicitement--allow-unsafe-features.
Qui est concerné
Les postes des développeurs. Toute version antérieure aux versions corrigées est concernée. Le risque principal est le clone récursif d'un dépôt dont la source n'est pas maîtrisée : un projet partagé dans un ticket, un exemple de code, un dépôt de démonstration envoyé par un candidat ou un prestataire.
Les runners de CI/CD et l'automatisation. Le billet de GitHub demande aux administrateurs de mettre à jour Git dans l'automatisation et les services qui traitent des dépôts pour le compte d'utilisateurs. Un runner auto-hébergé qui clone des dépôts externes avec leurs sous-modules entre dans ce cas.
Les applications qui embarquent leur propre Git. Un IDE, un client graphique ou un outil d'analyse peut fournir sa propre copie de Git, qui ne suit pas la mise à jour du système. GitHub indique coordonner des versions corrigées de GitHub Desktop et de l'application GitHub Copilot.
Les agents de code. Hypothèse de travail, non traitée par les sources : un agent de développement qui clone des dépôts de façon autonome, à partir d'une URL trouvée dans un ticket ou une page web, reproduit le comportement à risque sans qu'un humain évalue la source. Son environnement d'exécution doit être mis à jour comme un poste de développeur.
Ce que GitHub a déjà corrigé. Les correctifs sont déployés sur github.com, GitHub Enterprise Cloud et GitHub Enterprise Cloud avec résidence des données. Pour GitHub Enterprise Server, les versions corrigées sont 3.19.15, 3.20.11, 3.21.9 et 3.22.4. GitHub Codespaces et GitHub Actions doivent recevoir des versions corrigées de Git.
Comment s'en protéger : méthode en quatre étapes
1. Inventorier les copies de Git. Listez les endroits où Git s'exécute : postes (système et applications qui l'embarquent), images de conteneurs de build, runners auto-hébergés, serveurs qui traitent des dépôts (revue de code, analyse, miroir), environnements d'agents. Sur chaque cible, git --version donne la version effectivement appelée. Pour les applications qui embarquent Git, la version se lit dans leur documentation ou leurs notes de version.
2. Mettre à jour par ordre d'exposition. Commencez par ce qui clone ou fusionne du contenu venu de l'extérieur sans contrôle humain : runners auto-hébergés, services d'analyse, agents. Puis les postes. Puis le reste. La cible est 2.56.1 ou la version corrigée de votre branche (2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3, 2.50.2). Les administrateurs de GitHub Enterprise Server passent à la version corrigée de leur branche.
3. Appliquer les précautions en attendant. GitHub recommande, si la mise à jour ne peut pas être immédiate, de ne cloner que depuis des serveurs de confiance, d'éviter les clones récursifs de dépôts non fiables, et de ne pas fusionner de contenu ou de tags non fiables ni traiter de patchs binaires ou de flux fast-import venant de sources non fiables. Le billet précise que ces précautions ne remplacent pas l'installation des correctifs.
4. Vérifier. Une bonne pratique consiste à ajouter dans la chaîne de build un contrôle qui échoue si la version de Git de l'image est inférieure à la version corrigée de sa branche. Le contrôle reste utile pour les prochaines vulnérabilités. Vérifiez aussi les images de base figées dans vos fichiers de build : une image épinglée sur une ancienne version ne se met pas à jour seule.
Ce que l'épisode dit de la chaîne de développement
Git est un composant que l'on ne voit plus. Il est présent sur chaque poste, dans chaque image de CI, souvent en plusieurs exemplaires. Une vulnérabilité de Git n'est donc pas qu'un sujet de poste de travail : c'est un sujet d'inventaire logiciel. Une organisation qui tient un inventaire de ses composants, y compris des outils de build, peut répondre en quelques minutes à la question « où tourne une version vulnérable ? ». Les autres doivent la reconstituer à chaque avis.
Le clone récursif mérite aussi une règle explicite. Les sous-modules récupèrent du code depuis d'autres dépôts, éventuellement hébergés ailleurs. Une bonne pratique consiste à réserver le clone récursif aux dépôts dont vous connaissez la provenance, et à cloner d'abord sans sous-modules quand la source est inconnue.
FAQ
Quelle version de Git corrige CVE-2026-111760 ?
Git 2.56.1, ainsi que 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 et 2.50.2 pour les branches de maintenance.
Un simple git clone sans option est-il dangereux ?
Selon l'avis du projet Git, les mainteneurs estiment que CVE-2026-111760 ne se déclenche qu'avec --recurse-submodules. Les autres failles ont d'autres conditions (clone d'un dépôt vide depuis un serveur malveillant, fusion de tags, patchs binaires) : la mise à jour reste nécessaire.
Les dépôts hébergés sur GitHub sont-ils un vecteur ?
L'avis décrit un dépôt contrôlé et hébergé par l'attaquant, plutôt que sur une plateforme d'hébergement habituelle. GitHub a par ailleurs déployé les correctifs sur github.com.
Nos runners GitHub Actions hébergés sont-ils corrigés ?
GitHub indique que GitHub Actions et Codespaces recevront des versions corrigées de Git. Les runners auto-hébergés restent à votre charge.
Sources
- GitHub Blog, Git security vulnerabilities announced, Elijah Newren, 10 novembre 2026 : https://github.blog/open-source/git/git-security-vulnerabilities-announced-7/
- Projet Git, avis de sécurité GHSA-vp2w-7xxj-jvxr (CVE-2026-111760), 10 novembre 2026 : https://github.com/git/git/security/advisories/GHSA-vp2w-7xxj-jvxr
Pour inventorier les outils de votre chaîne de build et automatiser ce type de contrôle, WeeSec accompagne les équipes sur le DevSecOps.