En bref

  • CVE-2026-97229 (CVSS 10.0) : RCE sans authentification sur GitLab via une expression régulière malformée dans un fichier .gitlab-ci.yml
  • 25 766 instances GitLab auto-hébergées exposées sur Internet — PoC public disponible depuis le 13 octobre 2026 (Rapid7)
  • Patcher immédiatement vers GitLab 19.4.2, 19.3.5 ou 19.2.8 et effectuer une rotation complète des secrets CI/CD

Les faits

Le 12 octobre 2026, GitLab a publié des correctifs critiques en versions 19.4.2, 19.3.5 et 19.2.8 pour les éditions Community et Enterprise, adressant notamment CVE-2026-97229 — une vulnérabilité d'exécution de code à distance notée CVSS 10.0, le score maximum possible. C'est la deuxième CVE CVSS 10.0 à toucher GitLab en deux ans, après CVE-2023-7028 qui avait provoqué une vague de compromissions de plateformes de développement. L'historique se répète, et les conséquences peuvent être tout aussi sévères pour les organisations qui tardent à appliquer le correctif.

La faille réside dans le parseur de configurations CI/CD de GitLab. En soumettant une expression régulière spécialement conçue dans un fichier .gitlab-ci.yml accessible publiquement ou via l'API non authentifiée, un attaquant provoque un integer overflow (CWE-190) dans le moteur de validation regex. Cet overflow est exploitable pour exécuter du code arbitraire dans le contexte du processus serveur GitLab. L'absence totale de prérequis d'authentification, combinée à la gravité de l'impact, justifie pleinement le score CVSS maximal de 10.0.

L'exploitation a progressé à une vitesse alarmante. Rapid7 a reproduit la vulnérabilité en moins de 24 heures après la publication du patch le 12 octobre, et a mis en ligne un proof-of-concept public le 13 octobre 2026. Censys a simultanément dénombré 25 766 instances GitLab auto-hébergées directement exposées sur Internet — une surface d'attaque massive pour les acteurs malveillants désormais équipés d'un exploit fonctionnel.

GitLab.com, la plateforme SaaS hébergée par GitLab Inc., a été corrigée avant la divulgation publique. En revanche, les instances self-managed déployées dans des datacenters d'entreprise, sur des VPS, ou via Docker et Kubernetes restent vulnérables tant que la mise à jour n'est pas appliquée. Les organisations ayant adopté GitLab dans une stratégie de souveraineté ou de conformité RGPD en hébergeant leur propre instance sont directement dans le périmètre.

La criticité de cette vulnérabilité dépasse la simple compromission d'un serveur. GitLab est au cœur des pipelines CI/CD de millions d'organisations : c'est là que le code source vit, que les secrets sont stockés (clés API, credentials cloud, certificats), et que les artefacts de production sont construits. Une instance GitLab compromise permet à un attaquant d'injecter du code malveillant dans les pipelines de build, d'exfiltrer l'ensemble des secrets CI/CD, et de propager des implants vers les environnements de production à chaque nouveau déploiement. CVE-2026-97229 est un vecteur de supply chain attack de premier rang.

La release du 12 octobre 2026 corrige en tout 24 vulnérabilités, dont CVE-2026-92883 (XSS, CVSS 8.7) et CVE-2026-16301 (autorisation incorrecte, CVSS 8.5). Mais c'est CVE-2026-97229 qui concentre la priorité absolue, étant donné la disponibilité du PoC public et les signalements d'exploitation active dans les 72 heures suivant sa publication.

Dans les jours suivant le PoC, plusieurs sources de threat intelligence ont détecté des scans massifs automatisés ciblant les instances GitLab exposées avec tentatives d'exploitation active. Le délai entre publication d'un PoC et première exploitation dans le wild est désormais mesuré en heures, pas en jours. Chaque heure sans patch sur une instance exposée est une fenêtre d'opportunité supplémentaire pour les attaquants.

Un aspect souvent négligé post-exploitation : même si une instance n'est pas directement compromise, les pipelines CI/CD ayant exécuté des jobs depuis des branches issues de dépôts forkés publics méritent une vérification. L'exploitation via CI/CD peut se manifester de manière différée, notamment si des artefacts malveillants ont été déployés en production avant la détection de la compromission.

Impact et exposition

Toute instance GitLab CE ou EE en versions antérieures à 19.4.2, 19.3.5 et 19.2.8, accessible depuis Internet ou depuis un réseau interne non segmenté, est vulnérable. Les pipelines CI/CD publics, les API accessibles anonymement et les webhooks exposés constituent les vecteurs d'exploitation primaires. Une compromission réussie donne un accès au niveau processus serveur à l'ensemble des dépôts, secrets et pipelines hébergés, avec un impact supply chain potentiel sur les environnements de production.

Recommandations

  • Mettre à jour immédiatement vers GitLab 19.4.2, 19.3.5 ou 19.2.8 selon la version actuellement déployée
  • Si la mise à jour immédiate est impossible, désactiver l'accès public aux API CI/CD et restreindre les webhooks aux seules IP de confiance
  • Auditer les pipelines CI/CD des 10 derniers jours à la recherche de scripts ou d'étapes injectés non autorisés
  • Effectuer une rotation complète de tous les secrets stockés dans GitLab : variables CI/CD, deploy tokens, personal access tokens, clés SSH de déploiement
  • Activer les journaux d'audit GitLab et surveiller les accès API anonymes inhabituels sur les endpoints de configuration CI/CD

Alerte critique

CVE-2026-97229 est notée CVSS 10.0 avec un PoC public disponible depuis le 13 octobre 2026. Plus de 25 700 instances auto-hébergées sont exposées sur Internet et l'exploitation active est confirmée. Toute instance GitLab non mise à jour présente un risque de compromission de la chaîne de développement et des environnements de production.

Mon GitLab est derrière un VPN, suis-je protégé contre CVE-2026-97229 ?

Un GitLab accessible uniquement via VPN n'est pas dans les 25 766 instances exposées sur Internet — votre surface d'attaque externe directe est réduite. Cependant, si votre instance est accessible depuis un segment réseau interne non segmenté, elle reste vulnérable à une exploitation post-compromission d'un poste de travail interne. Si des pipelines CI/CD récupèrent des dépendances externes ou traitent des configurations issues de MR venant de forks externes, un vecteur d'exploitation indirect existe. Le patch reste nécessaire quelle que soit la topologie réseau.

Votre infrastructure est-elle exposée ?

Ayi NEDJIMI réalise des audits de sécurité ciblés pour identifier et corriger vos vulnérabilités avant qu'elles ne soient exploitées.

Demander un audit