Ing. Calogero Bono
Le projet Git a publié la version 2.56.1 pour corriger six vulnérabilités de sécurité. L'une d'elles permet d'exécuter du code d'un tiers lorsqu'on clone de façon récursive un dépôt malveillant. Les autres concernent des écritures dans des fichiers non prévus et des dommages à la mémoire pendant les fusions et les patchs binaires. C'est important parce que Git est intégré dans les éditeurs, les outils d'automatisation et les serveurs de beaucoup d'entreprises, et il doit être mis à jour partout.
Quelques termes avant d'entrer dans les faits. Clone récursif est la copie d'un dépôt avec ses sous-modules. Un sous-module est un dépôt placé à l'intérieur d'un autre dépôt. Les hooks sont des programmes que Git lance à des moments précis. Le path traversal utilise des chemins contenant des composants spéciaux pour sortir du dossier autorisé. Le CVE est le code qui identifie publiquement une vulnérabilité.
Qu'a publié le projet Git ?
Selon le blog de GitHub, les corrections se trouvent dans la version 2.56.1. Il existe aussi des backports pour les séries 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 et 2.50.2.
GitHub conseille de passer à la 2.56.1 ou à la version corrigée de ta série, et de mettre à jour aussi les applications qui embarquent une copie de Git. Ceux qui ont lu notre parcours sur Git pour les développeurs savent à quel point cet outil est répandu dans le travail quotidien.
Comment arrive-t-on à exécuter du code avec un clone récursif ?
Le défaut est répertorié sous le nom CVE-2026-111760. C'est une troncature d'entier dans la gestion de l'index. Un chemin très long passe le contrôle de Git, mais il est ensuite écrit sur le disque sous un nom plus court, que l'attaquant peut faire devenir .git.
On remplace ainsi le fichier .git d'un sous-module par un lien symbolique vers un dossier contenant des hooks ou des configurations hostiles. Comme l'explique The Hacker News, Git refuse de remplacer un dossier .git par un lien symbolique, mais dans un sous-module fraîchement cloné, .git est un fichier. Quand Git utilise ce dossier, le code de l'attaquant peut démarrer.
La correction rejette les chemins trop longs avant que leur longueur ne soit tronquée.
Quelles sont les cinq autres vulnérabilités ?
- CVE-2026-113408. En clonant un dépôt vide avec le protocole v2, un serveur malveillant peut indiquer un nom avec path traversal. Avec le backend de références sur fichiers, une mise à jour ultérieure peut écrire en dehors du dossier prévu.
- CVE-2026-114467. Un tag portant plus de deux signatures GPG, si on le fusionne, corrompt la pile et peut provoquer un blocage du service.
- CVE-2026-114469. Un patch binaire petit mais qui se dilate beaucoup contourne la limite d'environ 1 GiB et fait planter Git.
- CVE-2026-105437. Une fusion très volumineuse, avec beaucoup de conflits et un attribut conflict-marker-size élevé, corrompt la mémoire tas.
- CVE-2026-114466. Trois fonctions de fast-import peuvent lire des fichiers arbitraires ou en créer et y ajouter des données.
Pour ce dernier cas, Git refuse désormais ces fonctions dans les flux entrants, sauf avec l'option --allow-unsafe-features, à n'utiliser que si tu fais confiance au programme qui génère le flux.
Qui risque le plus, et qu'a déjà mis à jour GitHub ?
Les serveurs qui effectuent des fusions pour le compte des utilisateurs sont les plus exposés. GitLab, qui a attribué CVE-2026-105437, indique git merge-tree comme cible probable, car un serveur peut l'utiliser pour vérifier qu'une merge request est fusionnable. L'attribut se définit dans un fichier .gitattributes du dépôt, donc quiconque peut ouvrir une demande pourrait déclencher le défaut.
GitHub affirme avoir corrigé github.com et GitHub Enterprise Cloud. Pour Enterprise Server, il faut les versions 3.19.15, 3.20.11, 3.21.9 ou 3.22.4. GitHub Desktop, l'application Copilot, Codespaces et Actions recevront un Git corrigé.
Limites à connaître
Les sources ne signalent aucune exploitation active ni de niveau de gravité pour chaque CVE. Nous ne savons pas si quelqu'un a déjà exploité ces failles. Selon The Hacker News, mardi à 19h09 UTC, Git for Windows ne disposait pas encore d'une version basée sur la 2.56.1, donc les délais peuvent varier pour cette plateforme. Les délais pour GitHub Desktop, Copilot, Codespaces et Actions manquent aussi.
Ce qui change pour ceux qui travaillent avec le numérique
La première étape est de recenser les endroits où tourne Git. Pas seulement sur ton ordinateur, mais aussi dans les programmes qui en embarquent une copie, dans les systèmes d'intégration continue et dans les services qui traitent les dépôts d'autrui. Ceux qui gèrent des serveurs avec des dépôts de tiers doivent aussi mettre à jour les automatisations. Si tu ne peux pas le faire tout de suite, le contournement proposé par GitLab consiste à ajouter conflict-marker-size=7 au fichier info/attributes de chaque dépôt, ou à désactiver ces contrôles pour les dépôts non fiables. Si tu t'appuies sur un hébergement avec mises à jour de sécurité gérées, une partie de ce travail est déléguée.
Notre avis
Les vulnérabilités sont six, mais le message est unique. Git doit être traité comme un logiciel qui traite des entrées non fiables, et non comme un simple outil local. Nous clonons, fusionnons et appliquons des patchs venant de sources externes sans y penser, et les automatisations le font à notre place. Le risque le plus concret vient des copies de Git cachées dans d'autres programmes, que personne ne met à jour tant qu'on ne s'en souvient pas. Les précautions listées par GitHub sont utiles en attendant, mais ce ne sont que des palliatifs. À propos d'outils qui utilisent Git intensivement, nous avons écrit sur GitHub Rubicon, où la question des entrées non fiables pèse encore plus.
Questions fréquentes
Quelle version de Git dois-je installer ?
Installe la 2.56.1 ou la version corrigée de ta série, c'est-à-dire la 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 ou 2.50.2. Mets aussi à jour les applications qui embarquent leur propre copie de Git.
Suffit-il de ne pas cloner des dépôts inconnus ?
Cela aide, mais ce n'est pas suffisant. GitHub recommande de cloner uniquement depuis des serveurs de confiance et d'éviter les clones récursifs, les fusions et les patchs binaires venant de sources non fiables, en précisant que ces précautions ne remplacent pas les mises à jour.
Quelle est la vulnérabilité la plus grave ?
Les sources ne donnent pas de classement. Celle qui permet d'exécuter du code pendant un clone récursif est CVE-2026-111760, et c'est elle qui retient le plus l'attention.
Git for Windows est-il déjà à jour ?
Pas encore, selon le dernier contrôle de The Hacker News. Mardi à 19h09 UTC, aucune version basée sur la 2.56.1 ne figurait parmi les étiquettes de publication.
Les utilisateurs de GitHub doivent-ils faire quelque chose ?
Cela dépend. GitHub a déjà corrigé github.com et les versions Enterprise Cloud. Ceux qui utilisent Enterprise Server doivent passer à l'une des versions indiquées, et ceux qui utilisent des outils locaux doivent mettre Git à jour.
Les mises à jour de Git à suivre dans les prochains jours
Le correctif existe, mais sa distribution est morcelée. Il vaut mieux suivre ceux qui doivent encore publier leur version.
- Vérifie quand Git for Windows publie une build basée sur la 2.56.1 et mets à jour immédiatement.
- Surveille l'arrivée des versions corrigées de GitHub Desktop, de l'application Copilot, de Codespaces et d'Actions.
- Si tu gères un serveur de code hébergé, envisage le contournement de GitLab tant que tu ne peux pas mettre à jour.
