GitLab : deux failles critiques dans le moteur de regex CI/CD

Deux failles critiques dans le même correctif

Le 23 septembre 2026, GitLab a livré un correctif critique pour les éditions Community et Enterprise auto-hébergées, en versions 19.4.1, 19.3.3 et 19.2.7. Onze vulnérabilités y sont traitées. Deux d'entre elles partagent le même score de 9.9 et le même point d'entrée : le moteur d'expressions régulières que GitLab utilise pour évaluer les regex de vos fichiers CI/CD.

CVE-2026-89078 est un double free, CVE-2026-93577 un dépassement d'entier. Dans les deux cas, une regex façonnée, placée dans une configuration CI/CD, corrompt la mémoire du serveur pendant qu'il la traite.

Une précision conditionne tout le reste : ces deux failles exigent un compte. C'est ce qui les distingue de CVE-2026-85706, la lecture de fichier non authentifiée corrigée quinze jours plus tôt. Le privilège demandé reste faible, mais il n'est pas nul.

Les faits, tels que l'avis les pose

Un score de 9.9 pour des failles authentifiées peut surprendre. Il tient au S:C du vecteur : la corruption ne reste pas cantonnée à l'application, elle atteint le processus serveur. La dernière lettre sépare les deux CVE, A:H contre A:L. Le dépassement d'entier fait tomber le service de façon fiable, le double free pèse moins sur la disponibilité. La conséquence certaine de ces bugs, c'est donc le plantage. L'exécution de code est la borne haute : l'avis la retient, mais elle n'est pas acquise sur toutes les configurations.

Le mécanisme

GitLab évalue des regex que vous écrivez, à plusieurs endroits de la chaîne CI/CD : les règles de déclenchement d'un job (rules:if), les filtres de branches ou de tags, les conditions de workflow. Cette regex est une chaîne fournie par l'auteur du pipeline. Pour l'évaluer, le serveur l'analyse d'abord, puis la compile. Chaque CVE vise une de ces deux étapes.

Le double free (CVE-2026-89078) se produit à l'analyse. Sur une certaine forme de motif, l'analyseur libère deux fois la même zone mémoire. L'allocateur se retrouve dans un état incohérent, et une allocation ultérieure peut retomber sur une zone déjà rendue. Le dépassement d'entier (CVE-2026-93577) intervient plus loin, à la compilation : le calcul de la taille d'une structure déborde de la plage d'un entier, le moteur réserve trop peu de mémoire, et l'écriture qui suit sort du tampon.

La racine est commune. Le texte de la regex pilote des opérations mémoire dont les cas limites ne sont pas tous bornés. On n'est pas sur une injection qui se repère d'un coup d'œil : il faut une forme de motif précise, calée sur l'implémentation, pour toucher le défaut. C'est aussi pourquoi aucun exploit ne circule pour l'instant. Trouver le motif qui plante ne donne pas une exécution de code fiable, et l'écart entre les deux se mesure en semaines de développement.

Kill chain

Du compte à faible privilège à l'exécution de code

Phase 1Corruption mémoire

Phase 2Exécution de code (conditionnelle)

Qui peut soumettre une regex CI/CD chez vous ?

La portée réelle de ces failles se résume à cette question. Sur une instance qui autorise l'inscription libre, ou qui accepte des pipelines proposés par des contributeurs externes, un compte récent au rôle modeste suffit à pousser une configuration CI/CD. C'est le cas le plus exposé, et la raison pour laquelle GitLab.com a été corrigé sans délai.

Sur une instance interne réservée aux salariés, il faut d'abord un accès. Le risque ne disparaît pas pour autant. Un compte de stagiaire, un jeton de CI oublié dans un dépôt, un poste de développeur compromis, et l'attaquant passe d'un accès en lecture à du code sur le serveur qui héberge vos secrets et vos clés de déploiement. C'est le mouvement latéral qui fait d'un incident mineur une compromission de toute la chaîne de build.

Versions concernées

L'avis délimite trois branches : la 19.2 avant la 19.2.7, la 19.3 avant la 19.3.3, la 19.4 avant la 19.4.1. Le correctif est sorti le 23 septembre 2026.

Vérifier son exposition

Il n'y a pas, ici, de test à distance sans risque. Prouver l'exposition à une corruption mémoire supposerait d'envoyer la regex à un vrai pipeline, donc de chercher à faire tomber le serveur visé. Aucun marqueur inoffensif ne permet de contourner ça, contrairement à un path traversal qu'on confirme en faisant inclure un fichier public. Sur un actif de production, tester revient à exploiter. La version reste le seul juge fiable.

Trois façons de la relever, de la plus sûre à la plus commode :

• Sur le serveur, sudo gitlab-rake gitlab:env:info (installation Omnibus) donne la version exacte.
• Par l'API, curl --header "PRIVATE-TOKEN: <jeton>" https://gitlab.exemple.fr/api/v4/version, qui exige un jeton.
• Depuis l'interface, la page d'aide (/help) une fois connecté.

Les trois supposent un accès à l'instance. GitLab ne publie pas son numéro de correctif à un visiteur anonyme, par prudence, ce qui reste une limite pour tout inventaire mené depuis l'extérieur.

Remédiation

1. Mettez à jour vers 19.2.7, 19.3.3 ou 19.4.1 selon votre branche. C'est la seule remédiation qui ferme réellement les deux failles, et elle n'impose pas de saut de version majeure.
2. Recensez vos GitLab auto-hébergés, y compris ceux que personne ne revendique : l'instance de test d'un projet, le GitLab d'une filiale, celui d'un sous-domaine oublié. C'est souvent lui qui traîne une version en retard.
3. En attendant la montée de version, resserrez les accès : coupez l'inscription libre si elle n'est pas nécessaire, revoyez les rôles autorisés à modifier un fichier CI/CD, surveillez la création de projets par des comptes récents.

GitLab, cible récurrente

En un mois, GitLab aura connu une lecture de fichier non authentifiée à 10.0, puis ces deux corruptions mémoire à 9.9. Le vecteur change, le constat tient : une instance auto-hébergée concentre le code, les secrets et les clés de déploiement d'une organisation, ce qui en fait une cible de choix.

Un pentest annuel n'attrape aucune de ces failles : une divulgation du 23 septembre est absente d'un rapport daté du printemps. Ce qui les rattrape, c'est un inventaire à jour des actifs exposés et une surveillance qui repère l'instance restée en retard d'un correctif, sans attendre l'audit suivant. Encore faut-il connaître tout son périmètre, GitLab non déclarés compris.

Où Flawfence intervient

Ces deux failles étant authentifiées, aucun scanner externe passif ne prouve leur exploitabilité de l'extérieur, et le nôtre ne le prétend pas. Sa valeur est ailleurs, sur ce qui manque le plus souvent : retrouver l'instance GitLab qu'on avait oubliée.

Face à un avis de ce type, Flawfence découvre vos GitLab exposés sur l'ensemble de vos domaines et sous-domaines, Shadow IT compris, signale la version quand elle est lisible, marque chaque instance auto-hébergée comme un actif sensible à tenir à jour, et surveille en continu pour qu'un nouveau GitLab exposé ou un retour en arrière de version déclenche une alerte le jour même.

Questions fréquentes

Faut-il un compte pour exploiter ces failles ?

Oui. Le vecteur des deux CVE porte PR:L : il faut un compte à privilège faible, capable de soumettre une configuration CI/CD contenant la regex façonnée. Ce n'est pas exploitable par un anonyme, contrairement à la lecture de fichier CVE-2026-85706 du même mois. Sur une instance qui autorise l'inscription libre, la barrière reste basse.

Sont-elles activement exploitées ?

À la publication du correctif, aucune exploitation dans la nature n'était rapportée et aucun code d'exploitation public ne circulait. Passer d'une corruption mémoire à une exécution de code fiable demande un travail d'exploit qui n'est pas immédiat. Ce n'est pas une raison d'attendre : le correctif décrit le défaut, et balise le chemin pour qui voudra écrire cet exploit.

Corruption mémoire et RCE, est-ce pareil ?

Non, et l'avis reste prudent en parlant d'exécution de code « possible ». La conséquence certaine, c'est l'instabilité, le plantage du processus GitLab, donc un déni de service. L'exécution de code arbitraire est la borne haute, atteignable selon la configuration et le durcissement du système. On traite ces failles comme critiques sans surjouer la certitude d'une RCE immédiate.

Un WAF peut-il me protéger en attendant ?

Pas de façon fiable. La regex voyage dans une configuration CI/CD légitime, pas dans un paramètre suspect. Distinguer un motif dangereux d'un motif ordinaire sans bloquer des pipelines valides dépasse une règle générique. La montée vers 19.2.7, 19.3.3 ou 19.4.1 est la seule remédiation réelle.

Comment vérifier ma version sans exposer l'instance ?

Sur le serveur, sudo gitlab-rake gitlab:env:info donne la version exacte. En interface, la page d'aide (/help) l'affiche une fois connecté. Par l'API, GET /api/v4/version la renvoie, mais réclame un jeton. Aucun moyen fiable ne permet de lire le numéro de correctif depuis l'extérieur sans authentification, et c'est voulu.

Ce qu'il faut retenir

Une expression régulière fournie par un utilisateur est une entrée comme une autre : le code qui l'analyse ou la compile doit borner ses cas limites, sinon il finit par écrire là où il ne faut pas. La difficulté n'est pas de tester, on ne peut pas le faire à distance sans risque, mais de savoir où sont vos instances GitLab et sur quelle version elles tournent. C'est un travail d'inventaire, pas d'exploit.

Vérifiez votre exposition sur flawfence.com