GitLab a publié le 21 octobre 2026 des correctifs pour CVE-2026-110264, une faille notée 10 sur 10 qui pourrait permettre à un attaquant sans compte d’exécuter du code sur un serveur GitLab auto-hébergé. Toutes les branches encore maintenues reçoivent une version corrigée, et l’avis de l’éditeur ne mentionne aucune solution de contournement : il recommande fortement la mise à jour immédiate. Voici qui est concerné, quelle version installer et quoi vérifier ensuite.
Une faille maximale, la deuxième en dix jours
D’après l’avis de sécurité de GitLab, le problème est un dépassement d’entier dans le compilateur d’expressions régulières. Un utilisateur non authentifié pourrait s’en servir pour faire tourner son propre code sur la machine qui héberge l’instance. La note CVSS de 10,0 est la plus haute possible.
Ce n’est pas un incident isolé. BleepingComputer rappelle que le même chercheur, connu sous le pseudonyme « joaxcar » et passé par le programme de primes de GitLab sur HackerOne, avait déjà signalé une dizaine de jours plus tôt CVE-2026-97229, elle aussi notée 10, dans le traitement des expressions régulières de l’intégration continue. Selon The Hacker News, quatre failles critiques de GitLab découlent en réalité de trois bugs du moteur Onigmo, celui qu’utilise le langage Ruby, sur lequel repose GitLab. Le même média indique que la nouvelle faille touche toutes les versions depuis GitLab 7.0.
Qui est concerné, et qui ne l’est pas
Seules les installations que vous gérez vous-même, éditions Community (CE) et Enterprise (EE), sont à risque. GitLab précise que GitLab.com est déjà corrigé. Les clients de GitLab Dedicated sont protégés dès lors que leur environnement tourne en 19.3.5-internal0, 19.4.2-internal0 ou plus récent.
L’exposition est réelle : BleepingComputer cite les relevés de la fondation Shadowserver, qui recensent plus de 2 700 instances GitLab CE accessibles depuis Internet, sans savoir combien sont des leurres ou sont déjà à jour. Au 23 octobre, selon The Hacker News, aucune des quatre failles liées à Onigmo ne figurait au catalogue des vulnérabilités exploitées de l’agence américaine CISA. Mais une autre faille de gravité maximale, CVE-2026-85706, y a été ajoutée un jour seulement après sa publication par GitLab, rapporte BleepingComputer, qui ajoute que la CISA a classé cinq failles GitLab comme exploitées depuis novembre 2021.
Quelle version installer
GitLab a publié sept versions corrigées. Repérez votre branche et passez à la version correspondante :
- branche 19.5 : 19.5.1 ;
- branche 19.4 : 19.4.3 ;
- branche 19.3 : 19.3.6 ;
- branches 19.2, 19.1 et 19.0 : 19.2.9, 19.1.9 et 19.0.10 ;
- branche 18.11 : 18.11.13.
Point important : si vous avez appliqué en hâte le correctif du 12 octobre, vous n’êtes pas à l’abri pour autant. Il faut installer ce nouveau palier. L’avis signale aussi que les versions 19.4.3 et 19.3.6 contiennent des migrations de base de données : une instance sur un seul nœud subira une coupure pendant l’opération, alors qu’une architecture à plusieurs nœuds peut être mise à jour sans interruption. Prévenez vos équipes de développement avant de lancer la manœuvre.
Après la mise à jour : chercher des traces et vérifier ses réglages
GitLab fournit deux règles de détection destinées aux instances auto-hébergées, l’une sur les plantages du processus natif Onigmo, l’autre sur des rafales d’erreurs de rendu de fichiers au format Org. Si votre serveur était exposé avant le correctif, passez vos journaux au crible avec ces deux signaux.
Le même lot corrige onze autres failles, dont deux classées élevées : l’une concerne la liaison automatique de comptes entre SAML et LDAP, l’autre l’empoisonnement du cache des documents de découverte OAuth et OIDC. Si vous utilisez ces mécanismes d’authentification, relisez leur configuration une fois la mise à jour faite.
Enfin, le problème ne concerne pas que GitLab. The Hacker News rapporte que Ruby a publié les versions 4.0.9, 3.4.12 et 3.3.13 pour corriger les bugs d’Onigmo, la branche 3.2 restant sans correctif car elle n’est plus maintenue. Toute application Ruby qui construit une expression régulière à partir d’une saisie extérieure est exposée ; limiter la longueur des motifs ne suffit pas, puisque des motifs courts peuvent aussi déclencher le bug.
Questions fréquentes
J’utilise GitLab.com, dois-je faire quelque chose ?
Non. GitLab indique que sa plateforme en ligne est déjà corrigée. Seules les instances installées sur vos propres serveurs doivent être mises à jour.
Existe-t-il une parade temporaire si je ne peux pas mettre à jour tout de suite ?
L’avis de GitLab n’en mentionne aucune et recommande de mettre à jour au plus vite. Pour les applications Ruby, The Hacker News indique qu’à défaut de mise à jour il faut cesser de compiler des expressions régulières issues de saisies non fiables.
J’ai déjà installé le correctif du 12 octobre, suis-je protégé ?
Non. Ce correctif traitait CVE-2026-97229. Pour CVE-2026-110264, il faut passer aux versions publiées le 21 octobre, par exemple 19.4.3 ou 19.5.1.
Sources
- GitLab Critical Patch Release: 19.5.1, 19.4.3, 19.3.6 — GitLab, 2026-10-21
- GitLab warns of new max severity code execution vulnerability — BleepingComputer, 2026-10-22
- Ruby Fixes Three Regex Engine Bugs Responsible for Four Critical GitLab RCE Flaws — The Hacker News, 2026-10-23