Git 2.56.1 corrige six failles, dont une exécution de code lors du clonage récursif d’un dépôt malveillant
Le 10 novembre 2026, le projet Git a publié six correctifs de sécurité, dont une exécution de code arbitraire déclenchée par le clonage récursif d’un dépôt hostile. Passez à Git 2.56.1 et mettez à jour tout ce qui l’embarque — IDE, runners CI, outils de revue — car la faille se déclenche par le simple clonage.
10 novembre 2026. Le projet Git publie six correctifs de sécurité. 2.56.1. C’est la version de tête qui les embarque, avec des backports vers 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 et 2.50.2. Une exécution de code arbitraire. C’est ce que permet la plus sévère des six, CVE-2026-111760, déclenchée par le clonage récursif d’un dépôt hostile. Pourquoi c’est important : Git n’est plus un simple binaire de développeur — il est embarqué dans les IDE, les runners CI et les robots de revue, et la moitié de ces failles se déclenchent sur des opérations de routine.
La faille qui exécute du code : CVE-2026-111760
CVE-2026-111760 est la seule des six à permettre l’exécution de code. Son vecteur est le clonage récursif — l’opération git clone --recursive, qui télécharge un dépôt puis ses sous-modules. Pendant ce processus, Git vérifie les chemins avant d’écrire les fichiers dans l’arbre de travail, et rejette notamment ceux qui écraseraient ses propres métadonnées (le dossier .git).
Le défaut est une troncature d’entier : la longueur d’un chemin d’entrée d’index est stockée dans un type trop étroit, et une valeur suffisamment longue déborde. Un dépôt fabriqué peut ainsi présenter un chemin qui, une fois tronqué, se confond avec un répertoire légitime. Git écrit alors dans un emplacement qu’il croit sûr, puis réutilise ce répertoire — et exécute le code contrôlé par l’attaquant. Le correctif consiste à rejeter les chemins d’entrée d’index excessivement longs avant que leur longueur ne puisse être tronquée.
Le scénario concret tient en une phrase : un développeur ou un pipeline qui clone récursivement un dépôt non fiable — un projet tiers, un correctif reçu, un dépôt de démonstration — peut exécuter du code sans même ouvrir un fichier. C’est un vecteur de supply chain classique, du même ordre que les paquets piégés ou les hooks malveillants, mais qui ne demande aucune interaction au-delà du clonage.
Cinq autres failles : corruption mémoire et traversée de chemin
Les cinq autres failles sont moins spectaculaires, mais deux d’entre elles touchent des opérations que les plateformes d’hébergement exécutent en continu.
CVE-2026-113408 — traversée de chemin via le HEAD annoncé par le serveur. Lors du clonage d’un dépôt vide avec le protocole Git v2, le serveur peut annoncer une référence symbolique HEAD pointant vers une branche non encore née, c’est-à-dire sans commit. Un serveur malveillant peut ainsi faire écrire des références en dehors du répertoire attendu. Git valide désormais la cible annoncée avant de l’accepter, et étend cette validation aux autres noms de référence reçus via le protocole v2.
CVE-2026-114467 — corruption de pile à la suppression des signatures. En retirant les signatures GPG d’un message, Git supposait qu’il n’y en avait au plus deux. Un message forgé contenant plus de deux signatures provoquait un écrasement de pile — un déni de service, mais qui peut aussi toucher les services d’hébergement qui effectuent ces fusions pour le compte de leurs utilisateurs. Le correctif supprime le tableau de taille fixe et gère un nombre arbitraire de signatures.
CVE-2026-114469 — lecture hors limites à l’application de correctifs binaires. Git rejette les correctifs de plus d’environ 1 Gio, car son code ne sait pas les traiter en sécurité. Mais cette vérification ne portait que sur l’entrée compressée, pas sur la taille décompressée déclarée. Un correctif forgé contourne le contrôle et provoque une lecture hors limites qui fait planter Git. Git vérifie désormais aussi la taille décompressée déclarée avant de traiter le correctif.
CVE-2026-105437 — corruption de tas lors de fusions volumineuses. La machinerie de fusion calcule la mémoire nécessaire au résultat avant d’écrire la sortie ; ce calcul peut déborder quand le résultat est très grand. Le correctif utilise des types de taille adaptés et de l’arithmétique vérifiée, et rejette les fusions dont la taille de sortie ne peut être représentée en sécurité.
CVE-2026-114466 — accès au système de fichiers via les flux fast-import. git fast-import lit un flux de commandes pour construire un dépôt ; certaines commandes peuvent accéder à des fichiers hors du dépôt, alors que Git les restreignait déjà partiellement. La restriction est désormais complète.
Ce qui rend ce lot différent : la surface d’embarquement
Le point qui change la gravité réelle de ce lot n’est pas le score CVSS, c’est qui exécute Git. Git n’est plus seulement l’outil que le développeur lance en ligne de commande. Il est embarqué dans :
- les IDE et éditeurs — VS Code et ses dérivés, JetBrains — et leurs fonctions de clonage intégrées ;
- les runners CI et les images de build qui exécutent
git clonesur chaque commit ; - les bots de revue, les scanners de dépendances et les plateformes qui clonent des dépôts pour les analyser ;
- les bibliothèques qui lient Git — libgit2, go-git, dulwich — et qui doivent être recompilées contre les correctifs.
C’est précisément la recommandation de GitHub, par la voix d’Elijah Newren — le mainteneur de merge-ort et l’auteur de git-filter-repo, qui signe l’annonce : mettre à jour non seulement Git, mais aussi toute application qui l’embarque. Un IDE à jour ne protège pas si son Git interne traîne deux versions de retard.
Comment vérifier son exposition en une minute
La vérification est triviale : comparer la version de Git à 2.56.1. Deux commandes suffisent.
git --version
git config --get-regexp 'submodule\..*\.url' | wc -lLa première donne la version du binaire. Si elle est antérieure à 2.56.1 — ou à l’un des backports de votre série de maintenance — vous êtes exposé à CVE-2026-111760. La seconde sert de rappel : si vous utilisez des sous-modules, c’est précisément la surface de la faille la plus grave. Pour les postes gérés, le plus efficace est de laisser le gestionnaire de paquets faire le travail — apt, dnf, brew ou Git for Windows — plutôt que de corriger chaque machine à la main.
Pour les équipes qui embarquent Git dans leurs images, la règle est la même que pour n’importe quelle dépendance : reconstruire les images, ne pas se contenter de patcher le binaire du poste.
Verdict
Si vous clonez des dépôts non fiables — projets tiers, correctifs reçus, forks de démonstration — ou si vos pipelines clonent récursivement des dépôts que vous ne contrôlez pas, mettez à jour vers Git 2.56.1, ou le backport de votre série, avant votre prochaine revue de code, et reconstruisez les images CI qui embarquaient une version antérieure. La faille CVE-2026-111760 transforme un git clone --recursive en exécution de code : un vecteur de supply chain qui ne demande aucune interaction au-delà du clonage. Si votre parc ne clone que des dépôts internes et que tout est déjà à jour, le risque est faible — mais corrigez quand même dans la fenêtre habituelle : les cinq autres failles sont des corruptions mémoire et des traversées de chemin que les plateformes d’hébergement encaissent à votre place.