GitLab corrige une faille RCE de sévérité maximale liée aux regex

Le 22 octobre 2026, Bleeping Computer a rapporté que GitLab venait de publier des correctifs pour une faille de sévérité maximale, référencée CVE-2026-110264. Cet article repose sur ce seul compte rendu, qui reprend le bulletin de l’éditeur. Les éléments ci-dessous sont donc à lire avec cette réserve.

Une faille dans le compilateur d’expressions régulières

D’après Bleeping Computer, la faille se situerait dans le compilateur d’expressions régulières de GitLab. Ce moteur d’arrière-plan analyse et valide les expressions régulières présentes dans les fichiers de configuration. En cause, un dépassement d’entier : un calcul produit une valeur trop grande pour la variable censée la contenir, et le programme peut alors manipuler la mémoire d’une manière que personne n’avait prévue.

Selon le bulletin cité, un utilisateur non authentifié pourrait, sous certaines conditions, exécuter du code arbitraire sur le serveur GitLab. Il lui suffirait de lui faire compiler une expression régulière spécialement conçue. Aucun compte n’est donc nécessaire, et c’est ce qui rend ce type de faille particulièrement sérieux pour une instance accessible depuis Internet.

La faille a été signalée par un chercheur en sécurité, par l’intermédiaire du programme de bug bounty de GitLab sur HackerOne.

Les versions qui contiennent le correctif

GitLab a corrigé la faille dans ses éditions Community (CE) et Enterprise (EE), aux versions 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 et 18.11.13. Si votre instance tourne sur l’une de ces branches avec un numéro inférieur, elle n’a pas le correctif. L’éditeur recommande de mettre à niveau vers la dernière version, dès que possible, toute installation qui fait tourner une version concernée.

Deux cas ne demandent aucune action. GitLab.com fonctionne déjà avec la version corrigée. Les locataires de GitLab Dedicated en 19.3.5-internal0, en 19.4.2-internal0 ou dans une version ultérieure disposent eux aussi déjà du correctif.

Pourquoi l’auto-hébergé ne peut pas attendre

Sur le service géré, la correction est faite. Sur une instance auto-hébergée, personne ne l’appliquera à votre place. L’organisme de veille Shadowserver recense plus de 2 700 instances GitLab Community Edition exposées en ligne. Il ne précise pas combien sont des pots de miel ou sont déjà protégées.

Un précédent récent pèse aussi. Le mois dernier, GitLab a corrigé CVE-2026-85706, une autre faille de sévérité maximale qui permettait à un attaquant non authentifié de lire des données sensibles sur le serveur, notamment des identifiants. Le lendemain, la CISA, l’agence américaine de cybersécurité, l’a ajoutée à sa liste des failles activement exploitées et a donné trois jours aux agences fédérales pour sécuriser leurs systèmes. Depuis novembre 2021, la CISA a signalé cinq failles GitLab exploitées, dont une lors d’attaques par rançongiciel. La source ne fait état d’aucune exploitation de CVE-2026-110264 à ce stade.

L’enjeu dépasse les petites forges. Selon Bleeping Computer, GitLab compte plus de 30 millions d’utilisateurs inscrits et équipe plus de la moitié des entreprises du classement Fortune 100.

Une faille voisine, dix jours plus tôt

Dix jours avant cette annonce, GitLab avertissait déjà ses clients d’une autre faille critique d’exécution de code à distance, CVE-2026-97229, notée 10 sur 10 en score CVSS de base. Elle touchait le compilateur d’expressions régulières de la CI/CD et avait été signalée par le même chercheur. Si vous avez installé ce correctif-là, vous n’êtes pas protégé pour autant contre CVE-2026-110264 : ce sont deux références distinctes, et chacune a ses propres versions correctives.

Le correctif est disponible. Sur une instance exposée, chaque jour de plus avant de l’installer est un jour de trop.