Git corrige CVE-2026-111760 qui permet l'exécution de code en sous-modules pendant le clonage

Cette semaine, le projet Git a publié une correction pour vulnérabilité grave (CVE-2026-111760) qui permet à un dépôt malveillant de provoquer l'exécution de code dans la machine qui le clone récursivement avec ses sous-modules. Le problème a été résolu dans Git 2.56.1, et des correctifs correspondants ont été publiés pour les branches 2.50 à 2.55. Les corrections empêchent les voies de fichiers trop longues de passer par les contrôles de sécurité et sont ensuite coupées lors de l'écriture sur disque avec un nom qu'un attaquant peut forcer à être .git, qui ouvre la porte au remplacement du fichier .git d'un sous-module par un lien symbolique à un emplacement contrôlé par l'attaquant. Une fois là, Git peut lire des crochets ou des fichiers de configuration depuis cet emplacement et exécuter du code arbitraire à des moments contrôlés par le flux normal Git.

Ce qui s'est passé (faits confirmés): le projet Git connaît une défaillance totale de la troncation dans la gestion de l'index qui permet une route extrêmement longue qui devrait être bloquée par les contrôles de sécurité, passer et ensuite il est écrit avec un nom plus court. Cette différence entre la vérification et l'écriture permet au nom résultant d'être exactement ".git". Depuis Git traite un répertoire .git et un fichier .git différemment dans un sous-module nouvellement cloné, un attaquant peut utiliser ce comportement pour laisser un fichier .git qui est en fait un lien symbolique vers un dossier attaquant contenant des crochets ou d'autres fichiers exécutables. Git lance des crochets à des points spécifiques (par exemple après vérification, pré-engagement, etc.), de sorte que l'activation de ces crochets à partir d'un emplacement contrôlé par l'attaquant est la voie d'exécution du code à distance. La correction donnée rejette de si longues routes avant qu'il y ait une possibilité que le nom soit tronqué et peut devenir .gitto. Ces corrections sont disponibles dans la note de sortie de Git 2.56.1: https: / / github.com / git / git / releases / tag / v2.56.1.

Comment ça marche techniquement (explication): vulnérabilité est une condition de troncation des entiers dans la logique qui valide et écrit des entrées dans l'index Git. Lors d'une opération de clonage récursif avec sous-modules, Git effectue des contrôles de sécurité sur les routes qu'il reçoit du dépôt distant. Si un itinéraire dépasse une certaine taille, il doit être invalidé. Cependant, dans ce cas, la vérification est effectuée avec une valeur qui est ensuite réduite (par troncation) lorsque Git décide comment créer le fichier sur disque. Un nom long peut, après avoir été tronqué, correspondre à .git. Dans les sous-modules nouvellement créés, .git n'est pas un répertoire standard, mais un fichier qui indique l'emplacement de l'objet Git ; ce fichier peut être remplacé par un lien symbolique car Git ne s'attend pas à un lien dans un sous-module nouvellement cloné. Si le lien pointe vers un dossier avec des crochets malveillants ou des fichiers de configuration, les opérations normales de Git plus tard peuvent exécuter ce code ou lire des paramètres qui changent le comportement du client.

Qui est touché et quel est le risque réel (confirmé ou estimé) : équipements et services utilisant des systèmes précorrigés Les versions Git et les opérations de clonage récursif de dépôts non entièrement fiables sont affectées. Les utilisateurs clients Git emballés par les troisièmes applications (IDE, clients graphiques, copie Git à l'intérieur des applications) sont potentiellement en danger si ces applications ne mettent pas à jour la copie intégrée. GitHub a appliqué les corrections à son infrastructure publique et à GitHub Enterprise Cloud, et a signalé que les versions de GitHub Enterprise Server et certaines applications GitHub recevront ou ont déjà reçu des mises à jour; cependant, Git mainteneurs pour Windows et d'autres distributions ont pris le temps de publier des binaires basés sur 2.56.1 au moment de l'annonce initiale. Cela signifie que, jusqu'à ce que chaque plate-forme ou paquet distribué mette à jour votre Git copie, le risque persiste pour ceux qui ne peuvent ou ne veulent pas mettre à jour.

Il est important de souligner ce qui n'est pas publiquement confirmé: il n'y a pas de référence claire dans les notes officielles à l'exploitation active dans la nature (il n'y a pas eu d'échantillons publics ou de rapports médico-légaux largement vérifiés au moment du patch). Étant donné le vecteur - les dépôts clonés récursivement - et la facilité d'intégrer des sous-modules, le risque d'abus est élevé en théorie, en particulier contre les développeurs et les serveurs qui automatisent les clones et les projets tiers. Les services qui effectuent des fusions ou des vérifications au nom des utilisateurs (par exemple, des vérifications sur des serveurs d'intégration continue ou des hôtes qui exécutent des opérations de code fournies par les utilisateurs) sont des groupes qui, selon GitLab, peuvent être des cibles privilégiées pour les exploits axés sur la commande git merge-tree.

Autres corrections, notamment: En plus de la CVE-2026-111760, la dernière série de correctifs corrige plusieurs échecs avec le potentiel de corruption de la mémoire, hors-limites de lecture et l'abus des fonctions d'importation rapide. Parmi eux, les vulnérabilités qui permettent d'écrire à l'extérieur de l'arborescence de référence après un clone vide par protocole v2, les étiquettes corrompues avec plusieurs signatures GPG, les patchs binaires qui dépassent la limite et causent des lectures hors limites, la surécriture du tampon dans de très grandes fusions avec des attributs de taille de conflit modifiés et la possibilité de lire ou de créer des fichiers arbitraires par certaines fonctionnalités de git fast-import; ces derniers sont maintenant bloqués à moins qu'ils ne soient explicitement invoqués --allow-unsafe-features. Le projet Git et des équipes d'hébergement comme GitHub et GitLab ont documenté les détails techniques supplémentaires et les mesures d'atténuation.

Que devrait faire le lecteur maintenant (actions concrètes): d'abord, vérifiez la version Git sur les machines que vous administrez en exécutant Git localement (par exemple avec git --version). Si vous utilisez une version avant 2.56.1 ou les versions parachevées des branches 2.50-2.55, mettez à jour dès que possible à partir de la source officielle ou du gestionnaire de paquets de votre système. Si votre organisation utilise des instances GitHub Enterprise Server, vérifiez les notes de version pour les versions parachevées (les versions corporatives qui ont déjà reçu les corrections sont listées par GitHub) et appliquez les mises à jour de la plate-forme selon le calendrier de maintenance. Aussi, si vous utilisez des applications qui incluent votre propre copie de Git (clients de bureau, ID, conteneurs ou applications tierces), demandez ou vérifiez auprès du fournisseur quand ils entreront la version corrigée et appliqueront vos mises à jour. GitHub publie également des recommandations provisoires: clone uniquement à partir d'origines que vous avez confiance et éviter l'utilisation du clonage récursif dans des dépôts non vérifiés; ne mélangez pas le contenu ou les étiquettes de sources peu fiables; et ne traitez pas les patchs binaires ou les flux d'importation rapide de sources peu fiables. Pour plus de détails sur la mise à jour de Git, voir la documentation officielle: https: / / docs.github.com / fr / get-started / using-git / update-git. Pour comprendre comment les crochets qui peuvent être abusés fonctionnent, la documentation officielle de Git sur les crochets est utile: https: / / git-scm.com / docs / githouks.

Comme mesure supplémentaire pour les administrateurs de serveurs qui ne sont pas encore en mesure de mettre à jour, GitLab et d'autres ont suggéré une atténuation temporaire pour des défaillances spécifiques (par exemple, définir la taille de conflit-marqueur dans info / attributs des dépôts ou désactiver les vérifications de fusion@-@ arborescence pour des dépôts peu fiables). Ces mesures spécifiques correspondent à certaines vulnérabilités entre celles corrigées et sont applicables dans des contextes où une mise à jour immédiate n'est pas possible.

Résumé : la vulnérabilité expose un vecteur pratique pour exécuter le code contenu dans des sous-modules malveillants pendant le clonage récursif. La solution officielle est déjà publiée; la responsabilité immédiate est de mettre à jour les copies de Git distribuées dans ses propres systèmes et services, et d'éviter les opérations automatisées sur des dépôts d'origine douteuse jusqu'à ce que toutes les parties de l'écosystème (systèmes opérationnels, clients et services) intègrent la correction.