GitLab corrige une RCE CVSS 10 déclenchée par une expression régulière dans un pipeline CI/CD

12 octobre 2026. GitLab publie les versions 19.4.2, 19.3.5 et 19.2.8 pour corriger 24 failles, dont CVE-2026-97229. 10.0. Le score CVSS maximal de cette faille, qui permet une exécution de code à distance sans authentification. 25 766. Le nombre d’instances GitLab exposées sur Internet recensées par les scanners publics, alors qu’un PoC circule déjà. Pourquoi c’est important : le vecteur n’est ni un binaire ni un service réseau, c’est un fichier de configuration de pipeline — du texte que vos développeurs et vos forks écrivent chaque jour, et que la plupart des équipes ne traitent pas comme une surface d’attaque.

La faille : un entier qui déborde dans le compilateur de regex

CVE-2026-97229 est un dépassement d’entier (CWE-190) dans le compilateur d’expressions régulières que GitLab utilise pour évaluer les règles de ses pipelines CI/CD. Concrètement, GitLab compile les expressions régulières présentes dans les fichiers .gitlab-ci.yml — les conditions rules:if, les motifs only/except, les correspondances de variables. Le problème : une expression régulière spécialement conçue provoque un débordement pendant la compilation, ce qui, faute de validation suffisante, permet à un attaquant non authentifié d’exécuter du code arbitraire sur le serveur GitLab.

La faille touche toutes les versions de GitLab CE et EE depuis 19.2 jusqu’aux correctifs exclus : 19.2.8, 19.3.5 et 19.4.2. Une instance en 19.3.2 ou en 19.4.0 est donc vulnérable. Le CERT-EU a publié l’avis 2026-016 sur le sujet, et l’agence singapourienne CSA a émis l’alerte AL-2026-141. La note est rare : un CVSS de 10.0, la valeur maximale, pour une faille d’exécution de code à distance non authentifiée.

Pourquoi le fichier de pipeline est le vrai problème

Le point qui change la donne n’est pas la gravité — les RCE critiques chez les forgeurs de code ne sont pas une nouveauté — mais l’emplacement du déclencheur. La charge utile vit dans un fichier .gitlab-ci.yml, un artefact que GitLab doit analyser pour construire le graphe de pipeline. Or ce fichier est, dans la plupart des organisations, semi-public par conception : les merge requests venues de forks portent leur propre .gitlab-ci.yml, et les dépôts internes en changent en permanence.

Résultat : un attaquant qui veut franchir le périmètre n’a pas besoin d’un exploit réseau contre un service C ou d’un compte privilégié. Il lui suffit, selon le modèle de confiance de votre instance, de pousser une branche ou d’ouvrir une MR depuis un fork contenant une expression régulière malveillante. C’est exactement le scénario que les défenseurs redoutent dans la sécurité de la chaîne d’approvisionnement logicielle : l’entrée est légitime, le contenu ne l’est pas.

Le correctif confirme cette lecture. GitLab décrit la cause comme une validation insuffisante des expressions régulières : le compilateur ne borne pas correctement une valeur avant de l’utiliser, et le débordement qui en résulte est exploitable. En clair, on ne parle pas d’un ReDoS qui épuise le CPU — on parle de corruption de mémoire qui aboutit à une RCE.

Les 23 autres failles ne sont pas de la figuration

Le lot du 12 octobre corrige aussi des problèmes qui touchent directement la posture CI/CD, même sans atteindre le 10.0 de la faille principale. Parmi eux, l’exposition de variables d’environnement protégées, le contournement des protections de branche et des élévations de privilèges. Pris ensemble, ils forment une chaîne classique : un pipeline qui fuit un secret, une règle de protection qu’on saute, un privilège qu’on escalade.

C’est le signal d’un problème structurel plus large. Les runners exécutent du code sur vos machines, les variables CI portent vos secrets, et le graphe de pipeline décide de ce qui part en production. Chacune de ces couches a maintenant une faille connue dans le même lot de correctifs. Traiter le patch comme une formalité, c’est laisser trois chemins d’attaque ouverts à la place d’un.

Ce qu’il faut faire, concrètement

La correction est simple en apparence : monter en version. Mais le passage de 19.2.x ou 19.3.x vers une version corrigée est une migration, pas un clic, et les équipes qui traînent sur des versions mineures anciennes sont précisément celles qui mettront des semaines à bouger. Le PoC public — des détails techniques et un code d’exploitation — raccourcit ce délai : il ne faut pas supposer que la fenêtre reste ouverte jusqu’à votre prochaine maintenance planifiée.

Deux actions immédiates si vous êtes auto-hébergé. D’abord, vérifiez votre version et positionnez-vous sur 19.4.2, 19.3.5 ou 19.2.8 selon votre branche. Ensuite, réduisez la surface en attendant : limitez les MR issues de forks à des projets de confiance, et appliquez une revue stricte des .gitlab-ci.yml qui entrent par ce chemin. Une expression régulière n’a pas à être exécutée par le serveur avant d’avoir été lue par un humain.

À plus long terme, changez de modèle mental. Un fichier de pipeline est du code exécuté par votre forge, pas un simple fichier de configuration. Il mérite la même politique : revue de code, tests, provenance, et surtout la même surface de confiance. La faille d’aujourd’hui est un compilateur de regex ; la prochaine sera peut-être un parseur YAML ou un moteur de template.

Verdict

Si vous hébergez GitLab vous-même, c’est une urgence à traiter maintenant : la combinaison d’un CVSS 10.0, d’un PoC public et de 25 000+ instances exposées ne laisse aucune marge, et le vecteur par fork élargit le cercle des attaquants potentiels. Si vous êtes sur GitLab.com, la correction est déjà appliquée côté hébergeur — concentrez-vous plutôt sur la revue des .gitlab-ci.yml des MR de forks et sur la rotation des variables CI si un pipeline suspect a tourné. Dans les deux cas, la leçon est la même : votre configuration de pipeline fait partie de votre surface d’attaque, et elle s’agrandit à chaque fork que vous acceptez.

Références

• GitLab — Critical Patch Release: 19.4.2, 19.3.5, 19.2.8 (12 octobre 2026)
• OpenCVE — CVE-2026-97229
• CERT-EU — Security Advisory 2026-016, Critical Vulnerability in GitLab CE and EE
• CSA Singapour — Alert AL-2026-141
• DevOps.com — GitLab Fixes CVSS 10 Flaw in CI/CD Regex Engine, Plus 23 Other Vulnerabilities