Git : des dépôts malveillants peuvent exécuter du code lors de clones récursifs (CVE-2026-111760)

Ce qui s'est passé

Le 11 novembre 2026, le projet Git a publié de nouvelles versions qui corrigent six failles de sécurité. La plus grave est CVE-2026-111760. Le clonage récursif d'un dépôt malveillant, c'est-à-dire avec ses sous-modules, peut exécuter le code de l'attaquant sur la machine qui effectue le clonage.

La cause est une troncature d'entier dans la gestion de l'index par Git. Un chemin très long passe le contrôle de sécurité de Git, mais Git l'écrit ensuite sur le disque sous un nom plus court. Un attaquant peut choisir ce nom plus court. Il peut ainsi remplacer le fichier .git d'un sous-module par un lien symbolique vers un répertoire contenant des hooks ou une configuration malveillants. Lorsque Git utilise ensuite ce répertoire, le code de l'attaquant s'exécute. Le correctif fait rejeter par Git ces chemins très longs avant que leur longueur ne soit tronquée.

Les mêmes versions corrigent cinq autres failles :

• CVE-2026-113408 : lorsqu'un dépôt vide est cloné via le protocole Git v2, un serveur malveillant peut envoyer un nom de branche contenant une traversée de chemin. Avec le backend de références de type fichiers, une mise à jour ultérieure de cette branche peut écrire en dehors du répertoire de références de Git.
• CVE-2026-114467 : la fusion d'une étiquette portant plus de deux signatures GPG corrompt la mémoire de la pile et peut provoquer un déni de service. Les services d'hébergement qui exécutent de telles fusions pour leurs utilisateurs peuvent aussi être concernés.
• CVE-2026-114469 : un correctif binaire qui se développe à une taille très importante peut contourner la limite de taille des correctifs de Git, d'environ 1 Gio, et faire planter Git par une lecture hors limites.
• CVE-2026-105437 : une fusion très volumineuse comportant de nombreux conflits et un attribut conflict-marker-size de grande valeur peut faire écrire Git au-delà de la fin d'un tampon sur le tas. GitLab indique que les serveurs d'hébergement de code sont les cibles les plus probables, via git merge-tree, que les serveurs utilisent pour vérifier si une demande de tirage ou de fusion peut être fusionnée.
• CVE-2026-114466 : trois fonctionnalités de git fast-import (rewrite-submodules-from, rewrite-submodules-to et export-pack-edges) peuvent servir à lire des fichiers arbitraires, ou à créer des fichiers et y ajouter des données. Git rejette désormais ces fonctionnalités dans un flux d'entrée, sauf si --allow-unsafe-features est défini.

Aucune des sources ne signale d'attaque à ce jour.

Qui est concerné

Sont concernés tous les systèmes qui utilisent une version de Git antérieure à ces versions corrigées : 2.56.1, 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 et 2.50.2. Sur les serveurs, les points suivants sont les plus importants :

• Serveurs de build, d'intégration continue et de déploiement qui clonent des dépôts récursivement (git clone --recursive, --recurse-submodules ou git submodule update --init), en particulier des dépôts ou sous-modules provenant de tiers. Pour que CVE-2026-111760 fonctionne, le dépôt cloné doit être malveillant. Si vous ne clonez que vos propres dépôts de confiance, le risque est nettement plus faible, mais vous devriez quand même effectuer la mise à jour.
• Serveurs Git auto-hébergés qui exécutent des fusions ou des vérifications de fusion sur du contenu poussé par les utilisateurs (CVE-2026-105437, CVE-2026-114467).
• GitHub Enterprise Server : les correctifs figurent dans les versions 3.19.15, 3.20.11, 3.21.9 et 3.22.4.
• Applications qui embarquent leur propre copie de Git. Elles doivent être mises à jour par leur éditeur.

Non concernés : github.com et GitHub Enterprise Cloud. GitHub a déjà appliqué les correctifs sur ces plateformes. Les serveurs web sur lesquels Git est installé mais qui ne clonent ni ne fusionnent jamais de contenu externe ne sont pas exposés à la faille de clonage en pratique. Mettez-les tout de même à jour lors de votre prochaine maintenance.

Git pour Windows n'avait pas publié de version basée sur Git 2.56.1 au 10 novembre 2026, à 19 h 09 UTC. Les administrateurs Windows doivent surveiller cette publication.

Actions à mener maintenant

1. Vérifiez la version installée sur chaque serveur avec git --version.
2. Installez une version corrigée via le gestionnaire de paquets de votre système d'exploitation (par exemple apt update && apt install --only-upgrade git ou dnf upgrade git). Les distributions intègrent généralement les correctifs dans leurs propres versions de paquets : consultez donc l'avis de sécurité de votre distribution pour identifier le paquet corrigé. Si vous compilez Git vous-même, passez à la version 2.56.1 ou à la version corrigée de votre série.
3. Mettez GitHub Enterprise Server à jour vers 3.19.15, 3.20.11, 3.21.9 ou 3.22.4, selon votre branche de version. Mettez à jour les autres applications qui embarquent leur propre copie de Git dès que leur éditeur publie un correctif.
4. Tant que tous les systèmes ne sont pas mis à jour, suivez les recommandations provisoires de GitHub. Ces mesures ne remplacent pas la mise à jour :
   • Ne clonez que depuis des serveurs de confiance.
   • Ne clonez pas récursivement les dépôts que vous ne connaissez pas.
   • Ne fusionnez pas de contenu ou d'étiquettes dont vous ne connaissez pas l'origine.
   • Ne traitez pas de correctifs binaires ni de flux fast-import provenant de sources non fiables.
5. Sur les serveurs d'hébergement Git qui ne peuvent pas encore être mis à jour, protégez-vous contre CVE-2026-105437. Ajoutez conflict-marker-size=7 au fichier info/attributes de chaque dépôt, ou désactivez les vérifications de fusion pour les dépôts non fiables.
6. Redémarrez les services de longue durée qui appellent Git, comme les runners CI ou les démons d'hébergement Git, afin qu'ils utilisent le nouveau binaire.

Comment vérifier si vous êtes concerné

• Exécutez git --version. Les versions antérieures à la version corrigée de leur série sont concernées : 2.50.2, 2.51.3, 2.52.1, 2.53.1, 2.54.1, 2.55.1 ou 2.56.1. Pour les paquets de distribution, comparez la version du paquet avec l'avis de votre distribution plutôt qu'avec le numéro de version amont.
• Recherchez dans vos scripts de build et de déploiement ainsi que dans vos configurations CI les options --recursive, --recurse-submodules et submodule update. Vérifiez quels dépôts clonés proviennent de tiers.
• Recherchez les copies de Git installées en dehors du gestionnaire de paquets, par exemple avec which -a git. Vérifiez aussi le Git intégré aux runners CI, aux conteneurs et aux autres applications.

Sources

• https://nvd.nist.gov/vuln/detail/CVE-2026-111760
• https://thehackernews.com/2026/11/git-patches-flaw-that-lets-malicious.html