Ce que corrige la publication GitLab d'octobre 2026
Le 21 octobre 2026, GitLab a publié une version corrective critique pour ses éditions Community et Enterprise. CVE-2026-110264 est un dépassement d'entier dans le compilateur d'expressions régulières : d'après l'avis, un utilisateur non authentifié pourrait exécuter du code arbitraire sur le serveur GitLab. Le vecteur CVSS 3.1 publié par une source secondaire est AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, soit l'exposition réseau, aucune authentification, aucune interaction. Les versions touchées vont de 7.0 jusqu'à la version corrigée de chaque branche.
Plusieurs failles circulent en ce moment autour du moteur d'expressions régulières de GitLab, et il est facile de les confondre. CVE-2026-97229, corrigée le 12 octobre 2026 dans les versions 19.4.2, 19.3.5 et 19.2.8, visait le compilateur de regex des configurations CI/CD. Ces trois versions restent vulnérables à CVE-2026-110264. CVE-2026-85706, une traversée de chemin déjà exploitée, est une autre affaire, traitée dans notre article sur le patch d'urgence ou la migration vers Gitea. Attention : la version 19.3.2 qu'il cite comme corrigée est elle-même vulnérable à CVE-2026-110264, car la branche 19.3 n'est protégée qu'à partir de 19.3.6. La même publication corrige onze autres failles, de gravité haute à faible : elles justifient aussi la mise à jour, mais ne changent pas la marche à suivre.
Quelle version installer selon votre branche
Faites défiler le tableau
| Votre branche | Statut | Version à installer |
|---|---|---|
| 19.5.x | Affectée avant 19.5.1 | 19.5.1 |
| 19.4.x | Affectée avant 19.4.3, y compris 19.4.2 | 19.4.3 |
| 19.3.x | Affectée avant 19.3.6, y compris 19.3.5 | 19.3.6 |
| 19.2.x | Affectée avant 19.2.9, y compris 19.2.8 | 19.2.9 |
| 19.1.x | Affectée avant 19.1.9 | 19.1.9 |
| 19.0.x | Affectée avant 19.0.10 | 19.0.10 |
| 18.11.x | Affectée avant 18.11.13 | 18.11.13 |
| Version antérieure à 18.11 | Affectée, la plage commence à 7.0 | Suivre le chemin de mise à niveau officiel jusqu'à une branche corrigée |
Êtes-vous exposé : la lecture qui tranche
La question n'est pas de savoir si votre instance est « importante », mais si elle est auto-gérée et en dessous de la version corrigée de sa branche. GitLab.com est déjà corrigé, et les locataires GitLab Dedicated en 19.3.5-internal0 ou 19.4.2-internal0 et au-delà embarquent déjà les correctifs. Pour toute installation que vous administrez vous-même, sur un VPS ou sur un serveur dédié, la réponse est simple : vérifiez le numéro de version et comparez-le au tableau ci-dessus. Une instance en 19.4.2 se croit souvent à jour parce qu'elle a reçu le correctif du 12 octobre. Elle ne l'est pas.
L'avis ne précise pas de configuration qui désactiverait le défaut. Une instance joignable depuis Internet est évidemment la plus urgente à traiter, mais une instance interne n'est pas pour autant hors de portée d'un poste compromis du réseau. Au moment de la rédaction, GitLab ne rapporte aucune exploitation de CVE-2026-110264 et d'après les sources consultées la faille ne figure pas au catalogue CISA des vulnérabilités exploitées. C'est une fenêtre pour agir à froid, pas une raison de différer.
Vérifier votre version et préparer la fenêtre
Lire la version exacte
Dans l'interface, le menu d'aide affiche la version. En ligne de commande :
sudo gitlab-rake gitlab:env:info. Sur Docker :docker exec gitlab cat /opt/gitlab/version-manifest.txt. Notez le numéro complet, pas seulement la branche.Identifier l'édition installée
dpkg -l | grep gitlabsur Debian et Ubuntu,rpm -q gitlab-ce gitlab-eesur RHEL et AlmaLinux. Le nom du paquet,gitlab-ceougitlab-ee, décide de la commande de mise à jour. Les deux éditions sont concernées.Vérifier le chemin de mise à niveau
Sautez directement à la version corrigée seulement si aucun palier intermédiaire n'est requis. GitLab précise qu'on ne peut pas monter d'un coup vers la dernière version majeure quand le chemin impose des étapes. Dans ce cas, installez chaque palier avec son numéro exact. L'outil de chemin de mise à niveau de la documentation officielle donne la liste.
Contrôler l'espace disque
df -h /var/opt/gitlab. L'archive de sauvegarde et les migrations ont besoin de place. Une partition presque pleine est la première cause de mise à jour interrompue au milieu.Annoncer la coupure
Sur un nœud unique, GitLab prévient que les migrations doivent se terminer avant le démarrage : l'indisponibilité est normale. Prévenez les équipes, laissez les pipelines en cours se terminer et notez l'état des runners avec
sudo gitlab-ctl status.Garder une sortie de secours
Gardez ouverte une seconde session SSH et le numéro de la version actuelle. Si un palier échoue, vous saurez exactement à quelle version revenir et quelle archive restaurer.
La sauvegarde avant tout, et ce qu'elle ne contient pas
Le paquet sauvegarde la base automatiquement avant d'installer une version plus récente. GitLab recommande pourtant de conserver votre propre sauvegarde complète et à jour, et ne désactivez pas cette étape automatique (le fichier vide /etc/gitlab/skip-auto-backup existe pour cela). La commande est sudo gitlab-backup create, ou docker exec -t gitlab gitlab-backup create pour un conteneur nommé gitlab. L'archive est un fichier .tar unique, que le paramètre backup_path place localement.
Le piège classique : cette sauvegarde ne contient pas la configuration. Copiez à part /etc/gitlab/gitlab-secrets.json et /etc/gitlab/gitlab.rb, par exemple avec sudo mkdir -p /root/gitlab-config-backup && sudo cp -a /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab.rb /root/gitlab-config-backup/. Sans gitlab-secrets.json, une restauration laisse illisibles les données chiffrées, comme les variables CI/CD et les secrets d'authentification à deux facteurs. Mettez ensuite les deux copies hors de la machine, sur un stockage distinct. Un retour en arrière n'est possible qu'avec une sauvegarde de base prise sur la même version et la même édition que celles que vous restaurez.
Mettre à jour selon votre installation
Debian et Ubuntu (paquet Omnibus)
sudo apt update && sudo apt install gitlab-ce=<version>-ce.0
Remplacez<version>par la version du tableau, par exemple celle de votre branche. Pour l'édition Enterprise :sudo apt install gitlab-ee=<version>-ee.0.RHEL, AlmaLinux et Oracle Linux
sudo dnf install gitlab-ce-<version>-ce.0.el9
Utilisez.el8sur une machine en version 8, etgitlab-ee-<version>-ee.0.el9pour l'édition Enterprise.Docker avec docker run
sudo docker stop gitlabsudo docker rm gitlabsudo docker pull gitlab/gitlab-ce:<version>-ce.0
Relancez ensuitedocker runavec exactement vos options d'origine : mêmes ports, mêmes volumes pourconfig,logsetdata, même--shm-size. Les données vivent dans les volumes, pas dans le conteneur supprimé.Docker avec Compose
Modifiez l'étiquette de l'image dans
docker-compose.ymlpour viser<version>-ce.0, puis :docker compose pulldocker compose up -ddocker compose logs -f gitlab
Si votre fichier utilise une étiquette flottante, fixez-la : une version épinglée rend la prochaine mise à jour lisible.Appliquer la configuration
Sur Docker, GitLab se reconfigure et se met à niveau au premier démarrage du conteneur. Sur un paquet, après toute modification de
gitlab.rb, appliquez-la avecsudo gitlab-ctl reconfigure. Laissez les migrations aller à leur terme avant de juger que l'instance est bloquée.Contrôler le résultat
sudo gitlab-ctl statussudo gitlab-rake gitlab:env:info
La version affichée doit être celle du tableau. Ouvrez l'interface, vérifiez qu'un dépôt se clone, qu'un pipeline démarre et que les runners se reconnectent.
Répétez sur une copie quand l'instance est critique
Restaurez la sauvegarde sur une machine jetable de même version, mettez-la à jour, puis chronométrez les migrations. Vous obtenez la durée réelle de la coupure et vous découvrez les surprises sans toucher à la production. Détruisez la copie ensuite : elle contient vos secrets.
Indisponibilité, migrations, vieux chemins : les trois craintes
Mettre à jour une forge en production fait peur pour des raisons précises, et l'avis de GitLab y répond sans détour. Les migrations de base de données : la publication en contient, ordinaires dans 19.4.3 et 19.3.6, et post-déploiement dans 19.4.3. La coupure : sur un nœud unique, elle est attendue puisque les migrations doivent finir avant le démarrage ; en multi-nœuds, les procédures de mise à jour sans interruption s'appliquent. Les vieilles versions : au-dessous de 18.11, respectez le chemin de mise à niveau officiel, palier par palier, sans sauter d'étape.
Ce que vous ne perdez pas, si la sauvegarde existe : vos dépôts, vos tickets, vos runners enregistrés et vos jetons. La peur de tout casser est légitime, mais attendre est le pari le plus risqué, parce que le détail technique de la faille doit devenir public sur le suivi de tickets 90 jours après la publication du correctif. Mieux vaut mettre à jour avant ce jour.
En attendant la fenêtre : réduire l'exposition, sans illusion
- Aucun contournement officiel — l'avis GitLab ne liste aucune parade : la seule mitigation est la mise à jour.
- Restreindre l'accès réseau — limiter l'instance à votre VPN ou à une liste d'adresses réduit les attaquants possibles. Ce n'est pas une mesure officielle, seulement une mesure d'attente.
- Ne pas inventer de règle de filtrage — aucun filtre nginx publié ne couvre cette faille : en écrire un de mémoire donne un faux sentiment de protection.
- Surveiller dès maintenant — appliquez les deux règles de détection publiées par GitLab, présentées plus bas, pour savoir si quelqu'un a déjà tenté quelque chose.
- Fixer l'échéance — notez une date de mise à jour dans l'équipe : une mesure d'attente sans date devient une habitude.
Contrôler les traces après la mise à jour
Appliquer les deux règles de détection
GitLab publie deux règles pour les instances auto-gérées : « Onigmo native worker crash » et « Org mode render error burst ». Reprenez-les depuis l'avis officiel dans votre outil de supervision ou de journaux.
Relire les journaux de GitLab
sudo ls -la /var/log/gitlabpuissudo gitlab-ctl tail. Cherchez des plantages répétés de processus de travail et des erreurs de rendu qui se concentrent sur une courte période, autour ou avant le 21 octobre.Contrôler les comptes et les jetons
Dans l'espace d'administration, passez en revue les utilisateurs récents, les administrateurs, les jetons d'accès personnels et les clés de déploiement. Tout ce qui n'a pas d'auteur connu mérite une explication.
Contrôler les runners et les projets
Listez les runners enregistrés et les webhooks. Un runner inconnu ou un hook ajouté récemment est un point d'entrée classique après une prise de contrôle.
Garder les journaux
Copiez les journaux utiles hors de la machine avant de les laisser tourner. Si un doute apparaît dans une semaine, vous aurez de quoi comparer.
Si le doute subsiste : tenir l'instance pour compromise
L'absence d'alerte ne prouve pas l'absence de compromission : les deux règles de GitLab détectent des symptômes, pas toutes les intrusions. Si un indice apparaît (règle de détection déclenchée, compte ou runner inconnu, plantages groupés), tenez l'instance pour compromise. Sans indice, l'exposition seule justifie la mise à jour, pas la rotation de tous les secrets. En cas d'indice, renouvelez les secrets d'instance, les variables CI/CD, les jetons de runner et les jetons d'accès, puis réenregistrez les runners. Une variable de pipeline qui contient une clé de déploiement ou un mot de passe de base de données doit être changée à la source, pas seulement dans GitLab. C'est fastidieux et c'est le prix d'une forge qui détient le code et les accès de production.
Dépannage : les blocages fréquents
E: Version '<version>-ce.0' for 'gitlab-ce' was not found— apt ne connaît pas encore ce numéro : relancezsudo apt update, vérifiez que le dépôt GitLab est configuré, puis vérifiez l'orthographe du numéro et le suffixe-ce.0.- Impossible de monter directement vers la version voulue — votre instance impose des paliers. Installez-les un par un avec leur numéro exact et laissez les migrations finir entre deux.
- Page d'erreur 502 juste après la mise à jour — les migrations tournent encore. Patientez, suivez
sudo gitlab-ctl tailet ne relancez pas les services à la main tant qu'elles ne sont pas terminées. - Conteneur démarré mais vide —
docker runa été relancé sans les volumes d'origine. Arrêtez-le et recréez-le avec les mêmes chemins pourconfig,logsetdata. - Restauration impossible après un retour en arrière — la sauvegarde doit venir de la même version et de la même édition. Restaurez avec la version qui l'a produite, puis remettez à jour.
Une forge sur un VPS : ce que ça change
Quand votre forge tourne sur un VPS dont vous avez le root, vous décidez de la fenêtre de mise à jour, de l'emplacement des sauvegardes et de la durée de conservation des journaux. Personne ne vous impose un calendrier, et personne ne met à jour à votre place : c'est la contrepartie. Prévoyez de la place disque pour l'archive, une copie hors de la machine, et un moyen de tester une restauration, comme décrit dans notre guide sur les sauvegardes avec restic. Pour installer GitLab, notre guide d'installation de GitLab CE sur VPS donne le point de départ. Si vous préférez déléguer l'administration du serveur, l'option administration VPS existe ; ce guide est fourni tel quel, sans prise en charge de votre instance.
La documentation officielle
Avis de la version corrective GitLab 19.5.1 : https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-5-1-released/
Avis du 12 octobre 2026 : https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-4-2-released/
Mise à jour d'un paquet Linux : https://docs.gitlab.com/update/package/
Mise à jour d'une installation Docker : https://docs.gitlab.com/install/docker/upgrade/
Sauvegarde de GitLab : https://docs.gitlab.com/administration/backup_restore/backup_gitlab/
Compte rendu de BleepingComputer : https://www.bleepingcomputer.com/news/security/gitlab-warns-of-new-max-severity-code-execution-vulnerability/
