Le projet Git a publié le 10 novembre une série de versions de maintenance qui corrigent 6 vulnérabilités d'un coup. La plus grave est CVE-2026-111760 : cloner un dépôt contrôlé par un attaquant avec git clone --recurse-submodules peut exécuter le code de cet attaquant sur votre machine, et l'avis de GitHub lui attribue un score de 8,0 (élevé). Le projet Git précise que toutes les versions depuis la 2.27.0 sont touchées. Les versions corrigées sont 2.50.2, 2.51.3, 2.52.1, 2.53.1, 2.54.1, 2.55.1 et 2.56.1 ; les versions antérieures à 2.50 sont touchées elles aussi, mais ne reçoivent plus de versions de maintenance.

Dans quels cas chacune des six failles se déclenche

  • CVE-2026-111760 : Git stocke la longueur d'un chemin de fichier dans un champ de 32 bits. Un attaquant fabrique un chemin extrêmement long qui passe le contrôle de sécurité des chemins, mais se retrouve tronqué en .git au moment de l'écriture sur le disque. Dans un sous-module fraîchement cloné, .git est un fichier : il est donc remplacé par un lien symbolique vers un répertoire malveillant, dont les hooks ou la configuration sont ensuite exécutés. Le déclencheur est le clonage récursif d'un dépôt contrôlé par un attaquant.
  • CVE-2026-113408 : un serveur malveillant se sert du protocole v2 pour faire pointer HEAD vers un nom contenant ../ ; lorsque vous lancez ensuite git commit, Git écrit dans un fichier situé hors du répertoire des références.
  • CVE-2026-114467 : lorsque le message d'une étiquette (tag) porte plus de deux signatures GPG, git merge corrompt la mémoire de la pile, ce qui peut provoquer un déni de service.
  • CVE-2026-114469 : un correctif binaire (binary patch) dont la taille décompressée dépasse de loin 1 Gio échappe au contrôle de taille ; git apply lit alors hors limites et plante.
  • CVE-2026-105437 : un débordement de tas dans le code de fusion à trois voies, déclenché par un conflict-marker-size énorme dans .gitattributes, combiné à de nombreux conflits ; merge, rebase, cherry-pick et merge-tree exécutent tous ce code.
  • CVE-2026-114466 : plusieurs fonctionnalités de git fast-import permettaient de lire et d'écrire des fichiers arbitraires ; elles sont désormais désactivées par défaut et exigent --allow-unsafe-features si vous vous en servez réellement. Ce changement rompt la compatibilité ascendante.

Pourquoi cela compte sur un serveur

  • Scripts de déploiement et CI : de nombreux scripts clonent récursivement. Le projet Git indique qu'un tel dépôt malveillant échoue aux contrôles des grandes plateformes d'hébergement et ne peut pas facilement y être poussé, mais qu'il peut se trouver sur le propre serveur de l'attaquant ; un .gitmodules d'apparence anodine qui pointe vers lui suffit alors. Autrement dit, le risque vient des sous-modules contenus dans les dépôts tiers dont vous dépendez.
  • Services Git auto-hébergés : un service d'hébergement vérifie côté serveur, pour le compte de ses utilisateurs, si une fusion est possible. L'annonce note que le débordement de tas dans la fusion pourrait être transformé en exécution de code à distance sur GitLab. GitHub indique que github.com est déjà corrigé, et les versions corrigées de GitHub Enterprise Server sont 3.19.15, 3.20.11, 3.21.9 et 3.22.4.
  • Paquets des distributions : au 12 novembre, la 2.39.5 de Debian 12 et la 2.47.3 de Debian 13 sont toujours marquées vulnérables. Ancien ne veut pas dire sûr : d'après la plage indiquée en amont, la 2.34.1 livrée avec Ubuntu 22.04 est touchée elle aussi et doit attendre que la distribution rétroporte les correctifs.

Ce que vous pouvez faire dès maintenant

Vérifiez votre version avec git --version, mettez à jour dès que le paquet corrigé de votre distribution arrive, et mettez à jour les applications qui embarquent leur propre copie de Git. Tant que le correctif n'est pas installé, GitHub conseille de ne cloner que depuis des serveurs de confiance, d'éviter les clonages récursifs de dépôts non fiables, d'éviter de fusionner du contenu ou des étiquettes non fiables, et d'éviter de traiter des correctifs binaires ou des flux fast-import provenant de sources non fiables. GitHub précise aussi que ces précautions ne remplacent pas l'installation des correctifs. Nous avons traité le même type de risque lié à la chaîne d'approvisionnement dans notre article sur le ver npm ; les flux de déploiement classiques qui récupèrent le code avec Git sont décrits dans déployer une application Node.js et dans notre introduction à Docker ; et si vous soupçonnez qu'une machine de déploiement a déjà exécuté du code inconnu, suivez notre guide d'enquête et de re-sécurisation d'un VPS compromis.