Git : la faille CVE-2026-111760 laisse un dépôt piégé exécuter du code au clonage, mettez à jour Git et GitLab sur vos serveurs

Sources : annonce des failles de sécurité de Git (GitHub, 10 novembre 2026) ; avis GHSA-vp2w-7xxj-jvxr ; GitLab Critical Patch Release 19.5.4, 19.4.6, 19.3.8 ; suivi de sécurité Debian.

Le projet Git a publié le 10 novembre 2026 la version 2.56.1, accompagnée de six versions correctives pour les branches maintenues : 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 et 2.50.2. Elles ferment six vulnérabilités. La plus visible, CVE-2026-111760 (CVSS 8,0, avis GHSA-vp2w-7xxj-jvxr), permet à un dépôt piégé d'exécuter son propre code sur la machine qui le clone avec --recurse-submodules : le fichier .git d'un sous-module est remplacé par un lien symbolique, et Git exécute alors les hooks choisis par l'attaquant. La plus grave pour les forges auto-hébergées, CVE-2026-105437, est un débordement de tas dans la fusion à trois voies : GitLab la classe critique, car elle peut mener à l'exécution de commandes dans Gitaly, et l'a corrigée dans GitLab CE/EE 19.5.4, 19.4.6 et 19.3.8.

Cette actualité s'adresse aux administrateurs d'un serveur où Git tourne sans qu'on y pense : une instance GitLab, Forgejo ou Gitea, un runner d'intégration continue sous Linux ou sous Windows, un script qui clone des ressources FiveM ou des plugins Minecraft avant de redémarrer le serveur de jeu. Vous y trouverez la liste des failles, la version de Git à viser pour chaque branche, l'état des paquets Debian et Ubuntu au 12 novembre, les commandes de mise à jour de Git, de Git for Windows et de GitLab Omnibus, et les mesures à appliquer en attendant le paquet de votre distribution. Si vous déployez vos services en conteneurs, gardez sous la main notre guide installer Docker sur un VPS : une partie de la correction passe par la reconstruction d'images.

Ce qu'il faut retenir

• Versions corrigées de Git : 2.56.1, ou la version corrective de votre branche (2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3, 2.50.2). Les branches plus anciennes, comme la 2.39 de Debian 12 ou la 2.47 de Debian 13, dépendent d'un rétroportage par la distribution.
• CVE-2026-111760 : exécution de code au clonage récursif d'un dépôt malveillant. L'avis estime qu'elle ne se déclenche qu'avec l'option --recurse-submodules.
• CVE-2026-105437 : corruption du tas pendant une fusion, déclenchable par un attribut conflict-marker-size démesuré placé dans un .gitattributes commité. Elle touche GitLab de la 16.2 jusqu'aux versions corrigées exclues.
• GitLab : passez en 19.5.4, 19.4.6 ou 19.3.8. Les paquets Linux officiels (Omnibus) et les images Docker embarquent le Git corrigé ; mettre à jour le git du système ne suffit pas.
• Distributions : au 12 novembre, Debian n'a pas encore publié de paquet corrigé, bookworm (2.39.5) et trixie (2.47.3) sont marqués vulnérables, et Ubuntu évalue encore l'impact.
• Exploitation : aucun des avis publiés ne signale d'exploitation à ce jour.

Les six vulnérabilités corrigées par Git 2.56.1

Les six failles partagent un point commun : elles demandent qu'un contenu contrôlé par l'attaquant arrive dans Git, qu'il s'agisse d'un dépôt à cloner, d'une branche à fusionner, d'un tag signé, d'un patch binaire ou d'un flux d'import. Elles concernent donc d'abord les machines qui manipulent du code venu de l'extérieur : postes de développeurs, serveurs de build, runners CI et forges qui calculent la fusionnabilité des merge requests.

Pour CVE-2026-114466, les versions corrigées refusent désormais ces trois fonctions dans le flux d'entrée, sauf si l'appelant passe explicitement l'option --allow-unsafe-features, à réserver aux flux produits par un programme de confiance. L'annonce ajoute des contrôles de débordement sur les allocations d'entrées d'index pendant le checkout, en complément de la limite de longueur de chemin introduite pour CVE-2026-111760.

CVE-2026-111760 : un sous-module piégé exécute ses hooks au clonage

Un sous-module est un dépôt Git imbriqué dans un autre. Dans le dépôt parent, son répertoire de travail ne contient pas de dossier .git complet mais un simple fichier .git (un « gitfile ») qui pointe vers le vrai répertoire Git du sous-module. Les hooks sont des scripts que Git exécute automatiquement à certaines étapes, par exemple après un checkout, et ils vivent dans ce répertoire Git avec la configuration du dépôt.

La faille repose sur une troncature d'entier dans la gestion de l'index : un chemin extrêmement long passe la validation sous un nom, puis il est écrit sous un nom plus court. Un attaquant s'en sert pour remplacer le gitfile d'un sous-module par un lien symbolique vers un répertoire qu'il contrôle, avec sa propre configuration et ses propres hooks. Pendant un clonage récursif, Git utilise ce répertoire comme s'il s'agissait du sous-module légitime et exécute le code de l'attaquant, avec les droits du compte qui lance le clone.

L'avis GitHub note la faille 8,0 sur 10 (CVSS 3.1, vecteur AV:N/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:H) : complexité élevée et action de la victime requise, mais impact complet en cas de réussite. Il précise surtout que le problème ne serait déclenchable qu'avec l'option --recurse-submodules. Le correctif rejette les chemins d'entrée d'index trop longs avant que leur longueur puisse être tronquée.

Sur un serveur, les situations à risque sont concrètes :

• un runner CI qui récupère les sous-modules de façon récursive (dans GitLab CI, la variable GIT_SUBMODULE_STRATEGY: recursive) sur des projets ou des forks que vous ne maîtrisez pas ;
• un script de déploiement qui clone des ressources FiveM, des plugins Minecraft ou des mods depuis des dépôts publics avant de relancer le serveur, comme on en croise dans les procédures décrites dans notre article sur les scripts FiveM à éviter ;
• une installation Python depuis l'URL d'un dépôt (pip install git+https://...) : quand le dépôt contient un fichier .gitmodules, pip lance git submodule update --init --recursive après le clone, que la documentation de git clone présente comme l'équivalent exact de --recurse-submodules. Installer un paquet depuis un dépôt inconnu revient de toute façon à exécuter son code de construction : réservez-le aux dépôts de confiance ;
• un administrateur qui teste un projet trouvé sur Internet directement sur la machine de production, en root.

Le compte qui clone est celui qui exécute le code piégé. Un clone lancé en root sur le serveur de jeu donne donc la machine entière ; lancé par un utilisateur Unix dédié sans sudo, il limite les dégâts à ce compte et à ses permissions sur le système de fichiers.

CVE-2026-105437 : le débordement de tas qui menace GitLab et Gitaly

Lors d'une fusion à trois voies, Git calcule la taille du résultat avant de l'écrire, marqueurs de conflit compris. Ce total était stocké dans un entier signé de 32 bits. Un petit fichier avec beaucoup de conflits et un attribut conflict-marker-size énorme, que n'importe qui peut placer dans un .gitattributes commité, suffit à faire déborder le calcul : Git alloue un tampon trop petit puis écrit au-delà. Les commandes git merge, git rebase, git cherry-pick et git merge-tree sont concernées. Le correctif calcule désormais la taille sur un type adapté, avec contrôle de débordement, et refuse les fusions dont le résultat ne peut pas être représenté.

La fiche CVE lui attribue un score CVSS 3.1 de 7,5. GitLab, de son côté, classe son correctif comme critique : sur une forge, les tests de fusionnabilité tournent côté serveur, si bien qu'un utilisateur capable de pousser une branche et d'ouvrir une merge request peut déclencher l'écriture hors limites, ce qui pourrait permettre d'exécuter des commandes arbitraires dans l'environnement Gitaly, le service qui stocke et manipule les dépôts. Sont touchées toutes les versions de GitLab CE/EE depuis la 16.2 jusqu'aux versions 19.3.8, 19.4.6 et 19.5.4 exclues. GitLab.com et GitLab Dedicated sont déjà corrigés. GitLab a aussi publié une règle de détection pour les instances auto-hébergées, intitulée « Git merge-tree child process crash ».

Ce scénario n'est pas propre à GitLab : toute forge qui calcule ou réalise des fusions avec le binaire git du serveur, comme Forgejo ou Gitea pour les pull requests, est exposée aux utilisateurs qui peuvent y pousser du code. Pour les failles précédentes de GitLab et la façon de les traiter, voir notre actualité sur la faille critique CVE-2026-110264 de GitLab.

Quelle version de Git est corrigée sur votre distribution

Le projet Git ne corrige que ses branches maintenues. Les distributions Linux, qui figent souvent une version plus ancienne pour toute la durée de vie d'une release, rétroportent les correctifs dans leur propre paquet, sans changer le numéro de version principal.

État des paquets relevé le 12 novembre 2026 :

Alpine compte ici parce que c'est la base de nombreuses images Docker, dont celle de Gitea : un conteneur reconstruit sur Alpine 3.24 récupère le Git corrigé dès maintenant.

Vérifier la version de Git sur vos serveurs

Tout se fait en ligne de commande, dans un terminal ouvert en SSH sur chaque VPS ou serveur dédié. La commande suivante donne la version du binaire appelé par défaut, et la seconde son emplacement :

git --version
command -v git

Une version 2.56.1, ou l'une des versions correctives listées plus haut, est à jour. Sur Debian et Ubuntu, le numéro ne suffit pas : le paquet corrigé de bookworm affichera toujours 2.39.5. Vérifiez alors que le journal des modifications du paquet installé cite bien les CVE :

zgrep -E 'CVE-2026-(111760|105437)' /usr/share/doc/git/changelog.Debian.gz

Sur AlmaLinux, Rocky Linux ou Fedora, l'équivalent passe par le journal RPM :

rpm -q --changelog git | grep -E 'CVE-2026-(111760|105437)'

Aucune sortie signifie que le correctif n'est pas encore installé. N'oubliez pas les autres binaires git présents sur la machine : celui de chaque conteneur (docker exec nom-du-conteneur git --version), celui embarqué par GitLab, ou une version compilée à la main dans /usr/local/bin qui passe avant celle du paquet dans le PATH.

Sous Windows, sur un VPS Windows qui héberge un runner CI ou un poste de build, c'est Git for Windows qui est installé. Sa version 2.56.1 (tag v2.56.1.windows.1) est sortie le 10 novembre 2026 et ses notes de version citent les deux CVE. Dans PowerShell, git --version doit afficher git version 2.56.1.windows.1 ; sinon, l'outil de mise à jour intégré télécharge et installe la dernière version :

git update-git-for-windows

Côté poste de travail, GitHub indique coordonner des versions de GitHub Desktop et de l'application GitHub Copilot qui embarquent un Git corrigé : installez-les dès leur sortie.

Mettre à jour Git dès l'arrivée des paquets

Quand Debian ou Ubuntu publiera le paquet corrigé, la mise à jour ciblée tient en une ligne, sans toucher au reste du système :

sudo apt update && sudo apt install --only-upgrade git

Sur les distributions de la famille Red Hat :

sudo dnf upgrade git

Si vos serveurs appliquent déjà les mises à jour de sécurité automatiquement, le paquet git suivra le même chemin ; notre guide pour automatiser les mises à jour de sécurité sur Ubuntu explique comment le configurer et le contrôler. Sur Ubuntu, il existe une option pour ne pas attendre : le PPA ppa:git-core/ppa propose 2.56.1 depuis le 11 novembre pour Ubuntu 22.04, 24.04 et 26.04. Il remplace le Git de l'archive par la dernière version amont, avec ses changements de comportement : à réserver aux machines où cette montée de version ne casse rien.

sudo add-apt-repository ppa:git-core/ppa
sudo apt update && sudo apt install --only-upgrade git
git --version

Passer GitLab Omnibus en 19.5.4

GitLab n'utilise pas le git de votre distribution : le paquet Linux officiel, dit Omnibus, et les images de conteneur embarquent leur propre Git, déjà corrigé dans les versions du 10 novembre, avec le reste de la pile (Gitaly, la base PostgreSQL, Redis, le serveur web Nginx et le serveur d'application Puma). Commencez par relever la version installée :

sudo gitlab-rake gitlab:env:info

La version de GitLab et celles des composants embarqués figurent aussi dans /opt/gitlab/version-manifest.txt. Avant de toucher au paquet, faites une sauvegarde : la première commande archive les dépôts et la base de données dans /var/opt/gitlab/backups, la seconde copie la configuration dans /etc/gitlab/config_backup/. Cette seconde étape compte, car le backup applicatif ne contient ni gitlab.rb ni gitlab-secrets.json, qui porte la clé de chiffrement de la base.

sudo gitlab-backup create
sudo gitlab-ctl backup-etc

Visez ensuite la version corrective de votre branche : 19.5.4, 19.4.6 ou 19.3.8. Sur Debian ou Ubuntu, pour l'édition Community :

sudo apt update && sudo apt install gitlab-ce=19.5.4-ce.0

Pour l'édition Enterprise, remplacez par gitlab-ee=19.5.4-ee.0. Sur AlmaLinux ou Rocky Linux 9 : sudo dnf install gitlab-ce-19.5.4-ce.0.el9 (suffixe .el8 sur une version 8). En Docker, l'image gitlab/gitlab-ce:19.5.4-ce.0 est disponible sur Docker Hub depuis le 10 novembre : changez le tag dans votre fichier Compose, puis docker compose pull et docker compose up -d.

Ces versions n'apportent aucune nouvelle migration de base de données, et GitLab indique qu'un déploiement multi-nœuds, en cluster, ne devrait pas nécessiter d'interruption. Sur une instance à un seul nœud, le paquet Omnibus arrête les services, lance les migrations puis les redémarre : prévoyez une courte coupure. Contrôlez ensuite que tout est reparti et suivez les logs de Gitaly quelques minutes :

sudo gitlab-ctl status
sudo gitlab-ctl tail gitaly

Les archives restent sur la même machine que l'instance : copiez-les ailleurs, notre guide pour sauvegarder un VPS avec rsync vers un serveur distant couvre la partie hors site. Une instance encore en 19.2 ou plus ancienne n'a pas de version corrective dans cette série : il faut suivre le chemin de mise à jour de GitLab jusqu'à une branche corrigée.

Pour une installation compilée depuis les sources, GitLab demande de suivre la procédure de mise à jour de Gitaly, qui reconstruit les binaires Git qu'il embarque, puis de reconstruire le Git désigné par git.bin_path dans config/gitlab.yml depuis la branche stable de Gitaly correspondante. Si ce Git vient d'un paquet de distribution, il doit être en 2.56.1 ou plus, ou dans une version patchée par la distribution pour CVE-2026-105437.

Forgejo, Gitea et runners CI : le git du système ou de l'image

Contrairement à GitLab, Forgejo et Gitea n'embarquent pas leur propre Git : leur documentation d'installation demande simplement qu'il soit présent sur le serveur, et ils appellent ce binaire pour manipuler les dépôts, y compris pour vérifier qu'une pull request se fusionne sans conflit puis pour la fusionner. Deux cas se présentent :

• Installation par binaire ou paquet : c'est le git de la distribution qui travaille. La forge est corrigée quand ce paquet l'est, après un redémarrage du service, par exemple sudo systemctl restart forgejo ou sudo systemctl restart gitea selon le nom de votre unité systemd. Cette mise à jour ne touche ni la base de données de la forge (SQLite, MySQL, MariaDB ou PostgreSQL), ni le reverse proxy Nginx ou Apache placé devant elle, décrit dans notre guide Nginx en reverse proxy sur un VPS Linux.
• Installation en Docker : c'est le git de l'image. L'image officielle de Gitea part d'Alpine 3.24 et installe le paquet git. Vérifiez la version dans le conteneur ; si vous utilisez l'image de l'éditeur telle quelle, attendez une image qui embarque un Git corrigé et contrôlez-la après le pull. Si vous construisez votre propre image, reconstruisez-la sans cache avec docker compose build --pull --no-cache, pour que le paquet git soit réellement retéléchargé. Notre guide Docker Compose sur VPS Linux rappelle le cycle pull, build et redémarrage.

Les runners CI suivent la même logique. Un runner GitLab en exécuteur shell ou un runner GitHub Actions auto-hébergé installé directement sur la machine utilise le git de l'hôte. En exécuteur Docker, le runner GitLab clone les dépôts avec son image auxiliaire (helper image) : c'est le git de cette image qui compte, pas celui de l'hôte. Côté GitHub, l'annonce précise que Codespaces et les runners GitHub Actions hébergés recevront un Git corrigé ; les runners auto-hébergés restent à votre charge. Jusqu'à la mise à jour, réglez GIT_SUBMODULE_STRATEGY: none sur les projets qui exécutent du code venu de contributeurs externes.

En attendant le correctif : trois mesures immédiates

Ces précautions réduisent l'exposition mais, comme le rappelle l'annonce de Git, elles ne remplacent pas l'installation des correctifs.

1. Plus de clonage récursif de dépôts non fiables. Clonez sans l'option, lisez le fichier .gitmodules pour savoir quels dépôts seraient récupérés, et n'initialisez les sous-modules qu'après la mise à jour de Git, sur un dépôt dont vous connaissez l'origine. Faites-le avec un compte sans privilèges, jamais en root sur un serveur de production.

git clone https://exemple.org/projet.git
cat projet/.gitmodules

2. Fixer submodule.recurse à false au niveau du système. Ce réglage décide si git pull, git fetch, git checkout et d'autres commandes descendent dans les sous-modules par défaut. Sa valeur par défaut est déjà false ; l'écrire dans /etc/gitconfig documente le choix sur la machine. Ses limites sont à connaître : la documentation de Git précise qu'il ne s'applique pas à git clone, et une valeur définie dans le ~/.gitconfig d'un utilisateur ou dans la configuration d'un dépôt l'emporte sur celle du système. Vérifiez donc aussi ce que voit chaque compte qui clone :

sudo git config --system submodule.recurse false
git config --show-origin --get-all submodule.recurse

Si la seconde commande affiche true avec un fichier d'origine, retirez la ligne de ce fichier.

3. Neutraliser conflict-marker-size dans les dépôts hébergés. Le fichier info/attributes d'un dépôt a la priorité la plus haute sur tous les .gitattributes commités. Y écrire * conflict-marker-size=7 ramène la taille des marqueurs de conflit à leur valeur par défaut pour tous les fichiers, quelle que soit la valeur poussée par un utilisateur : c'est le contournement indiqué dans la fiche CVE. Pour une forge Forgejo ou Gitea, ou un simple serveur Git en SSH, la boucle Bash suivante parcourt les répertoires des dépôts et ajoute la ligne à chaque dépôt nu. Remplacez le chemin par la valeur ROOT de la section [repository] de votre app.ini, et lancez-la sous l'utilisateur propriétaire des dépôts (souvent git) :

DEPOTS=/chemin/vers/les/depots
find "$DEPOTS" -type d -name '*.git' -prune | while read -r d; do
  mkdir -p "$d/info"
  grep -qxF '* conflict-marker-size=7' "$d/info/attributes" 2>/dev/null \
    || echo '* conflict-marker-size=7' >> "$d/info/attributes"
done

Les dépôts créés après le passage de la boucle n'auront pas la ligne : relancez-la, ou planifiez-la, jusqu'à la mise à jour de Git. Sur GitLab, la parade reste le passage en 19.5.4, 19.4.6 ou 19.3.8.

Les termes à connaître

En résumé

Faites l'inventaire des machines où Git tourne pour le compte des autres : forge, runners, scripts de déploiement de vos serveurs de jeu. Sur GitLab, passez dès maintenant en 19.5.4, 19.4.6 ou 19.3.8. Ailleurs, visez Git 2.56.1 ou la version corrective de votre branche, installez le paquet de Debian ou d'Ubuntu dès sa publication, et reconstruisez les images Docker qui embarquent Git. En attendant, pas de --recurse-submodules sur des dépôts que vous ne connaissez pas, et * conflict-marker-size=7 dans les dépôts hébergés. Pour isoler une forge ou des runners de vos serveurs de production, un VPS Linux dédié à l'intégration continue ou un serveur dédié découpé en machines virtuelles grâce à la virtualisation limitent ce qu'un dépôt piégé peut atteindre : un runner compromis dans sa machine virtuelle ne voit ni la base de données ni les fichiers du serveur de jeu. Pour durcir l'accès à ces machines, voir aussi notre guide pour sécuriser SSH sur un VPS Linux.