GitLab : RCE sans authentification sur 12 ans de versions (CVE-2026-110264)

En bref

• CVE-2026-110264 est un dépassement d’entier dans le compilateur d’expressions régulières de GitLab autogéré, auquel GitLab attribue le score maximal CVSS v3.1 de 10.0. Sous des conditions non divulguées par GitLab, un attaquant non authentifié peut exécuter du code arbitraire sur le serveur en fournissant une expression régulière spécialement conçue.
• Toutes les versions autogérées de GitLab CE/EE depuis 7.0 (2014) sont affectées, car la faille se trouve dans Onigmo, le moteur d’expressions régulières de Ruby que GitLab fournit et corrige dans ses propres packages. GitLab a corrigé sept branches simultanément le 21 octobre 2026, en rétroportant au-delà de sa politique habituelle.
• Aucune exploitation n’a été signalée et la faille ne figure pas dans le catalogue CISA KEV. Aucune preuve de concept n’est publique, et GitLab n’a publié aucune solution de contournement : les prérequis n’étant pas divulgués, aucune configuration ne permet d’exclure une instance du périmètre affecté. La mise à jour est donc la seule protection certaine.
• Mettez immédiatement à jour vers 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 ou 18.11.13. Si vous avez appliqué le correctif du 12 octobre pour CVE-2026-97229, vous êtes de nouveau concerné : ces builds se trouvent un niveau de correctif sous les nouvelles versions corrigées.

Suis-je concerné ?

Vous êtes concerné si ces deux conditions sont réunies :

• Vous utilisez GitLab Community Edition ou Enterprise Edition autogéré, quel que soit le type de déploiement : packages omnibus, Docker, charts Helm ou installations depuis les sources. GitLab.com utilise déjà une version corrigée, et les tenants GitLab Dedicated en 19.3.5-internal0 et 19.4.2-internal0 ou ultérieures n’ont aucune action à effectuer.
• Votre version se trouve dans une plage affectée. GitLab n’a pas précisé les fonctionnalités ou paramètres nécessaires à l’attaquant : aucune instance antérieure aux versions corrigées ne peut donc être exclue en fonction de sa configuration.

Vérifiez la version de chaque instance, y compris les serveurs de préproduction et ceux réservés à la CI. Dans l’interface web, elle apparaît sous Help et dans la vue d’ensemble de l’Admin Area. Sur l’hôte :

cat /opt/gitlab/embedded/service/gitlab-rails/VERSION        # omnibus package install
docker exec gitlab cat /opt/gitlab/embedded/service/gitlab-rails/VERSION   # Docker: adjust the container name
cat /home/git/gitlab/VERSION                                  # source install

Les instances exécutant 19.2.8, 19.3.5 ou 19.4.2, les correctifs du 12 octobre pour CVE-2026-97229, se trouvent dans les plages affectées et doivent passer au correctif suivant.

Comment corriger le problème ?

Passez à la version corrigée de votre branche, en suivant le parcours de mise à niveau documenté par GitLab pour les anciennes instances. Quatre des sept versions corrigées, 18.11.13, 19.0.10, 19.1.9 et 19.2.9, sont des rétroportages réservés par GitLab aux problèmes graves ; sa politique normale ne couvre que les trois versions mensuelles les plus récentes.

Prévoyez la fenêtre de mise à jour. Les versions 19.4.3 et 19.3.6 incluent des migrations de base de données exécutées pendant la mise à niveau. Un serveur à un seul nœud reste donc indisponible jusqu’à leur fin ; les installations multinœuds peuvent appliquer le correctif sans interruption avec la procédure de mise à niveau sans arrêt de GitLab. La version 19.4.3 exécute aussi des migrations après déploiement.

Aucune solution de contournement n’est publiée, et les limites d’une mesure improvisée doivent être claires : GitLab n’a pas divulgué les prérequis, donc restreindre les fonctionnalités, les inscriptions ou l’usage de la CI ne constitue pas une défense documentée. Limiter au niveau réseau les personnes pouvant atteindre l’instance réduit l’exposition, mais n’est pas une correction garantie par GitLab. La protection est la mise à jour.

La même publication du 21 octobre corrige 10 autres problèmes, dont deux de sévérité élevée : CVE-2026-15723, une prise de contrôle de compte via la recherche d’e-mail pour l’association automatique OmniAuth-vers-LDAP lorsque les associations automatiques SAML et LDAP sont toutes deux activées, et CVE-2026-112212, un empoisonnement du cache des endpoints de découverte OAuth et OpenID Connect. Une seule mise à jour les couvre tous.

Quelle est la cause racine ?

GitLab compile des expressions régulières fournies par ses utilisateurs. Son moteur, Onigmo, comptait deux types d’identifiants internes avec des compteurs non bornés : un motif contenant suffisamment de constructions de répétition faisait déborder les identifiants et corrompait le programme compilé.

GitLab est une application Ruby on Rails, et le moteur d’expressions régulières intégré de Ruby est Onigmo, une bibliothèque C. GitLab n’utilise pas le Ruby du système : il embarque son propre Ruby, corrigé dans ses propres packages. C’est pourquoi une faiblesse d’Onigmo se retrouve dans toutes les versions de GitLab depuis 7.0 et pourquoi GitLab distribue le correctif en modifiant le Ruby qu’il fournit.

Le bulletin de Ruby nomme précisément le bug à l’origine de CVE-2026-110264 : « dépassement des identifiants internes dans un motif comportant de nombreuses répétitions ». Le correctif, intégré en amont dans la pull request ruby/ruby #16801, « Reject overflowed repeat/null-check IDs in huge regexps », montre le mécanisme en deux lignes. Lorsqu’Onigmo compile une répétition bornée telle que (?:foobar){0,100}, il émet une paire d’instructions de machine virtuelle qui nécessitent un identifiant numérique :

   r = add_mem_num(reg, num_repeat); /* OP_REPEAT ID */
   reg->num_repeat++;
+  if ((MemNumType)reg->num_repeat <= 0) return ONIGERR_TOO_MANY_RANGE_REPEAT;

La ligne ajoutée est la vérification qui manquait. L’identifiant est stocké comme un MemNumType, qu’Onigmo définit comme short int, un entier signé sur 16 bits d’une valeur maximale de 32 767. Avant le correctif, reg->num_repeat était incrémenté indéfiniment sans comparaison avec cette limite. Lorsque le compteur dépassait 32,767, la valeur écrite comme identifiant devenait négative par débordement. La nouvelle vérification convertit le compteur en MemNumType et arrête la compilation dès que la valeur convertie est nulle ou négative, avant qu’un identifiant ayant débordé n’atteigne le programme compilé. La même lacune existait pour les identifiants de vérification de correspondance vide qu’Onigmo attribue lorsqu’il compile des constructions à contrôler pour les correspondances vides :

     r = add_mem_num(reg, reg->num_null_check); /* NULL CHECK ID */
     if (r) return r;
     reg->num_null_check++;
+    if ((MemNumType)reg->num_null_check <= 0) return ONIGERR_TOO_MANY_NULL_CHECK;

Un motif spécialement conçu contenant un très grand nombre de ces constructions pousse les compteurs au-delà de la plage des identifiants ; les valeurs stockées débordent et entrent en collision dans le programme compilé. Les tests de non-régression ajoutés avec le correctif montrent les deux formes de déclenchement, chacune répétée 100 000 fois dans un même motif :

'(?:foobar){0,100}' * 100000          # range repeats
'(?:(?:foo)?|(?:bar)?)*' * 100000     # constructs needing null checks

Le bulletin de GitLab indique que ce dépassement d’entier, atteint lors de la compilation d’un tel motif, peut être transformé en exécution de code arbitraire sur le serveur. Le chercheur Johan Carlsson, connu sous le pseudonyme joaxcar, a signalé la faille via le programme de bug bounty HackerOne de GitLab. C’est sa quatrième faille d’exécution de code dans le moteur d’expressions régulières de GitLab en un mois, et la première qui touche des versions antérieures à 19.2.

Comment la faille est-elle exploitée ?

Aucun code d’exploit n’est public. Les étapes ci-dessous suivent donc le bulletin, le correctif en amont et la description du chemin d’entrée par Ruby, plutôt qu’une preuve de concept publiée.

1. L’attaquant fournit une expression régulière spécialement conçue à une fonctionnalité GitLab qui compile des motifs fournis par les utilisateurs. GitLab compile notamment les motifs de configuration CI, mais n’a pas divulgué quelles fonctionnalités atteignent ce bug.
2. Le motif est généré, pas saisi à la main : il répète une construction quantifiée des dizaines de milliers de fois, comme les deux formes présentes dans les tests de non-régression.
3. Pendant la compilation, les compteurs d’identifiants de répétition et de vérification de correspondance vide dépassent la plage de MemNumType et débordent. Le programme compilé contient donc des identifiants en collision.
4. L’état de compilation corrompu entraîne une corruption mémoire que GitLab indique pouvoir transformer en exécution de code sous l’identité du processus serveur GitLab.

Les traces observables d’échecs ou de tentatives d’exploitation font l’objet de deux règles de détection publiées par GitLab, toutes deux dans son framework de détection open source TLDR, écrites au format Sigma pour les journaux applicatifs GitLab.

Quel est le déroulement de l’attaque ?

Le chemin est court : un motif généré automatiquement et rempli de répétitions atteint le compilateur, ses identifiants débordent, puis le programme corrompu fait planter le worker ou permet à l’attaquant de prendre le contrôle de l’exécution.

Que peut faire un attaquant ?

• Exécuter du code arbitraire sur le serveur GitLab sous l’identité du processus GitLab, sans authentification. Le vecteur CVSS indique une portée modifiée, ce qui signifie que le score tient compte d’un impact au-delà du composant vulnérable lui-même.
• Atteindre tout ce qui est accessible au processus GitLab : dépôts et historique, variables CI/CD et autres secrets stockés, registres de conteneurs et de packages, et hôte exécutant l’instance.
• Progresser latéralement via la CI : les runners exécutent les tâches définies dans l’instance affectée. Une exécution de code côté serveur peut donc influencer les charges de travail et les machines qui lui font confiance.

Conditions nécessaires à l’attaquant : accès réseau à l’interface web GitLab et prérequis non divulgués. Aucune authentification n’est requise selon le vecteur CVSS, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, et aucune interaction utilisateur n’est indiquée. Les prérequis n’étant pas publiés, toute instance autogérée accessible depuis Internet doit être considérée comme exposée.

Pourquoi le correctif fonctionne-t-il ?

La pull request Ruby #16801 ferme le dépassement des deux compteurs. Après chaque incrément, le nouveau code convertit le compteur en MemNumType et renvoie une erreur bloquante si la valeur a débordé :

/* regcomp.c, compile_range_repeat_node() */
if ((MemNumType)reg->num_repeat <= 0) return ONIGERR_TOO_MANY_RANGE_REPEAT;

/* regcomp.c, compile_tree_empty_check() */
if ((MemNumType)reg->num_null_check <= 0) return ONIGERR_TOO_MANY_NULL_CHECK;

Deux nouveaux codes d’erreur, ONIGERR_TOO_MANY_RANGE_REPEAT (-224) et ONIGERR_TOO_MANY_NULL_CHECK (-225), avec des messages dans regerror.c, font qu’un motif dont les identifiants déborderaient est désormais rejeté avec une RegexpError avant que le programme compilé n’existe. Les identifiants en collision ne peuvent plus être produits, ce qui ferme le chemin de corruption. Le correctif est complet pour cette faille et inclut des tests de non-régression pour les deux formes de déclenchement.

Le déploiement mérite l’attention. Le correctif en amont a été intégré à ruby/ruby le 29 avril 2026, mais aucune version Ruby ne l’a inclus avant le 23 octobre 2026 : Ruby 4.0.9, 3.4.12 et 3.3.13, que le bulletin confirme comme premières versions corrigées de leurs séries. Ruby 4.0.8 ne contient explicitement pas ce correctif. GitLab n’a pas attendu : ses packages du 21 octobre incluent leur propre rétroportage, que les notes de version décrivent comme « Add Ruby regexp repeat ID overflow patch for 3.3, 3.4 and 4.0 » dans les builds 19.2 à 19.5, en plus du correctif antérieur des plages de répétition qui atteint les branches plus anciennes. Installer une version corrigée de GitLab applique la correction via le Ruby embarqué.

Comment vérifier si j’ai été compromis ?

Aucune exploitation de CVE-2026-110264 n’a été signalée et aucun indicateur de compromission n’existe. GitLab et le catalogue de CISA n’indiquent aucune activité réelle au 25 octobre 2026.

En attendant de nouveaux éléments, les défenseurs disposent de deux règles de détection publiées et d’une surveillance générale :

• Les règles Sigma de GitLab, Onigmo native worker crash et Org mode render error burst, s’appliquent aux journaux applicatifs de GitLab et constituent la méthode prise en charge par l’éditeur pour rechercher des tentatives d’exploitation.
• De manière générale, des séries de plantages de workers Ruby liés à la compilation de motifs, des rafales d’erreurs de rendu Org mode et des processus enfants ou connexions sortantes inattendus depuis le compte de service GitLab sont les signaux qu’une exploitation réussie ou tentée laisserait. Traitez un tel résultat comme un incident d’exécution de code : isolez, prenez un instantané, renouvelez les secrets détenus par l’instance et reconstruisez-la depuis une installation propre.

Chronologie

• 2026-04-29 : le correctif, pull request ruby/ruby #16801, « Reject overflowed repeat/null-check IDs in huge regexps », est intégré en amont.
• 2026-09-23 : GitLab corrige dans 19.4.1 les deux premières failles de moteur d’expressions régulières de joaxcar, CVE-2026-89078 et CVE-2026-93577, toutes deux notées 9.9 et nécessitant un compte.
• 2026-10-12 : GitLab corrige CVE-2026-97229, un dépassement du compilateur d’expressions régulières sans authentification noté 10.0, dans 19.2.8, 19.3.5 et 19.4.2.
• 2026-10-21 : GitLab corrige CVE-2026-110264 dans 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 et 18.11.13, avec des rétroportages au-delà de sa politique habituelle.
• 2026-10-22 : CVE-2026-110264 est publiée avec le score CVSS v3.1 de 10.0.
• 2026-10-23 : Ruby publie 4.0.9, 3.4.12 et 3.3.13 avec les correctifs Onigmo sous-jacents et son bulletin identifiant le bug associé à chaque CVE GitLab.
• 2026-10-25 : publication de cet article.

FAQ

J’ai appliqué le correctif du 12 octobre pour CVE-2026-97229. Suis-je protégé ?

Non. Les builds du 12 octobre, 19.2.8, 19.3.5 et 19.4.2, se trouvent dans les plages affectées de CVE-2026-110264, dont les versions corrigées sont un niveau au-dessus : 19.2.9, 19.3.6 et 19.4.3. La faille précédente s’arrêtait à 19.2 ; celle-ci non. Chaque instance autogérée a donc besoin de la publication du 21 octobre, quels que soient les correctifs déjà appliqués.

GitLab.com ou GitLab Dedicated sont-ils affectés ?

Non. GitLab.com utilise déjà une version corrigée, et les tenants GitLab Dedicated sur les versions internes 19.3.5-internal0 et 19.4.2-internal0 ou ultérieures incluent déjà le correctif. L’exposition concerne les installations CE et EE autogérées de tout type de déploiement.

De quelles fonctionnalités GitLab l’attaquant a-t-il besoin ?

GitLab n’a pas divulgué les prérequis : aucune méthode documentée ne permet donc d’exclure une instance en fonction de sa configuration. GitLab compile les expressions régulières fournies par ses utilisateurs, comme les motifs de configuration CI, et les règles de détection publiées surveillent les plantages de workers Onigmo et les rafales d’erreurs de rendu Org mode. Considérez toute instance autogérée accessible depuis Internet comme exposée jusqu’à sa mise à jour.

Regexp.timeout ou une limite de longueur des motifs protègent-ils mes propres applications Ruby ?

Non. Le bulletin de Ruby indique que Regexp.timeout ne protège pas contre ces bugs et que les limites de longueur ne sont pas fiables, car des motifs courts peuvent en déclencher certains. Les applications qui compilent des chaînes contrôlées par un attaquant avec Regexp.new, Regexp.union, Regexp.compile ou une interpolation dans un littéral d’expression régulière doivent mettre Ruby à jour et cesser de compiler des motifs non fiables.

Un scanner CVE signalera-t-il les installations Ruby vulnérables ?

Pas via un identifiant CVE Ruby : Ruby n’en a pas demandé, du moins pour l’instant, et recommande de suivre les quatre numéros CVE de GitLab, dont les fiches ne citent que GitLab comme produit affecté. Suivez plutôt Ruby par version : 4.0.9, 3.4.12 et 3.3.13 sont corrigées, Ruby 4.0.8 ne contient pas le correctif de CVE-2026-110264, et Ruby 3.2 et antérieurs sont en fin de vie sans correctif.

Quel est le coût de la mise à jour sur un serveur à un seul nœud ?

Les versions 19.4.3 et 19.3.6 incluent des migrations de base de données qui doivent se terminer avant le démarrage de GitLab, ce qui impose une indisponibilité sur une installation à un seul nœud. Les installations multinœuds peuvent appliquer le correctif avec la procédure sans interruption de GitLab, et 19.4.3 exécute en plus des migrations après déploiement.

Repérez les instances GitLab non corrigées avant les attaquants

Scannez vos actifs externes et vos images de conteneurs avec Ostorlab pour repérer chaque instance GitLab autogérée de votre parc encore sur une version antérieure aux publications du 21 octobre 2026, y compris les serveurs de préproduction et ceux réservés à la CI qui reçoivent rarement de l’attention.

Références

• Publication des correctifs critiques GitLab 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 et 18.11.13, 21 octobre 2026, avec la description de CVE-2026-110264, le vecteur CVSS 10.0, les plages affectées, la note de rétroportage, l’attribution à joaxcar, les liens de détection et les avertissements de migration : https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-5-1-released/ (consultée le 25 octobre 2026)
• Fiche CVE-2026-110264 avec les plages de versions affectées et la référence au rapport HackerOne : https://cveawg.mitre.org/api/cve/CVE-2026-110264 (consultée le 25 octobre 2026)
• Bulletin Ruby, « Regexp compilation fixes related to GitLab’s CVE-2026-89078, CVE-2026-93577, CVE-2026-97229 and CVE-2026-110264 », 23 octobre 2026, avec le tableau des bugs par CVE, la définition des entrées affectées, les limites des mesures de contournement et les attributions : https://www.ruby-lang.org/en/news/2026/10/23/regexp-fixes-for-gitlab-cves/ (consulté le 25 octobre 2026)
• Pull request ruby/ruby #16801, « Reject overflowed repeat/null-check IDs in huge regexps », intégrée le 29 avril 2026, avec les deux vérifications de compteurs, les nouveaux codes d’erreur et les tests de non-régression : https://github.com/ruby/ruby/pull/16801 (consultée le 25 octobre 2026)
• Version Ruby 4.0.9, 23 octobre 2026, première version 4.0 contenant le correctif de CVE-2026-110264 : https://www.ruby-lang.org/en/news/2026/10/23/ruby-4-0-9-released/ (consultée le 25 octobre 2026)
• Versions Ruby 3.4.12 et 3.3.13, 23 octobre 2026 : https://www.ruby-lang.org/en/news/2026/10/23/ruby-3-4-12-released/ et https://www.ruby-lang.org/en/news/2026/10/23/ruby-3-3-13-released/ (consultées le 25 octobre 2026)
• Merge request omnibus GitLab ajoutant le correctif Ruby de dépassement des identifiants de répétition au build 19.5, depuis la liste de corrections de la version : https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/9922 (consultée le 25 octobre 2026)
• Règle de détection GitLab « Onigmo native worker crash », au format Sigma, dans le framework TLDR : https://gitlab.com/gitlab-security-oss/tldr/-/blob/main/Detections/platforms/GitLab/Vulnerability%20Detections/onigmo_native_worker_crash.md (consultée le 25 octobre 2026)
• Règle de détection GitLab « Org mode render error burst », au format Sigma, dans le framework TLDR : https://gitlab.com/gitlab-security-oss/tldr/-/blob/main/Detections/platforms/GitLab/Vulnerability%20Detections/org_mode_render_error_burst.md (consultée le 25 octobre 2026)
• Rapport HackerOne pour CVE-2026-110264, référence 4093475 : https://hackerone.com/reports/4093475 (référencé dans la fiche CVE, consulté le 25 octobre 2026)
• The Hacker News, « Critical GitLab Flaw (CVSS 10.0) Could Allow Unauthenticated RCE Across 12 Years of Releases », 21 octobre 2026, avec la matrice des versions corrigées, la nouvelle exposition des installations corrigées le 12 octobre et les détails de l’interruption de mise à jour : https://thehackernews.com/2026/10/critical-gitlab-flaw-cvss-100-could.html (consulté le 25 octobre 2026)
• The Hacker News, « Ruby Fixes Three Regex Engine Bugs Responsible for Four Critical GitLab RCE Flaws », 23 octobre 2026 : https://thehackernews.com/2026/10/ruby-fixes-three-regex-engine-bugs.html (consulté le 25 octobre 2026)
• CVE-2026-97229, faille associée du 12 octobre corrigée dans 19.2.8, 19.3.5 et 19.4.2 : https://www.cve.org/CVERecord?id=CVE-2026-97229 (consultée le 25 octobre 2026)
• Documentation GitLab sur les mises à jour sans interruption : https://docs.gitlab.com/update/zero_downtime/ (consultée le 25 octobre 2026)
• Parcours de mise à niveau GitLab pour les anciennes versions : https://docs.gitlab.com/update/ (consultés le 25 octobre 2026)
• Catalogue CISA Known Exploited Vulnerabilities, consulté pour ces CVE le 25 octobre 2026 (absentes) : https://www.cisa.gov/known-exploited-vulnerabilities-catalog