GitLab referme un CVSS 10,0 : une regex forgée exécute du code sans la moindre authentification
Le 12 octobre 2026, GitLab a publié un correctif critique refermant 24 failles, dont CVE-2026-97229, un débordement d’entier à CVSS 10,0 dans le compilateur d’expressions régulières du CI/CD, exploitable sans authentification. Tout administrateur d’une instance auto-hébergée doit passer en 19.4.2, 19.3.5 ou 19.2.8 sans attendre, car cette faille ne demande même plus de compte.
12 octobre 2026. GitLab publie les versions 19.4.2, 19.3.5 et 19.2.8 pour les éditions Community et Enterprise, un correctif critique qui referme 24 failles. 12 octobre 2026. La plus grave, CVE-2026-97229, obtient le score maximal CVSS 10,0 et permet à un attaquant non authentifié d’exécuter du code sur le serveur via une expression régulière forgée dans une configuration CI/CD. 12 octobre 2026. GitLab.com tourne déjà sur la version corrigée. Pourquoi c’est important : il y a trois semaines, une faille quasi jumelle exigeait encore un compte valide pour être exploitée — celle-ci n’en demande plus, ce qui change la nature de l’urgence pour les instances auto-hébergées.
Une faille critique sans prérequis
CVE-2026-97229 est un débordement d’entier (integer overflow) dans le compilateur d’expressions régulières qui valide les règles des pipelines CI/CD. Le vecteur CVSS est sans ambiguïté : AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H — attaque par le réseau, faible complexité, aucun privilège requis, aucune interaction utilisateur, impact confidentialité-intégrité-disponibilité complet et changement de périmètre. C’est la définition d’un 10,0.
La chaîne se lit ainsi : un attaquant soumet une règle contenant une expression régulière hostile à l’analyseur de pipeline ; le serveur la compile ; la corruption mémoire obtenue débouche sur l’exécution de code dans le processus GitLab. Comme la validation de la configuration est le point d’entrée, l’attaquant n’a pas besoin d’un compte, d’un accès au dépôt ni d’un runner compromis. La faille a été signalée par le chercheur joaxcar, déjà à l’origine des deux 9,9 de septembre, via le programme de bug bounty HackerOne.
Les versions impactées couvrent la quasi-totalité des déploiements récents : tout 19.2 avant 19.2.8, tout 19.3 avant 19.3.5 et tout 19.4 avant 19.4.2.
La même famille que septembre, un cran au-dessus
Le correctif du 23 septembre 2026 refermait déjà deux exécutions de code à CVSS 9,9 dans le même chemin de code : CVE-2026-89078, un double free, et CVE-2026-93577, un débordement d’entier dans le compilateur d’expressions régulières. Le point commun était le prérequis PR:L — il fallait être authentifié, même sans privilège administratif.
CVE-2026-97229 referme la boucle en supprimant ce prérequis. Le compilateur d’expressions régulières de la configuration CI/CD reste le point d’entrée, mais la barre d’accès tombe à zéro. La progression de septembre à octobre dessine une tendance inquiétante : ce moteur, historiquement écrit en C et réutilisé par Ruby sous GitLab, accumule les classes de failles — double free, débordement d’entier — et chaque itération élargit la surface exploitable.
Le reste de la livraison confirme que le correctif ne se résume pas à une faille. CVE-2026-92883, un XSS noté High dans la coloration syntaxique, permet à un utilisateur authentifié d’exécuter du JavaScript dans la session d’autres utilisateurs via un dépôt forgé. CVE-2026-16301 et CVE-2026-14814, également High, touchent respectivement l’autorisation du service de création de pipelines descendants et un regex permissif dans l’accès aux fichiers. Plusieurs autres failles, notées Medium, concernent l’autorisation dans les API GraphQL, le package registry et les rôles personnalisés. Vingt-quatre correctifs au total, dont un seul justifie à lui seul l’urgence.
Le pipeline as code devient la surface d’attaque
Le point d’entrée de cette faille n’est pas un service exotique, c’est la configuration CI/CD elle-même. Les règles only et except, les workflow:rules et les filtres de variables acceptent des expressions régulières, et GitLab les compile à chaque évaluation de pipeline. Le « pipeline as code » a déplacé la logique de build dans les dépôts — un gain de reproductibilité — mais il a aussi élargi le périmètre de confiance : tout ce qui influence ce que le serveur va compiler devient une surface exécutée côté serveur.
Avec CVE-2026-97229, cette surface devient accessible sans compte. Une expression régulière n’est pas un format inerte : la compiler revient à faire tourner un petit programme, et un moteur non maîtrisé transforme ce programme en primitive d’exécution. La parade de fond ne remplace pas le correctif, elle le complète : restreindre qui peut pousser vers les dépôts qui alimentent des pipelines, surveiller les journaux d’audit pour des configurations modifiées de façon anormale, et traiter le serveur GitLab comme l’actif critique qu’il est devenu — il détient le code source, les secrets CI/CD et désormais le plan de contrôle des agents IA.
Migrations et fenêtre de maintenance
Le correctif embarque des migrations de base de données, avec une conséquence directe sur le déploiement. Sur une instance mono-nœud, la mise à jour provoque une indisponibilité pendant l’exécution des migrations, qui doivent se terminer avant le redémarrage de GitLab. Sur une instance multi-nœuds, les procédures de mise à jour zéro-downtime permettent d’appliquer le correctif sans coupure — à condition de les suivre à la lettre. La version 19.3.5 inclut en outre des migrations post-déploiement.
Pour une instance sous Docker, la remontée de version est directe :
# Docker (image officielle) — monter vers le correctif critique du 12 octobre
docker pull gitlab/gitlab-ee:19.4.2-ee.0
docker compose up -dGitLab.com fonctionne déjà sur la version corrigée, et les clients GitLab Dedicated n’ont aucune action à mener. Ce sont les instances auto-hébergées qui portent le risque.
Comment savoir si vous avez été touché
Une exploitation de cette classe ne laisse pas de trace évidente : l’exécution a lieu dans le processus du serveur GitLab, pas dans un runner isolé. Les signaux exploitables sont indirects — un pipeline qui échoue de façon répétée sur une règle regex, des expressions anormalement longues ou imbriquées dans les fichiers .gitlab-ci.yml récemment modifiés, une hausse soudaine de la charge CPU du serveur pendant l’évaluation des pipelines. Croisez ces indices avec les journaux d’audit, qui enregistrent qui a modifié quelle configuration et à quel moment.
En cas de doute, comparez l’historique des modifications de .gitlab-ci.yml avec les pics d’erreur des pipelines : une tentative d’exploitation laisse presque toujours une trace dans l’un des deux.
Verdict
Si vous administrez une instance GitLab auto-hébergée, montez vers 19.4.2, 19.3.5 ou 19.2.8 sans attendre — un 10,0 exploitable sans authentification ne laisse aucune marge de triage, et un plan de contrôle DevSecOps compromis donne à l’attaquant le code, les secrets et les déploiements. Si vous gérez une instance multi-nœuds, planifiez la mise à jour zéro-downtime plutôt qu’une coupure sèche, mais ne repoussez pas le correctif pour autant. Et si votre priorité est la prévention, traitez la surface CI/CD comme un périmètre de confiance à réduire : avec cette famille de failles, le droit de modifier une configuration de pipeline vaut désormais un droit d’exécution de code sur le serveur, et plus personne n’a besoin d’un compte pour tenter sa chance.