Plus de 1 000 serveurs GitLab accessibles depuis Internet resteraient vulnérables à une faille critique permettant l’exécution de code à distance. Référencée sous le numéro CVE-2026-97229, cette vulnérabilité a reçu la note maximale de 10 sur 10. Elle touche certaines versions auto-hébergées de GitLab Community Edition et Enterprise Edition et fait désormais l’objet d’attaques actives.
Pourquoi cette faille GitLab est-elle critique ?
Le problème se trouve dans le traitement des expressions régulières utilisées par les configurations CI/CD. Une expression spécialement conçue peut déclencher un dépassement d’entier dans le compilateur d’expressions régulières de Ruby, après avoir franchi les contrôles de validation de GitLab. Dans certaines conditions, l’attaquant peut détourner ce comportement pour exécuter une commande sur le système hébergeant GitLab.
L’impact est particulièrement grave : une compromission du serveur GitLab peut exposer du code source, des variables CI/CD, des jetons d’accès, des clés de déploiement et des secrets utilisés par les pipelines. Elle peut aussi permettre de modifier des dépôts ou de transformer l’infrastructure de développement en point d’entrée vers d’autres systèmes.
Quelles versions de GitLab sont vulnérables ?
GitLab a publié les premiers correctifs le 12 octobre 2026. Les branches touchées et leurs versions minimales corrigées sont :
- 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.
Ces numéros représentent les premiers correctifs de CVE-2026-97229. Les administrateurs doivent toutefois installer la version de sécurité la plus récente de leur branche, car GitLab a depuis corrigé une autre faille critique du même composant, CVE-2026-110264. Les versions plus récentes comprennent notamment 19.5.1, 19.4.3, 19.3.6 et 19.2.9.
GitLab.com avait déjà été corrigé avant la publication, et les environnements GitLab Dedicated ont reçu un correctif interne. L’urgence concerne donc principalement les installations GitLab Self-Managed.
Plus de 1 000 serveurs encore exposés
La fondation Shadowserver indique suivre quotidiennement environ 39 000 instances GitLab. Au 1er novembre, plus de 1 000 installations apparaissaient toujours vulnérables à CVE-2026-97229. En parallèle, plus de 11 300 serveurs restaient exposés à CVE-2026-110264, une faille distincte affectant elle aussi le compilateur d’expressions régulières.
La CISA américaine a ajouté CVE-2026-97229 à son catalogue des vulnérabilités activement exploitées le 29 octobre. Un code de démonstration public existe et un module Metasploit a également été publié, ce qui réduit fortement la difficulté d’exploitation pour des attaquants opportunistes.
Comment réduire le risque immédiatement ?
- Identifier la version réellement exécutée sur chaque instance GitLab auto-hébergée.
- Installer immédiatement la dernière version de sécurité compatible, pas uniquement le premier correctif d’octobre.
- Limiter l’accès Internet à GitLab si une mise à jour immédiate est impossible.
- Restreindre temporairement la création et l’écriture dans les projets publics par des utilisateurs non fiables.
- Surveiller les appels inhabituels aux fonctions CI Lint, les expressions régulières volumineuses et les arrêts anormaux des processus GitLab.
- Examiner les processus enfants lancés par GitLab et toute commande exécutée sous le compte système
git.
Que faire en cas de suspicion de compromission ?
Une mise à jour ferme la vulnérabilité mais ne supprime pas un accès déjà obtenu. Si le serveur a été exposé pendant la période d’exploitation, il faut conserver les journaux, rechercher les créations de comptes ou clés inconnues et vérifier l’intégrité des dépôts. Les secrets CI/CD, jetons d’accès personnels, clés de déploiement, identifiants de runners et mots de passe lisibles par GitLab doivent être renouvelés selon le niveau de risque.
Les entreprises devraient aussi vérifier les systèmes reliés aux pipelines. Un attaquant qui récupère un secret de déploiement peut parfois atteindre l’environnement cloud ou de production même après la correction du serveur GitLab.
L’essentiel à retenir
CVE-2026-97229 n’est plus une vulnérabilité théorique. Elle est publiquement documentée, exploitable et recensée par la CISA comme activement utilisée. Pour les instances GitLab auto-hébergées, la priorité est donc de passer à la dernière version de sécurité disponible, puis de rechercher d’éventuelles traces d’intrusion.
Sources : alerte officielle GitLab du 12 octobre 2026, analyse Rapid7, données Shadowserver et publication BleepingComputer du 2 novembre 2026.
