Git 2.56.1 bloque un dépôt qui exécutait du code pendant un clone récursif

Le 10 novembre 2026, le projet Git a publié des versions qui corrigent six failles, dont CVE-2026-111760 : un dépôt conçu pour cela peut exécuter du code sur la machine qui le clone de façon récursive, avec ses sous-modules.

L’annonce est sur le blog de GitHub, horodatée le 10 novembre 2026 à 18 h UTC. Les correctifs sont dans Git 2.56.1, et en rétroportage dans Git 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 et 2.50.2. GitHub demande d’installer la version corrigée de sa série de maintenance, et de mettre à jour les applications qui embarquent leur propre copie de Git.

Un chemin trop long, puis un nom plus court

Git vérifie les chemins avant d’écrire dans l’arbre de travail, et refuse ceux qui écraseraient ses propres métadonnées. Une troncature d’entier dans la gestion de l’index fait qu’un chemin extrêmement long passe le contrôle sous un nom, puis est écrit sous un nom plus court.

L’écart permet de remplacer le fichier .git d’un sous-module par un lien vers un dossier qui contient une configuration ou des crochets malveillants. Les crochets sont des programmes que Git lance à des moments prévus. Quand Git utilise ensuite ce dossier, le code de l’attaquant peut partir pendant le clone récursif. Les versions corrigées refusent ces chemins avant que leur longueur puisse être tronquée. La mise à jour ajoute aussi des contrôles de dépassement sur des allocations voisines, au checkout et au traitement des arbres.

Cinq autres failles dans la même livraison

CVE-2026-113408 : lors du clone d’un dépôt vide avec le protocole Git version 2, un serveur peut annoncer une référence HEAD vers une branche qui n’a pas encore de commit. Git ne validait pas la cible. Un nom contenant une traversée de chemin peut, avec le moteur de références « files », faire écrire une mise à jour ultérieure hors du dossier prévu. Git valide désormais la cible annoncée, ainsi que d’autres noms de références reçus par ce protocole.

CVE-2026-114467 : en retirant des signatures GPG, Git supposait qu’il y en aurait au plus deux. Un message qui en contient davantage écrit au-delà d’un tableau de taille fixe. Fusionner une étiquette dans ce cas corrompt la mémoire et peut provoquer un déni de service, y compris chez un hébergeur qui fusionne pour le compte des utilisateurs.

CVE-2026-114469 : Git refuse les correctifs d’environ plus de 1 Gio, mais ne mesurait que la taille fournie. Un correctif binaire compressé peut se déployer au-delà et provoquer une lecture hors limites. Git contrôle maintenant la taille décompressée annoncée.

CVE-2026-105437 : le calcul de la mémoire nécessaire à une fusion peut déborder quand le résultat est très grand, par exemple avec beaucoup de conflits et un attribut conflict-marker-size élevé. Git alloue alors un tampon trop petit et écrit au-delà. Le correctif refuse les fusions dont la taille de sortie ne peut pas être représentée.

CVE-2026-114466 : trois fonctions de git fast-import, rewrite-submodules-from, rewrite-submodules-to et export-pack-edges, pouvaient lire des fichiers arbitraires ou en créer et y ajouter des données. Elles sont refusées dans un flux d’entrée, sauf si l’appelant passe explicitement l’option qui autorise les fonctions dangereuses. GitHub dit de ne l’activer que si l’on fait confiance au programme qui produit le flux.

Où le correctif est déjà en place

GitHub a déployé les correctifs sur github.com, GitHub Enterprise Cloud et GitHub Enterprise Cloud avec résidence des données. Pour GitHub Enterprise Server, les versions corrigées sont 3.19.15, 3.20.11, 3.21.9 et 3.22.4. Des versions de GitHub Desktop et de l’application GitHub Copilot sont en préparation. GitHub Codespaces et GitHub Actions recevront aussi un Git corrigé.

En attendant l’installation, GitHub conseille de ne cloner que depuis des serveurs de confiance, d’éviter les clones récursifs de dépôts non fiables, et de ne pas fusionner de contenu ou d’étiquettes non fiables, ni traiter de correctifs binaires ou de flux fast-import dont on ne connaît pas l’origine. Ces précautions ne remplacent pas la mise à jour. Les administrateurs doivent aussi mettre à jour les Git utilisés par les automates qui traitent des dépôts pour d’autres.

Sources

Annonce des vulnérabilités Git, blog GitHub, 10 novembre 2026, 18 h UTC.