GitLab 19.4.1 referme deux RCE critiques à CVSS 9,9 dans l’analyseur d’expressions régulières du CI/CD
Le 23 septembre 2026, GitLab a publié un correctif critique pour 19.4.1, 19.3.3 et 19.2.7, refermant deux exécutions de code à distance à CVSS 9,9 dans l’analyseur d’expressions régulières du pipeline, déclenchables par un simple fichier .gitlab-ci.yml forgé. Tout utilisateur authentifié capable d’éditer une configuration CI/CD devient un vecteur : corrigez les instances auto-hébergées immédiatement.
23 septembre 2026. GitLab publie les versions 19.4.1, 19.3.3 et 19.2.7 pour Community Edition et Enterprise Edition, qualifiées de correctif critique. 23 septembre 2026. Deux failles notées CVSS 9,9 y sont refermées, toutes deux dans l’analyseur d’expressions régulières qui traite les configurations CI/CD. 17 septembre 2026. La version 19.4, sortie six jours plus tôt, venait d’étendre le plan de contrôle aux agents IA. Pourquoi c’est important : une expression régulière forgée dans un fichier .gitlab-ci.yml devient une primitive d’exécution de code à distance, et tout utilisateur authentifié capable d’éditer un pipeline devient un vecteur d’attaque.
Deux 9,9 dans le même chemin de code
Les deux failles critiques partagent le même point d’entrée : le moteur d’expressions régulières qui valide les règles du pipeline CI/CD.
CVE-2026-89078 est un double free dans l’analyseur d’expressions régulières : sous certaines conditions, un utilisateur authentifié peut exécuter du code arbitraire sur le serveur en soumettant une expression régulière spécialement conçue dans une configuration CI/CD. Le vecteur CVSS est noté AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:L, soit 9,9. CVE-2026-93577 est un débordement d’entier dans le compilateur d’expressions régulières, avec la même conséquence et le même vecteur, mais un impact intégrité-disponibilité complet : C:H/I:H/A:H.
Les deux ont été signalées par le même chercheur, joaxcar, via le programme de bug bounty HackerOne. Les versions impactées couvrent tout 19.2 avant 19.2.7, tout 19.3 avant 19.3.3 et tout 19.4 avant 19.4.1 — autrement dit, la quasi-totalité des instances auto-hébergées récentes.
Le regex comme primitive d’exécution
La leçon de cette livraison dépasse GitLab. Une expression régulière n’est pas un format inerte : la compiler et l’exécuter revient à faire tourner un petit programme, et les moteurs historiques écrits en C accumulent les classes de failles — double free, débordement d’entier, plus rarement l’exécution directe. Le fait que GitLab traite des expressions régulières venues de la configuration CI/CD transforme ce risque théorique en vecteur pratique : le fichier .gitlab-ci.yml est rédigé par des développeurs, mais il est aussi modifiable par tout contributeur d’un projet.
Concrètement, la chaîne d’exploitation se lit ainsi : un compte authentifié, même sans privilège administratif, soumet une règle contenant une expression régulière hostile ; le serveur la compile en analysant le pipeline ; la corruption mémoire obtenue aboutit à l’exécution de code. Le tout sans interaction d’une victime et sans accès préalable à l’infrastructure.
Le reste de la livraison
Le correctif referme aussi plusieurs failles secondaires qui méritent l’attention des équipes DevSecOps. CVE-2026-84739, une injection XSS dans le visualiseur de diff des merge requests notée 8,7, remonte jusqu’aux versions 13.11 — un rappel que certaines failles dorment des années avant d’être corrigées. CVE-2026-92470, notée 7,7, concerne la fonctionnalité de dépannage Duo AI : un défaut d’autorisation permettait de lire les valeurs de variables CI/CD sensibles depuis les traces de jobs en mode debug. Enfin, CVE-2026-92874 corrige un contrôle de périmètre défaillant sur les jetons MCP, un enjeu direct pour les équipes qui ont commencé à brancher des agents IA sur GitLab avec 19.4.
Migrations et fenêtre de maintenance
Le correctif embarque des migrations de base de données, ce qui a une conséquence concrète 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. Les versions 19.3.3 et 19.2.7 incluent en plus des migrations post-déploiement à exécuter après la mise à jour.
Pour une instance auto-hébergée sous Docker, la remontée de version est directe :
# Docker (image officielle) — remonter vers le correctif critique
docker pull gitlab/gitlab-ee:19.4.1-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, et l’éditeur recommande explicitement une mise à jour « dès que possible ».
Un vecteur qui vient du « pipeline as code »
Le point d’entrée de ces deux failles n’est pas anodin : c’est la configuration CI/CD elle-même, devenue du code à part entière. 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 du pipeline. Ce qui était un simple fichier de configuration est devenu une surface d’attaque exécutée côté serveur.
C’est une tendance plus large. Le « pipeline as code » a déplacé la logique de build dans les dépôts — excellent pour la reproductibilité — mais il a aussi élargi le périmètre de confiance : tout contributeur d’un dépôt peut influencer ce que le serveur GitLab va compiler et exécuter. Une faille dans l’analyseur transforme ce droit d’édition en exécution de code, sans passer par les protections du runner.
La parade ne se résume donc pas au correctif. Auditer qui peut éditer .gitlab-ci.yml, restreindre les contributeurs externes aux forks sans accès CI, et surveiller les journaux d’audit pour des pipelines anormalement lents ou en erreur sur une règle regex — autant de réflexes qui réduisent la surface en amont, indépendamment des failles à venir. Les deux 9,9 d’aujourd’hui sont le symptôme d’une surface qui ne va cesser de grandir.
Comment savoir si vous avez été touché
Avant même de patcher, la question de la détection se pose. Une exploitation de cette classe ne laisse pas de trace évidente : l’exécution de code a lieu dans le processus du serveur GitLab, pas dans un runner isolé, ce qui la rend difficile à distinguer d’une activité légitime.
Les signaux exploitables sont indirects. Un pipeline qui échoue de façon répétée sur une règle regex, des expressions régulières 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 — autant d’indices faibles à croiser avec les journaux d’audit de GitLab, 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.
La conclusion rejoint celle de toute compromission d’un plan de contrôle DevSecOps : le serveur GitLab détient les clés de vos déploiements, de vos secrets CI/CD et de votre code source. Le traiter comme un actif critique — sauvegardes testées, surveillance des journaux, correctifs sous 24 heures — n’est pas une option, mais la norme minimale pour une plateforme qui exécute désormais des agents IA en plus des pipelines.
Verdict
Si vous administrez une instance GitLab auto-hébergée, montez vers 19.4.1, 19.3.3 ou 19.2.7 sans attendre : deux 9,9 exploitables par n’importe quel utilisateur authentifié ne laissent aucune marge de triage. 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, auditez qui peut éditer les configurations CI/CD de vos dépôts : avec cette classe de faille, le droit d’écrire un .gitlab-ci.yml équivaut temporairement à un droit d’exécution de code sur le serveur.