{"id":184239,"date":"2026-11-12T11:41:56","date_gmt":"2026-11-12T09:41:56","guid":{"rendered":"https:\/\/prohoster.info\/blog\/news\/uyazvimost-v-git-dopuskayushhaya-vypolnenie-koda-pri-klonirovanii-iz-vredonosnogo-git-repozitoriya"},"modified":"2026-11-12T11:42:03","modified_gmt":"2026-11-12T09:42:03","slug":"git-vulnerability-allows-code-execution-when-cloning-a-malicious-git-repository","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/news\/git-vulnerability-allows-code-execution-when-cloning-a-malicious-git-repository","title":{"rendered":"Vuln\u00e9rabilit\u00e9 dans Git permettant l'ex\u00e9cution de code lors du clonage depuis un d\u00e9p\u00f4t Git malveillant.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Des versions corrig\u00e9es du syst\u00e8me de gestion de code source distribu\u00e9 Git 2.56.1, 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 et 2.50.2 ont \u00e9t\u00e9 publi\u00e9es, corrigeant 6 vuln\u00e9rabilit\u00e9s. La vuln\u00e9rabilit\u00e9 la plus critique (CVE-2026-111760) permet l'ex\u00e9cution de code lors de l'utilisation de la commande \u00ab git clone \u00bb en mode \u00ab --recurse-submodules \u00bb avec des d\u00e9p\u00f4ts contr\u00f4l\u00e9s par un attaquant.<\/p>\n
Le probl\u00e8me provient du fait que la longueur d'enregistrement d'un nom dans l'index est calcul\u00e9e \u00e0 l'aide d'un type entier 32 bits. Lors de la transmission d'un nom tr\u00e8s long tel que \u00ab .git\/... \u00bb, cela entra\u00eene un d\u00e9passement d'entier et un attaquant peut obtenir un calcul de longueur \u00e9quivalente \u00e0 4 octets. En cons\u00e9quence, lors de la v\u00e9rification de la valeur, les donn\u00e9es r\u00e9elles sont utilis\u00e9es, tandis que lors de l'ex\u00e9cution de l'op\u00e9ration, c'est la version tronqu\u00e9e \u00ab .git \u00bb qui est utilis\u00e9e, permettant \u00e0 l'attaquant de remplacer le fichier \u00ab .git \u00bb dans le sous-module par un lien symbolique pointant vers un r\u00e9pertoire contenant des configurations et des hooks.<\/p>\n
Autres vuln\u00e9rabilit\u00e9s :<\/p>\n
\n
CVE-2026-113408 \u2014 d\u00e9passement de r\u00e9pertoire refs\/ en transmettant un lien symbolique avec la valeur \u00ab refs\/heads\/...\/..\/....\/TARGET \u00bb comme branche HEAD lors de la clonage d'un d\u00e9p\u00f4t vide via le protocole Git v2. Lors de l'ex\u00e9cution ult\u00e9rieure de \u00ab git commit \u00bb, un fichier TARGET sera cr\u00e9\u00e9 \u00e0 la racine du d\u00e9p\u00f4t, ce qui peut \u00eatre utilis\u00e9 pour \u00e9craser des fichiers dans le d\u00e9p\u00f4t et permettre l'ex\u00e9cution de code.\n
CVE-2026-114467 \u2014 d\u00e9bordement de pile lors de la suppression de signatures GPG, ce qui peut potentiellement conduire \u00e0 l'ex\u00e9cution de code arbitraire. Le probl\u00e8me est caus\u00e9 par le fait que la fonction remove_signature() stocke les positions des signatures dans un tableau fixe, pr\u00e9vu pour un maximum de deux signatures. Lorsqu'un tag avec trois signatures ou plus est transmis, les donn\u00e9es sont sauvegard\u00e9es en dehors du tableau.\n
CVE-2026-114469 \u2014 lors de la v\u00e9rification des limites de taille des patches binaires, les donn\u00e9es \u00e9taient prises en compte avant le d\u00e9ballage des donn\u00e9es compress\u00e9es, ce qui conduisait \u00e0 la lecture de contenu en dehors des limites du tampon.\n
CVE-2026-105437 \u2014 corruption de m\u00e9moire lors de l'ex\u00e9cution de grandes op\u00e9rations de fusion en raison d'une accumulation de la taille du r\u00e9sultat dans un champ de type int. Dans la configuration GitLab, la vuln\u00e9rabilit\u00e9 peut \u00eatre exploit\u00e9e pour ex\u00e9cuter du code (probl\u00e8me bloqu\u00e9 dans GitLab 19.5.4).\n
CVE-2026-114466 \u2014 \u00e9criture de fichiers arbitraires dans le syst\u00e8me de fichiers via la commande \u00ab git fast-import \u00bb en raison d'une r\u00e9solution incompl\u00e8te de la vuln\u00e9rabilit\u00e9 CVE-2019-1348.\n<\/ul>\n