Git 2.56.1 corrige six vulnérabilités, et vos runners CI en ont plus besoin que votre portable

Le 10 novembre, le projet Git a publié Git 2.56.1, ainsi que des versions corrigées pour les anciennes branches de maintenance : 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 et 2.50.2. Ensemble, elles referment six CVE : CVE-2026-111760, CVE-2026-113408, CVE-2026-114467, CVE-2026-114469, CVE-2026-105437 et CVE-2026-114466. Le projet parle de versions de correctifs de sécurité coordonnées et demande de mettre à jour dès que possible. Les bugs ont été découverts par Luke Martin et pwn2addr.

Celle qui compte, c'est CVE-2026-111760, classée High avec un score CVSS de 8,0 dans l'avis de sécurité du projet. En résumé : le code de l'index de Git contient un bug de troncature d'entier. Un chemin très long est vérifié sous son nom complet, puis écrit sur le disque sous un nom plus court. Un attaquant peut exploiter ce décalage pour remplacer le fichier .git d'un sous-module par un lien symbolique pointant vers un répertoire qu'il contrôle, rempli de sa propre configuration ou de ses propres hooks. Or les hooks, c'est du code. Un clone récursif du mauvais dépôt peut donc se terminer par l'exécution du code de quelqu'un d'autre sur votre machine. Selon l'avis, la faille ne serait exploitable que lorsque l'on passe --recurse-submodules.

GitHub a déjà corrigé github.com, GitHub Enterprise Cloud et Enterprise Cloud avec résidence des données. Si vous hébergez vous-même GitHub Enterprise Server, les versions corrigées sont 3.19.15, 3.20.11, 3.21.9 et 3.22.4.

Le score sous-estime le risque pour la plupart des équipes

Si vous lisez le vecteur CVSS, vous pourriez vous détendre un peu. Complexité d'attaque élevée, privilèges faibles, interaction de l'utilisateur requise. Sur un portable de développeur, c'est justifié : quelqu'un doit cloner récursivement un dépôt hostile.

Mais demandez-vous qui exécute réellement git clone dans votre organisation. Le plus souvent, ce ne sont pas des personnes. Ce sont les runners CI, des centaines de fois par jour, sans personne pour surveiller, avec des clés de déploiement et des identifiants cloud dans les variables d'environnement. « Interaction de l'utilisateur requise » ne veut pas dire grand-chose quand l'utilisateur est un fichier YAML.

Quand nous développons des applications cloud-native pour des clients d'entreprise, le Git qui compte est rarement celui d'un portable. C'est celui qui est intégré dans une image Docker de base choisie il y a un an et demi, celui d'un runner auto-hébergé, celui d'un conteneur de déploiement. Mettre à jour les paquets de votre Mac ne touche aucun de ces éléments. D'après notre expérience en PHP et Docker, nous pensons honnêtement que la plupart des équipes ont trois ou quatre versions de Git différentes sur leurs chaînes de build et de déploiement, et qu'elles seraient incapables de les lister sans aller vérifier.

Les équipes mobiles ont leur propre variante du problème. Dans nos projets iOS et Android natifs, les sous-modules restent un moyen courant d'intégrer des SDK partagés, des bibliothèques natives embarquées ou un kit d'UI interne. Les machines de build sont souvent des Mac de longue date que personne n'a réinstallés depuis une éternité. Et le projet Git précise de mettre à jour toute application qui embarque sa propre copie de Git, ce qui concerne pas mal d'IDE et de clients de bureau. Mettre à jour le Git du système ne les corrige pas.

Côté sécurité, cela correspond à un schéma que nous rencontrons sans cesse. Lors de nos tests d'intrusion, le pipeline de build est régulièrement la porte d'entrée la plus facile, parce qu'il fait confiance à des choses qu'on ne laisserait jamais approcher la production : le fork d'un prestataire, le projet d'exemple d'un fournisseur, une dépendance open source intégrée comme sous-module. On oublie que les hooks sont exécutables. Les attaquants, non.

Je l'avoue, mes sentiments sont mitigés. Six CVE d'un coup, dans un outil aussi ancien et aussi fiable, c'est un peu inquiétant. En même temps, des correctifs coordonnés sur sept branches de versions, c'est exactement la maintenance sobre et compétente que l'on attend d'un projet dont tout le monde dépend. Le correctif existe. Le plus dur reste de notre côté : retrouver chaque copie.

Ce que je ferais cette semaine

1. Inventoriez chaque binaire Git, pas seulement ceux des portables. Lancez git --version dans vos images CI, Dockerfiles, runners auto-hébergés et Mac de build. Vous visez la 2.56.1, ou la version corrigée de votre série (2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 ou 2.50.2).
2. Reconstruisez volontairement vos images de base. Ne partez pas du principe que la prochaine reconstruction planifiée récupérera un Git corrigé. Vérifiez la version dans l'image construite.
3. Si vous auto-hébergez GitHub Enterprise Server, passez en 3.19.15, 3.20.11, 3.21.9 ou 3.22.4.
4. Cherchez dans la configuration de vos pipelines les checkouts récursifs de sous-modules. Lorsque le dépôt parent ou un sous-module n'est pas entièrement sous votre contrôle, désactivez la récursion tant que le runner n'est pas corrigé.
5. Tant que tout n'est pas à jour, suivez les consignes provisoires du projet : ne clonez que depuis des serveurs de confiance, évitez les clones récursifs de tout ce qui n'est pas fiable, et soyez prudent en fusionnant du contenu ou des tags externes, en appliquant des patchs binaires ou en alimentant fast-import avec des flux provenant de sources que vous ne maîtrisez pas.

Pour nos clients suisses soumis à des exigences de conformité, j'ajouterais une sixième étape : consignez par écrit ce que vous avez patché et quand. Les auditeurs aiment les preuves, et pour un correctif aussi répandu, mieux vaut les avoir sous la main que les reconstituer plus tard. Cette hygiène de pipeline fait partie de ce que nous couvrons quand nous mettons en place l'infrastructure de build et de déploiement, et elle revient constamment dans nos audits de sécurité.

Si vous ne savez pas combien de copies de Git se cachent dans votre pipeline de build, parlons-en.