Faille GitLab CVSS 10 : 1 RCE sans authentification, le guide essentiel

Cette faille GitLab a tout pour inquiéter : score maximal, aucune authentification nécessaire, et une plage de versions touchées qui remonte à plus de dix ans. Elle vient d’un dépassement d’entier lors de la compilation d’une expression régulière spécialement fabriquée. Si tu héberges ton propre GitLab Community Edition ou Enterprise Edition, pour ton équipe, ton école ou tes projets personnels, tu es concerné.

Dans cet article de veille, on reprend l’histoire dans l’ordre : la série de failles regex qui a précédé, ce que fait cette faille GitLab (sans entrer dans l’exploitation), puis la correction et la procédure de mise à jour.

Chronologie de la faille GitLab

Le point clé de cette chronologie : beaucoup d’administrateurs ont mis à jour leur instance le 12 octobre et pensent être tranquilles. Ce n’est pas le cas. La faille GitLab du 21 octobre est distincte de celle du 12, et elle n’est corrigée que dans les versions publiées le 21.

En bref : la faille GitLab en chiffres

	CVE-2026-110264
Composant	Compilateur d’expressions régulières
Type	Dépassement d’entier (CWE-190) menant à une exécution de code
Gravité	Critique · CVSS 10.0
Authentification requise	Non
Éditions touchées	GitLab Community Edition et Enterprise Edition auto-hébergées
Versions touchées	Toutes depuis GitLab 7.0 (2014)
Découverte	Chercheur « joaxcar », programme de bug bounty HackerOne
Date de publication	21 octobre 2026

Le correctif fait partie d’une version qui corrige 12 vulnérabilités au total, dont deux autres de gravité haute : CVE-2026-15723 (CVSS 8.2) et CVE-2026-112212 (CVSS 7.5). Selon la Shadowserver Foundation, plus de 2 700 instances GitLab CE sont exposées directement sur Internet.

Ce que fait la faille GitLab : un dépassement d’entier dans les regex

GitLab utilise des expressions régulières un peu partout : règles de validation, fichiers de configuration, détection de contenus, pipelines CI/CD. Avant d’utiliser une regex, le moteur la compile : il la transforme en une structure interne qu’il pourra exécuter rapidement.

Selon le bulletin de GitLab, la compilation d’une expression régulière spécialement fabriquée peut provoquer un dépassement d’entier. Un calcul de taille dépasse la valeur maximale que peut contenir sa variable et « repart à zéro ». Le moteur réserve alors une zone mémoire trop petite, puis écrit au-delà. Dans les bonnes conditions, un attaquant peut en profiter pour exécuter son propre code sur le serveur, avec les droits de GitLab.

GitLab embarque sa propre version de Ruby dans ses paquets Omnibus et ses images Cloud Native, et le correctif touche la gestion des regex de Ruby 3.3, 3.4 et 4.0. Le moteur de regex intégré à Ruby s’appelle Onigmo. Le site IT-Connect relie la faille à ce moteur, sans que GitLab l’ait confirmé explicitement. GitLab n’a pas non plus détaillé les « certaines conditions » nécessaires à l’attaque.

Suis-je concerné par cette faille GitLab ?

• Tu utilises GitLab.com : rien à faire, l’instance est déjà corrigée.
• Tu es client GitLab Dedicated : protégé à partir des versions 19.3.5-internal0 et 19.4.2-internal0.
• Tu héberges GitLab toi-même (Omnibus, Docker, Helm) : tu es concerné, quelle que soit ta version, tant que tu n’as pas installé une version du 21 octobre ou plus récente.

Pour connaître ta version exacte, ouvre Aide → À propos de GitLab dans l’interface, ou lance cette commande sur le serveur :

# Installation Omnibus
sudo gitlab-rake gitlab:env:info | grep -A2 "GitLab information"

# Ou plus directement
cat /opt/gitlab/embedded/service/gitlab-rails/VERSION

# Installation Docker
docker exec -it gitlab cat /opt/gitlab/embedded/service/gitlab-rails/VERSION

Si tu es sur	Mets à jour vers
19.5 (avant 19.5.1)	19.5.1
19.4 (avant 19.4.3)	19.4.3
19.3 (avant 19.3.6)	19.3.6
19.2 (avant 19.2.9)	19.2.9
19.1 (avant 19.1.9)	19.1.9
19.0 (avant 19.0.10)	19.0.10
7.0 à 18.11 (avant 18.11.13)	18.11.13

Comment corriger la faille GitLab : mettre à jour

Installation Omnibus (Debian / Ubuntu)

# Sauvegarde d’abord
sudo gitlab-backup create

# Mise à jour vers la version corrigée de ta branche
sudo apt update
sudo apt install gitlab-ce=19.4.3-ce.0   # adapte l’édition et la version

# Vérification
sudo gitlab-rake gitlab:check SANITIZE=true

Installation Omnibus (RHEL / AlmaLinux / Rocky)

sudo gitlab-backup create
sudo dnf install gitlab-ee-19.5.1-ee.0.el9   # adapte l’édition et la version
sudo gitlab-ctl status

Docker

# docker-compose.yml : épingle une version corrigée
#   image: gitlab/gitlab-ce:19.5.1-ce.0

docker compose pull
docker compose up -d
docker exec -it gitlab gitlab-rake gitlab:check SANITIZE=true

Respecte aussi le chemin de mise à jour officiel de GitLab : si ton instance est très ancienne, tu ne peux pas sauter directement à la dernière version. Passe par les versions intermédiaires obligatoires, en terminant par 18.11.13 ou une version 19.x corrigée.

Pas de mise à jour possible tout de suite ? Les mesures temporaires

GitLab n’a publié aucune mesure de contournement pour cette faille GitLab : la mise à jour est la seule protection connue. En attendant, tu peux réduire l’exposition :

• Retirer l’instance d’Internet et la rendre accessible uniquement par VPN ou réseau privé.
• Restreindre l’accès par adresse IP au niveau du pare-feu ou du proxy inverse.
• Surveiller de près les journaux et l’activité des processus du serveur.

# Nginx devant GitLab : n’autoriser que ton réseau en attendant le correctif
location / {
    allow 10.0.0.0/8;
    allow 192.168.0.0/16;
    deny  all;
    proxy_pass http://gitlab;
}

Comprendre un dépassement d’entier en 2 minutes

Imagine un compteur kilométrique à six chiffres. Arrivé à 999 999, il repasse à 000 000 : la voiture a pourtant parcouru un million de kilomètres. En informatique, un entier stocké sur un nombre fixe de bits se comporte de la même façon. Si un calcul de taille dépasse la limite, le résultat devient minuscule.

Le programme croit alors avoir besoin d’une toute petite zone mémoire, la réserve, puis y copie beaucoup plus de données que prévu. Le surplus écrase la mémoire voisine. Si l’attaquant contrôle ce qui déborde, il peut parfois détourner l’exécution du programme. C’est exactement le scénario décrit pour cette faille GitLab.

Ce que cette faille GitLab nous apprend

Au-delà du correctif, cette faille GitLab illustre trois tendances de fond que tout développeur qui héberge ses propres outils devrait garder en tête.

1. Les composants embarqués sont une surface d’attaque à part entière. Le défaut ne se trouve pas dans le code métier de GitLab, mais dans la gestion des expressions régulières de la version de Ruby que GitLab embarque. Quand tu installes un logiciel « tout-en-un », tu installes aussi son langage, ses bibliothèques et ses moteurs internes. Leur sécurité dépend entièrement du rythme de mise à jour de l’éditeur, et donc de ta capacité à appliquer ses correctifs rapidement.

2. Une série de failles appelle d’autres failles. Quand un chercheur trouve une faille dans un composant, il est fréquent que d’autres suivent dans le même code : le chercheur connaît le terrain, et les autres équipes de sécurité s’y intéressent à leur tour. Trois correctifs critiques liés aux regex en un mois, c’est le signe qu’il faut rester particulièrement attentif aux prochains bulletins GitLab.

3. Un correctif ne vaut que s’il couvre la bonne faille. Le piège du 12 octobre est instructif : de nombreux administrateurs ont appliqué un correctif critique, puis ont considéré le sujet comme clos. Neuf jours plus tard, une nouvelle faille GitLab rendait ce correctif insuffisant. La bonne pratique consiste à vérifier chaque bulletin individuellement, en comparant ta version exacte aux versions corrigées annoncées, plutôt que de raisonner en « j’ai patché récemment ».

Pour une petite équipe, la question mérite d’être posée franchement : as-tu le temps et les compétences pour suivre ce rythme ? Si la réponse est non, une instance hébergée comme GitLab.com, déjà corrigée côté éditeur, est souvent plus sûre qu’un serveur auto-hébergé mis à jour une fois par trimestre. Si tu gardes ton instance, automatise au moins la surveillance des versions et la sauvegarde avant chaque mise à jour.

Checklist complète après la faille GitLab

• Vérifie la version de chaque instance : production, préproduction, instance de test, vieux serveur oublié.
• Mets à jour aussi les GitLab Runners lors de la même opération, pour garder des versions cohérentes.
• Fais tourner les secrets sensibles si ton instance était exposée sans correctif : jetons d’accès personnels, variables CI/CD, clés de déploiement.
• Relis les journaux (/var/log/gitlab/) à la recherche de requêtes ou de processus inhabituels.
• Abonne-toi aux annonces de sécurité de GitLab : trois correctifs critiques en un mois, ce rythme impose une veille régulière.

# État des services après la mise à jour
sudo gitlab-ctl status

# Rechercher des erreurs récentes côté Rails
sudo gitlab-ctl tail gitlab-rails | grep -i error

Faille GitLab : les erreurs à éviter

• Croire que le patch du 12 octobre suffit : 19.2.8, 19.3.5 et 19.4.2 restent vulnérables à CVE-2026-110264.
• Penser qu’une vieille version est « trop vieille pour être visée » : la faille GitLab remonte à la 7.0, et un correctif existe désormais en 18.11.13.
• Mettre à jour sans sauvegarde : une migration de base de données qui échoue sans sauvegarde peut coûter beaucoup plus cher que la faille.
• Oublier les instances internes : un réseau privé réduit le risque, il ne le supprime pas.

FAQ

J’utilise GitLab.com, dois-je faire quelque chose ?

Non. GitLab.com tourne déjà sur une version corrigée. Seules les instances auto-hébergées doivent être mises à jour.

J’ai mis à jour le 12 octobre, suis-je protégé ?

Non. Le correctif du 12 octobre traitait une autre faille (CVE-2026-97229). Les versions 19.2.8, 19.3.5 et 19.4.2 restent vulnérables à la faille GitLab CVE-2026-110264 : il faut installer les versions du 21 octobre.

La faille GitLab est-elle exploitée activement ?

Au 22 octobre 2026, GitLab ne signalait aucune exploitation, et la faille ne figurait pas au catalogue KEV de la CISA. Mais une faille GitLab précédente avait été ajoutée à ce catalogue dès le lendemain de son correctif : ne tarde pas.

Existe-t-il un contournement sans mise à jour ?

Non, GitLab n’en a publié aucun. Restreindre l’accès réseau réduit l’exposition en attendant, mais seule la mise à jour corrige la faille.

Et si tu utilises GitHub ou un autre outil ? Cette faille GitLab ne concerne que GitLab. GitHub, Gitea, Forgejo ou Bitbucket ne partagent pas ce code et ne sont pas touchés par CVE-2026-110264. En revanche, la leçon reste valable pour tous ces outils : dès qu’un service de gestion de code est auto-hébergé, ses mises à jour de sécurité deviennent ta responsabilité. Un dépôt Git contient souvent bien plus que du code : des fichiers de configuration, des secrets oubliés, des clés de déploiement et l’historique complet de ton projet.

Pourquoi un serveur Git est une cible de choix. Prendre le contrôle d’un serveur GitLab, c’est accéder au code source de tous les projets hébergés, aux variables CI/CD qui contiennent souvent des mots de passe de bases de données ou des jetons d’API, et aux pipelines qui déploient en production. Un attaquant peut y injecter du code malveillant qui sera ensuite déployé automatiquement. C’est ce qu’on appelle une attaque de la chaîne d’approvisionnement logicielle, et c’est pour ça qu’une faille GitLab notée 10 sur 10 se traite en priorité, avant presque tout le reste.

Comment rester informé. GitLab publie ses correctifs de sécurité sur son blog et via un flux RSS dédié aux versions. Abonne-toi à ce flux, ou suis notre rubrique Veille sécurité : chaque faille GitLab importante y est expliquée en français, avec les versions concernées et les commandes de mise à jour.

Enfin, documente ta procédure de mise à jour : la commande exacte, l’emplacement des sauvegardes et le temps d’indisponibilité prévu. La prochaine fois qu’une faille GitLab critique sera annoncée, tu pourras appliquer le correctif en quelques minutes au lieu de chercher les bonnes étapes dans l’urgence, un vendredi soir, avec ton équipe qui attend.

Faille GitLab : le résumé à retenir

• La faille GitLab CVE-2026-110264 est un dépassement d’entier lors de la compilation d’une regex, noté CVSS 10.0.
• Elle permet, dans certaines conditions, une exécution de code sans authentification sur GitLab CE et EE.
• Toutes les versions auto-hébergées depuis la 7.0 sont touchées. GitLab.com et Dedicated sont déjà protégés.
• Les versions corrigées sont 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 et 18.11.13, publiées le 21 octobre 2026.
• Le correctif du 12 octobre ne protège pas contre cette faille GitLab, et aucun contournement n’existe.

Si tu ne retiens qu’une chose de cette faille GitLab : un serveur auto-hébergé, c’est aussi la responsabilité de ses mises à jour. Traite la faille GitLab aujourd’hui et vérifie ta version à chaque bulletin.

Conclusion

Trois correctifs critiques en un mois, dont deux notés 10/10 : GitLab traverse une série de failles regex qui impose une vigilance particulière aux administrateurs. Mets à jour ton instance, même si tu l’as déjà fait le 12 octobre, et garde notre antisèche des commandes Git à portée de main pour tes projets. Le même jour, la faille Node.js Node2Shell et la faille critique PHP ont aussi été corrigées.

Sources

• NVD : CVE-2026-110264
• BleepingComputer : GitLab warns of new max severity code execution vulnerability
• IT-Connect : GitLab CVE-2026-110264, faille critique regex
• The Hacker News : Critical GitLab Flaw (CVSS 10.0)