
10 sur 10. C’est une belle note. Mais quand il s’agit du score CVSS d’une faille de sécurité, c’est gênant. Il correspond à une faille de sécurité critique (CVE-20026-97229) que GitLab vient de corriger dans le compilateur d’expressions régulières de sa CI/CD. Elle pourrait permettre à un attaquant non authentifié d’exécuter du code sur le serveur. Voici comment se protéger.
Le 12 octobre 2026, GitLab a publié un patch critique pour GitLab Community Edition (CE) et Enterprise Edition (EE), sous la forme de trois nouvelles versions : 19.4.2, 19.3.5 et 19.2.8. Mais au-delà de cette faille critique, cette mise à jour corrige au total 24 vulnérabilités : 5 avec une sévérité élevée, 14 avec une sévérité moyenne et 4 de sévérité faible.
Concernant la faille critique, associée à la référence CVE-2026-97229, c’est un dépassement d’entier (integer overflow) dans le compilateur d’expressions régulières de GitLab CI/CD : le composant qui traite les regex de la configuration des pipelines, par exemple pour conditionner un job au nom d’une branche.
“GitLab a corrigé un problème qui, sous certaines conditions, aurait pu permettre à un utilisateur non authentifié d’exécuter du code arbitraire sur le serveur GitLab via une expression régulière spécialement conçue dans une configuration CI/CD, en raison d’une validation insuffisante des expressions régulières”, peut-on lire dans le bulletin de sécurité. Et cette faille a tout du jackpot pour les cybercriminels : exploitation à distance, faible complexité, aucun privilège requis, aucune interaction de l’utilisateur. Il vaut mieux patcher.
Toutefois, même si l’utilisateur n’a pas besoin d’être authentifié (ce qui peut étonner), GitLab précise que la faille est exploitable sous certaines conditions, sans préciser lesquelles.
Trois failles critiques dans le moteur regex en trois semaines
Cette vulnérabilité a été signalée par le chercheur joaxcar, via le programme de bug bounty de GitLab sur HackerOne. Et ce n’est pas sa première trouvaille sur ce terrain. Le 23 septembre 2026, GitLab avait déjà publié les versions 19.4.1, 19.3.3 et 19.2.7 pour corriger deux failles critiques signalées par le même chercheur :
CVE-2026-93577 : un dépassement d’entier lors de la compilation d’une regex piégée dans une configuration CI/CD.
CVE-2026-89078 : une double free lors de l’analyse d’une regex piégée, elle aussi dans une configuration CI/CD.
Il y a tout de même une différence notable entre la CVE-2026-97229 et ces deux vulnérabilités : elles nécessitaient d’être authentifié.
Quelles versions de GitLab sont concernées ?
La faille CVE-2026-97229 affecte GitLab CE et EE dans les versions suivantes :
GitLab 19.2 : toutes les versions antérieures à 19.2.8.
GitLab 19.3 : toutes les versions antérieures à 19.3.5.
GitLab 19.4 : toutes les versions antérieures à 19.4.2.
Donc, une instance passée en 19.4.1 fin septembre reste vulnérable ! Côté SaaS, GitLab.com tourne déjà sur une version corrigée et les clients GitLab Dedicated n’ont aucune action à effectuer. Pour les instances auto-hébergées, là c’est une autre histoire : la mise à jour est la seule option. “Nous recommandons vivement que toutes les installations GitLab auto-gérées soient mises à jour vers l’une de ces versions immédiatement”, insiste GitLab. Consultez cette page de la doc si vous avez besoin d’aide.
Il est vraiment recommandé de patcher vos instances GitLab. Ceci est d’autant plus vrai que des failles récentes ont été rapidement exploitées et ajoutées au catalogue KEV de la CISA.
Cofondateur d’IT-Connect et Microsoft MVP “Cloud and Datacenter Management”. Mon obsession depuis près de 15 ans ? Rendre l’administration système et la cybersécurité accessibles, que vous soyez junior ou confirmé. Plus qu’un métier, l’IT est pour moi une véritable passion. J’accompagne au quotidien les sysadmins et les professionnels de l’IT dans leur montée en compétences et leur veille technique.
