Six vulnérabilités Git : mettez à jour au-delà de la ligne de commande

Si vous avez mis à jour Git dans le terminal, le travail n’est pas terminé : certaines applications et certains environnements de compilation peuvent exécuter leur propre copie. Le 10 novembre 2026, le projet Git a publié des correctifs pour six vulnérabilités, allant de l’exécution de code lors d’un clonage récursif à la corruption de mémoire pendant une fusion. Il faut donc vérifier chaque environnement qui traite des dépôts ou leur contenu, et pas seulement le résultat de la commande git --version dans votre shell.

Ce qui a changé dans la mise à jour

Les correctifs ont été intégrés à Git 2.56.1 et rétroportés dans les branches prises en charge : 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 et 2.50.2. La mise à jour résout six problèmes dans différentes parties de Git, notamment dans le traitement des chemins, des liens, des signatures, des correctifs binaires, des fusions et des flux d’importation. GitHub a publié le 10 novembre une analyse des vulnérabilités et une recommandation de mise à jour ; les notes de version de Git 2.56.1 répertorient les CVE corrigées dans cette série.

En pratique, il faut mettre à jour Git à trois endroits : sur les postes de travail, dans les systèmes d’automatisation et au sein des applications qui embarquent leur propre version de Git. C’est ce dernier cas qu’il est facile d’oublier : la mise à jour du paquet système ne modifie pas automatiquement la version de chaque client ou image de compilation.

Pourquoi le clonage récursif mérite une attention particulière

Le scénario le plus parlant commence par le clonage récursif d’un dépôt non fiable. En raison de la troncature de la longueur des chemins, un chemin très long pouvait passer la vérification sous un nom, puis être enregistré sur le disque sous une forme raccourcie. Dans le scénario décrit pour Git, cela permettait de remplacer le fichier .git d’un sous-module par un lien symbolique pointant vers un répertoire contenant une configuration ou des hooks malveillants. Lors d’une utilisation ultérieure, Git pouvait exécuter le code défini par l’attaquant.

À retenir : ce scénario nécessite un dépôt spécialement préparé et une opération correspondante. Les équipes qui clonent régulièrement des projets provenant de sources externes avec l’option --recurse-submodules devraient donner la priorité à la mise à jour de leurs clients et environnements automatisés. Le correctif rejette les chemins excessivement longs avant que leur longueur soit tronquée.

Autres points où Git traite des données non fiables

Un autre problème apparaît lors du clonage d’un dépôt vide via le protocole Git v2. Le serveur pouvait transmettre une référence HEAD dont le nom de branche contenait des composants de traversée de répertoires ; par la suite, une opération de mise à jour de branche pouvait écrire un fichier en dehors du répertoire de références prévu. Dans les versions corrigées, Git vérifie cette cible ainsi que les autres noms de références reçus via le protocole.

Des vulnérabilités distinctes concernaient les opérations de fusion et les correctifs. Lors du traitement des signatures, un tableau de taille fixe ne prévoyait que deux signatures ; un message spécialement conçu comportant davantage de signatures pouvait provoquer une écriture hors des limites du tableau et corrompre la mémoire. Lors de l’application d’un correctif binaire, la vérification de la taille tenait compte de la représentation d’origine, alors que les données compressées peuvent se décompresser en un volume bien plus important. Git vérifie désormais la taille décompressée déclarée avant le traitement.

De grandes fusions pouvaient également provoquer un dépassement de capacité lors du calcul de la taille du tampon nécessaire, puis une écriture hors limites. Cela concerne notamment les plateformes d’hébergement et les applications qui fusionnent du contenu non fiable. Enfin, trois fonctionnalités de git fast-import ont été restreintes pour les commandes issues du flux d’entrée : rewrite-submodules-from et rewrite-submodules-to pouvaient lire des fichiers arbitraires, tandis que export-pack-edges pouvait créer des fichiers ou ajouter des données à des fichiers existants. Ces fonctionnalités sont désormais bloquées, sauf si l’option --allow-unsafe-features est explicitement indiquée ; elle ne doit être utilisée qu’avec un générateur de flux digne de confiance.

Où chercher les copies distinctes de Git

Pour les développeurs, un bon point de départ consiste à recenser les sources qui lancent Git. Vérifiez la version dans le terminal et utilisez la fonction de mise à jour intégrée des IDE et des clients Git de bureau. Vérifiez ensuite les images CI, les conteneurs, les runners et les tâches serveur qui exécutent des commandes de clonage ou de fusion, appliquent des correctifs binaires ou lancent fast-import. La présence d’une version récente de Git sur l’hôte ne garantit pas que l’application l’utilise.

Dans les organisations, il est utile de vérifier non seulement les images sources, mais aussi les environnements déjà déployés : un runner persistant ou un service interne peut avoir conservé un ancien binaire après la mise à jour de l’image de base. Pour GitHub Enterprise Server, GitHub indique que les versions corrigées sont 3.19.15, 3.20.11, 3.21.9 et 3.22.4. L’entreprise a indiqué avoir déjà déployé les correctifs sur github.com et GitHub Enterprise Cloud, y compris les offres avec résidence des données. Les versions de GitHub Desktop et de l’application GitHub Copilot intégrant le Git corrigé sont en cours de coordination ; les versions corrigées pour Codespaces et GitHub Actions doivent également être publiées.

Comment réduire le risque avant la mise à jour

Si vous ne pouvez pas installer immédiatement le correctif, limitez temporairement les opérations sur des données non fiables : clonez uniquement des dépôts provenant de serveurs de confiance, évitez le clonage récursif de projets non vérifiés, ne fusionnez pas leur contenu et n’appliquez pas les correctifs binaires ou les flux fast-import qu’ils fournissent. Ces mesures réduisent l’exposition aux scénarios vulnérables concernés, mais ne remplacent pas la mise à jour.

La conclusion pratique est simple : il faut chercher les correctifs Git là où le programme exécute réellement Git. La commande du terminal n’est qu’un de ces points ; les clients de développement, les environnements CI et les services qui traitent des dépôts doivent être vérifiés séparément.