Mehdi Assabbane
← Tous les articles

GitLab CVE-2026-110264 : la faille critique qui touche toutes les versions depuis 2014

Mehdi Assabbane ·

En bref (état au 23 octobre 2026)

  • GitLab a corrigé le 21 octobre 2026 une faille critique (CVSS 10,0), CVE-2026-110264, qui pouvait permettre à un utilisateur non authentifié d'exécuter du code sur un serveur GitLab auto-hébergé.
  • Elle touche toutes les versions depuis GitLab 7.0 (2014). Versions corrigées : 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 et 18.11.13.
  • Une première faille critique de même nature, CVE-2026-97229, avait été corrigée le 12 octobre. Les versions publiées ce jour-là (19.4.2, 19.3.5, 19.2.8) restent vulnérables à la seconde.
  • GitLab.com et GitLab Dedicated sont déjà corrigés. Seules les instances auto-hébergées (self-managed) sont à mettre à jour.

Introduction

En moins de dix jours, GitLab a publié deux correctifs critiques notés 10 sur 10 pour ses éditions auto-hébergées Community (CE) et Enterprise (EE). Les deux failles ont la même origine : un dépassement d'entier lors de la compilation d'une expression régulière spécialement construite. La seconde, CVE-2026-110264, est la plus large : elle concerne l'ensemble des versions publiées depuis 2014.

Pour beaucoup d'équipes, GitLab est le cœur de la chaîne DevOps : code source, pipelines CI/CD, registres d'images, secrets de déploiement. Une exécution de code sur ce serveur donne potentiellement accès à tout cela. Cet article fait le point sur ce qui est confirmé, la version à installer selon votre branche et la procédure de mise à jour.

Les deux failles en détail

CVE-2026-97229 CVE-2026-110264
Correctif publié 12 octobre 2026 21 octobre 2026
Score CVSS 3.1 : 10,0 CVSS : 10,0
Nature Dépassement d'entier dans le compilateur d'expressions régulières CI/CD Dépassement d'entier dans le compilateur d'expressions régulières
Authentification requise Non Non
Versions affectées 19.2 < 19.2.8, 19.3 < 19.3.5, 19.4 < 19.4.2 Toutes depuis 7.0, avant 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3 et 19.5.1
Exploitation connue Aucune signalée par GitLab Aucune signalée par GitLab

CVE-2026-97229 : la regex des pipelines

Selon l'avis de GitLab, une validation insuffisante des expressions régulières permettait, sous certaines conditions, à un utilisateur non authentifié d'exécuter du code arbitraire en soumettant une expression régulière piégée dans une configuration CI/CD. Le correctif est arrivé avec les versions 19.4.2, 19.3.5 et 19.2.8.

Point d'attention : la version 19.3.4, publiée en même temps, comportait un bogue sur les pages de merge requests lorsque l'intégration Ona est activée. La cible recommandée sur cette branche était donc 19.3.5.

CVE-2026-110264 : douze ans de versions concernées

Le 21 octobre, GitLab a corrigé un second dépassement d'entier lors de la compilation d'une expression régulière, avec le même impact : exécution de code arbitraire sur le serveur, sans authentification. L'avis indique que toutes les versions depuis 7.0 sont affectées, et le correctif a été rétroporté jusqu'à la branche 18.11.

Cette publication corrige aussi onze autres vulnérabilités, dont deux de sévérité élevée : un défaut d'authentification dans l'association automatique OmniAuth/LDAP (CVE-2026-15723, CVSS 8,2) et un empoisonnement de cache des points de découverte OAuth/OIDC (CVE-2026-112212, CVSS 7,5).

Quelle version installer ?

Votre version cible dépend de la branche sur laquelle vous êtes :

Branche installée Version minimale à installer
19.5 19.5.1
19.4 19.4.3
19.3 19.3.6
19.2 19.2.9
19.1 19.1.9
19.0 19.0.10
18.11 18.11.13
18.10 ou antérieure Monter vers une branche maintenue (voir plus bas)

Si vous avez mis à jour le 12 octobre vers 19.4.2, 19.3.5 ou 19.2.8, vous êtes protégé contre la première faille mais pas contre la seconde : une nouvelle mise à jour est nécessaire.

Vérifier sa version

Sur une installation par paquet Linux (Omnibus) :

sudo gitlab-rake gitlab:env:info | grep -A2 '^GitLab information'

Affiche la version de GitLab installée, sans rien modifier.

cat /opt/gitlab/embedded/service/gitlab-rails/VERSION

Lit directement le fichier de version de l'application.

Sur une installation Docker :

docker ps --format '{{.Names}}\t{{.Image}}' | grep -i gitlab

Affiche l'image utilisée par le conteneur GitLab, dont l'étiquette indique la version (par exemple gitlab/gitlab-ee:19.4.2-ee.0).

Vous pouvez aussi consulter la version dans l'interface : Admin > Tableau de bord, ou via l'aide (/help) une fois connecté.

Mettre à jour sans mauvaise surprise

1. Sauvegarder

sudo gitlab-backup create

Crée une sauvegarde des données GitLab (dépôts, base de données, pièces jointes) dans le répertoire de sauvegarde configuré.

Attention : cette sauvegarde n'inclut pas les fichiers /etc/gitlab/gitlab.rb et /etc/gitlab/gitlab-secrets.json. Copiez-les à part, dans un endroit sûr : sans gitlab-secrets.json, les données chiffrées (variables CI/CD, jetons d'intégration) d'une sauvegarde sont inutilisables.

sudo cp /etc/gitlab/gitlab.rb /etc/gitlab/gitlab-secrets.json /root/

2. Prévoir l'interruption

Selon GitLab, les versions 19.4.3 et 19.3.6 contiennent des migrations de base de données (19.4.3 aussi des migrations post-déploiement). Sur une instance mono-serveur, GitLab reste indisponible jusqu'à la fin des migrations. Les autres versions corrigées n'en contiennent pas. Les instances multi-nœuds peuvent appliquer la procédure de mise à jour sans interruption.

3. Installer

Sur Debian/Ubuntu, en restant sur votre branche (adaptez l'édition ee/ce et la version) :

sudo apt-get update
sudo apt-get install gitlab-ee=19.4.3-ee.0

Sur RHEL et dérivés :

sudo dnf install gitlab-ee-19.4.3-ee.0.el9

Avec Docker, modifiez l'étiquette de l'image dans votre docker-compose.yml (par exemple gitlab/gitlab-ee:19.4.3-ee.0), puis recréez le conteneur.

Une mise à jour de correctif au sein d'une même branche (19.4.x vers 19.4.3) ne nécessite pas de chemin de mise à jour particulier. Pour changer de branche, utilisez l'outil officiel GitLab Upgrade Path (voir aussi notre article sur les changements majeurs de GitLab 19).

4. Vérifier

sudo gitlab-rake gitlab:check SANITIZE=true

Lance les contrôles de cohérence de GitLab (configuration, permissions, services) et masque les informations sensibles dans la sortie.

Vérifiez aussi, dans Admin > Monitoring > Background migrations, que les migrations se terminent, puis testez un pipeline, un git push et une connexion.

5. Ne pas oublier les runners

GitLab Runner se met à jour séparément. Profitez de l'intervention pour vérifier que vos runners sont sur une version récente.

Et si la mise à jour doit attendre ?

GitLab ne propose aucune mesure d'atténuation : la mise à jour est la seule solution. En attendant, réduisez l'exposition :

  • restreignez l'accès à l'instance (VPN, liste d'adresses IP autorisées) si elle est exposée sur Internet ;
  • désactivez temporairement l'inscription publique de nouveaux comptes ;
  • surveillez les journaux.

GitLab a publié des règles de détection pour les instances auto-hébergées, notamment « Onigmo native worker crash » (Onigmo est le moteur d'expressions régulières de Ruby) et « Org mode render error burst ». Des plantages répétés de workers Puma ou Sidekiq après la mi-octobre méritent une analyse.

sudo gitlab-ctl tail puma | grep -iE 'segfault|signal|crash'

Suit en direct les journaux de Puma (le serveur web de GitLab) et filtre les plantages. Interrompez avec Ctrl+C.

Checklist

  • Identifier toutes les instances GitLab auto-hébergées (production, préproduction, instances oubliées).
  • Relever la version de chacune.
  • Sauvegarder les données et copier gitlab.rb et gitlab-secrets.json.
  • Planifier l'interruption si la cible est 19.4.3 ou 19.3.6 sur un seul serveur.
  • Installer la version corrigée de la branche.
  • Lancer gitlab:check et vérifier les migrations en arrière-plan.
  • Mettre à jour les runners.
  • Analyser les journaux depuis le 12 octobre au moins.
  • Pour les branches 18.10 et antérieures : planifier la montée de version.

FAQ

J'utilise GitLab.com. Dois-je faire quelque chose ? Non. GitLab.com tourne déjà sur une version corrigée, comme les instances GitLab Dedicated récentes.

J'ai mis à jour le 12 octobre. Suis-je protégé ? Contre CVE-2026-97229, oui. Contre CVE-2026-110264, non : les versions 19.4.2, 19.3.5 et 19.2.8 restent vulnérables. Installez 19.4.3, 19.3.6 ou 19.2.9.

Mon instance n'est accessible que depuis le réseau interne. Est-ce urgent ? Le risque est plus faible, mais la faille ne demande pas d'authentification : toute personne ou machine compromise du réseau interne peut l'exploiter. Mettez à jour rapidement.

Ces failles sont-elles exploitées ? Au 22 octobre 2026, GitLab ne signale pas d'exploitation. La situation peut évoluer vite pour une faille de ce niveau : ne comptez pas sur ce délai.

Je suis sur une version 17 ou 18 ancienne. Que faire ? Aucune version corrigée n'est publiée avant 18.11. Il faut monter de version en suivant le chemin indiqué par l'outil GitLab Upgrade Path, avec des étapes intermédiaires obligatoires.

Conclusion

Deux failles critiques en dix jours sur l'outil qui détient votre code et vos secrets de déploiement : c'est le moment de vérifier que la mise à jour de GitLab fait partie de vos routines, et pas seulement de vos urgences.

  1. Installez la version corrigée de votre branche aujourd'hui, même si vous avez mis à jour le 12 octobre.
  2. Sauvegardez correctement, secrets compris.
  3. Abonnez-vous aux annonces de sécurité de GitLab, qui publie des versions correctives deux fois par mois.

Sources officielles