CVE-2026-97229 : la réserve que cache le RCE « non authentifié » de GitLab

Zéro identifiant sur le papier. Un compte en pratique.

Zéro. C’est le nombre d’identifiants que requiert le vecteur CVSS de GitLab lui-même pour CVE-2026-97229 : AV:N/AC:L/PR:N/UI:N, un 10.0 parfait, exécution de code arbitraire sans le moindre privilège. Un. C’est le nombre de comptes dont ont eu besoin les deux seules personnes ayant réellement fait fonctionner cela, indépendamment l’une de l’autre, avant de pouvoir envoyer la requête qui faisait quoi que ce soit. Les deux chiffres sont vrais. Ils décrivent deux étapes différentes de la même attaque.

CVE-2026-97229 est un débordement d’entier critique dans le compilateur d’expressions régulières CI/CD de GitLab, corrigé le 12 octobre 2026 sur les branches 19.2, 19.3 et 19.4.[1] L’avis de GitLab lui-même décrit exactement ce que cette note implique : une expression régulière forgée dans une configuration CI/CD, envoyée par un utilisateur non authentifié, se transforme en exécution de code arbitraire sur le serveur, sous certaines conditions.[1] La CISA l’a ajoutée à son catalogue des vulnérabilités activement exploitées moins de trois semaines plus tard, confirmant qu’elle est utilisée contre des cibles réelles.[2] Rien de tout cela n’est faux. Cela omet simplement le seul détail qui indique réellement votre niveau d’exposition : atteindre l’étape non authentifiée exige d’abord un compte.

Ce que GitLab a réellement publié, et quand

GitLab a daté la version corrigée du 12 octobre 2026, en publiant 19.2.8, 19.3.5 et 19.4.2 pour les trois branches concernées — 19.2 avant 19.2.8, 19.3 avant 19.3.5, 19.4 avant 19.4.2.[1] GitLab.com exécutait déjà une version corrigée avant la publication de l’avis, et les clients GitLab Dedicated n’ont eu absolument rien à faire.[1] Le chercheur qui l’a signalée a utilisé le pseudonyme HackerOne joaxcar, qui a par ailleurs signalé un bogue de redirection ouverte de gravité moyenne, CVE-2026-7767, corrigé dans la même version.[1]

Un détail a changé après coup, et il vaut la peine de le savoir avant de vérifier votre propre numéro de version. Les notes de version de GitLab indiquaient initialement 19.3.4 pour la branche 19.3 ; le lendemain, des articles ont rapporté que cette version corrigeait en réalité un bogue sans rapport, lié à la page des merge requests, et que 19.3.5 est bien la version réellement corrigée pour cette CVE, ce que l’avis actuel reflète désormais.[8] Ensuite, les choses se sont enchaînées rapidement : Rapid7 a signalé une reproduction indépendante et fonctionnelle environ un jour après la divulgation, une preuve de concept publique et signée a suivi environ quatre jours plus tard, et l’inscription de la CISA confirmant l’exploitation est arrivée environ dix-sept jours après le correctif initial.[1][2][4][7] Ce n’est pas le sujet principal de cet article. Cela vaut néanmoins la peine de s’y arrêter : un CVSS 10.0 sur un produit comme GitLab se transforme rapidement en arme dès que le correctif lui-même indique aux attaquants exactement où regarder.

Le moteur d’expressions régulières qui exécute votre commande au lieu de comparer votre chaîne

Je n’ai pas reproduit ceci moi-même. Tout ce qui suit provient de la preuve de concept que Jonah Burgess (GitHub : jburgess-r7) a publiée environ quatre jours après le correctif, explicitement qualifiée de « première publication de PoC », de la reproduction signalée séparément par Rapid7, et de l’avis de GitLab lui-même, tous consultés le 2 novembre 2026.[1][3][4] Le déclencheur se trouve derrière l’endpoint CI-lint de GitLab, celui-là même que GitLab utilise pour valider un fichier .gitlab-ci.yml avant l’exécution d’un pipeline. En lui soumettant une expression régulière forgée dans la configuration CI/CD, associée à une branche de dépôt dont le chemin utilise une astuce de nommage UTF-8 particulière, le calcul interne de longueur du compilateur d’expressions régulières déborde.[3]

Ce débordement ne se contente pas de faire planter le worker, même si c’est souvent aussi le cas. Il redirige l’exécution du moteur d’expressions régulières, droit vers une fonction qui exécute une commande arbitraire.[3] La commande s’exécute sous le compte de service à faible privilège « git » de GitLab, pas en tant qu’administrateur, ni en tant que root sur l’hôte.[3] C’est un vrai plafond pour l’ampleur des dégâts, et il vaut la peine de le dire clairement : il s’agit d’une exécution de code côté serveur, pas d’une voie instantanée vers un contrôle administrateur complet. Depuis un shell « git », un attaquant a déjà largement de quoi se servir, à commencer par le contenu des dépôts et tous les secrets CI que ce compte peut lire.

// The CI-lint trigger, reconstructed from Burgess's public PoC. Paraphrased
// shape of the chain -- not the working payload itself.

1. Attacker-controlled branch is pushed to a public project, with a
   specially-named (UTF-8) path and a crafted regex in .gitlab-ci.yml.
2. An unauthenticated request hits GitLab's CI-lint endpoint, which
   validates that regex before any pipeline actually runs.
3. The regex compiler's internal length accounting overflows -- an
   integer wraps where it shouldn't.
4. Execution inside the regex engine is redirected into a function that
   runs an OS command, as the low-privilege "git" service account.
5. On a vulnerable build, the worker process frequently crashes right
   after (a bare HTTP 502 is a side effect, not proof by itself).

L’étape qui se produit avant l’étape non authentifiée

Voici le détail que tous les titres sur un CVSS 10 passent sous silence. Le README de Burgess énonce clairement les conditions préalables : un compte ordinaire capable de pousser une branche vers un projet public sur l’instance cible ; une cible exécutant exactement la version officielle gitlab/gitlab-ce:19.4.1-ce.0 (toute autre nécessite des décalages binaires reconstruits) ; environ 9 Gio de mémoire libre ; et une accessibilité réseau vers un listener si l’on veut la sortie de la commande.[3] La requête CI-lint qui déclenche réellement le débordement ne nécessite aucun jeton, aucun cookie, ni aucun en-tête d’autorisation, cette partie est bien réellement non authentifiée.[3][4] Simplement, ce n’est pas la première étape.

Selon les informations de Help Net Security, Rapid7 a reproduit de manière indépendante une exécution de code fonctionnelle contre une image officielle non corrigée de GitLab CE 19.4.1 environ un jour après la divulgation (la même entrée a échoué contre l’image corrigée 19.4.2), et a décrit la même barrière : un « compte ordinaire » poussant la branche forgée, viable « sur les instances autohébergées qui autorisent la création de projets publics ».[4] Deux parties indépendantes, travaillant séparément, sont arrivées à la même condition préalable. Je souligne un point que les sources ne disent pas réellement, car il est tentant de fusionner les deux : le pseudonyme GitHub de la PoC porte le suffixe « -r7 », et son propre README renvoie vers « l’analyse technique de Rapid7 » de cette même faille. Aucune source n’affirme ce lien directement, donc je traite la PoC de Burgess et la reproduction de Rapid7 comme les sources le montrent réellement : deux confirmations obtenues indépendamment de la même condition préalable, et non une seule.

L’auteur de la PoC est également transparent sur ses limites : 10 essais sur 10 ont réussi contre cette unique version testée avec l’ASLR activé, la même entrée renvoie false contre le compilateur corrigé 19.4.2, et l’auteur affirme directement que « l’analyse des autres configurations concernées et des chemins atteignables est toujours en cours » et que la PoC « n’établit pas d’exploitation réelle lors d’intrusions ».[3] Un déclenchement réussi renvoie souvent un simple HTTP 502, car le worker plante juste après l’exécution de la commande ; un 502 seul, sans le reste du schéma, ne prouve donc rien.[3] Retenez cette distinction. Elle compte pour ce que vous pouvez réellement déduire de vos propres journaux.

Jusqu’où s’étend réellement le « non authentifié »

Alors, est-ce non authentifié ou non ? Les deux, selon la frontière dont on parle. Le vecteur CVSS de GitLab note le composant vulnérable PR:N, aucun privilège requis, et c’est exact pour ce qu’il évalue réellement : la requête CI-lint elle-même ne vérifie aucun identifiant.[1] Mais « le composant ne requiert pas d’authentification » et « la chaîne d’attaque ne requiert pas d’authentification » sont deux affirmations différentes, et les deux seules parties nommées ayant réussi à faire fonctionner cela en pratique, Burgess et Rapid7, s’accordent indépendamment pour dire que la chaîne nécessite une étape avant cette requête : un compte capable de pousser une branche vers un projet public.[3][4] La notation de gravité de GitLab n’est pas fausse. Elle répond simplement à une question plus étroite que ne le suggère le titre.

Que cette condition préalable soit triviale ou constitue un véritable mur dépend de réglages que la plupart des administrateurs ne considèrent pas comme des mesures d’atténuation pour cette CVE. La documentation de GitLab elle-même indique que l’auto-inscription est ouverte par défaut à tout visiteur sur une instance autohébergée, et recommande de la désactiver sur tout ce qui est exposé au public et ne s’attend pas à des inscriptions ouvertes.[5] Elle indique aussi que l’approbation par un administrateur des nouvelles inscriptions est le réglage par défaut pour les nouvelles instances depuis GitLab 13.6, de sorte qu’une instance raisonnablement récente et raisonnablement bien configurée a déjà un humain dans la boucle avant qu’un inconnu n’obtienne un compte.[5] La visibilité des projets, et qui est autorisé à créer un projet public, est configurable séparément par l’administrateur.[5] Rien de tout cela n’est un correctif. Mais tout cela change combien d’inconnus peuvent même atteindre la moitié non authentifiée de cette faille.

// For a stranger to turn this into RCE against your instance,
// three things have to be true at once:

1. Your instance allows self-registration, OR the attacker already
   holds any ordinary account on it.
2. That account (or self-registration) can create, or push a branch
   to, a PUBLIC project -- not just a private one.
3. The instance is still running an unpatched build
   (before 19.2.8 / 19.3.5 / 19.4.2) and is reachable from wherever
   the attacker is.

Close registration, restrict who can make projects public, or patch --
any one of the three breaks the chain. Patching is still the only fix
that doesn't depend on a setting staying the way you left it.

Exploitation confirmée. Presque rien d’autre ne l’est.

La CISA a ajouté CVE-2026-97229 à son catalogue des vulnérabilités activement exploitées le 29 octobre 2026, sous le nom « GitLab Community Edition and Enterprise Edition Integer Overflow or Wraparound Vulnerability », avec une date limite d’action obligatoire fixée au 1er novembre en vertu de la directive opérationnelle contraignante BOD 26-04.[2] Cette date d’ajout n’est pas une affirmation sur le moment où l’exploitation a réellement commencé. Les entrées KEV accusent régulièrement un retard par rapport à la première utilisation réelle, et aucune source ici ne précise quand les attaques contre cette faille ont réellement débuté. Lisez « 29 octobre » comme la date à laquelle la CISA l’a confirmé, pas comme un horodatage des attaques elles-mêmes.

Voici l’ampleur honnête de ce que signifie « exploitation confirmée » dans ce dossier, et il vaut la peine d’être précis, car les éléments disponibles sont plus minces que ne le laisse entendre le titre : aucune source examinée pour cet article, ni l’entrée de la CISA elle-même, ni l’avis de GitLab, ni la couverture de BleepingComputer à ce sujet, ne publie un indicateur de compromission, une victime nommée, ou un quelconque récit au niveau technique de ce que les attaques observées ont réellement fait.[1][2][6] L’article de suivi de BleepingComputer cite les propres publications de détection de menaces de GitLab et le comptage de Shadowserver d’environ 2 800 instances GitLab CE exposées sur Internet, et c’est toute l’étendue du détail public disponible.[6] « Exploitation confirmée » repose ici sur l’inscription de la CISA comme autorité nommée, et non sur des preuves d’attaque que cet article aurait pu examiner de façon indépendante. C’est un fondement légitime pour cette conclusion. C’est aussi le plafond de ce que je peux honnêtement vous dire sur les attaques elles-mêmes.

Le correctif, les règles, et ce qu’il faut vérifier cette semaine

Le correctif est versionné avec précision : 19.2.8, 19.3.5 et 19.4.2, toutes publiées le 12 octobre 2026.[1] Si votre branche 19.3 affiche 19.3.4, cette version a corrigé un bogue sans rapport lié à la page des merge requests, pas cette CVE ; 19.3.5 est celle qu’il vous faut réellement.[8] Parallèlement au correctif, GitLab a publié six nouvelles règles de détection de menaces pour les instances autohébergées, nommées spécifiquement pour ce problème : Onigmo native worker crash, GraphQL cilint hostile regexp, ci regexp oversized non-ascii path, ci regexp guard rejection, ci lint workhorse worker crash et ci lint scripted client error burst.[1] Si votre propre supervision ou les détections de GitLab font apparaître l’une d’elles, traitez-la comme un signal qui mérite d’être suivi, pas comme du bruit.

La politique de divulgation de GitLab publie l’intégralité des détails du suivi des tickets pour une vulnérabilité corrigée 90 jours après la version du correctif, ce qui, par simple calcul, place tout ce qui dépasse le texte de l’avis vers la mi-janvier 2027, une date que GitLab ne donne pas elle-même, mais simplement ce que donne sa propre règle des 90 jours.[1] En attendant, voici ce que les éléments publics permettent réellement de vérifier.

Patch and verify, in order:
  [ ] Confirm the build actually RUNNING, not just what the changelog
      says: 19.2.8 / 19.3.5 / 19.4.2 or later.
  [ ] If self-managed, review sign-up restrictions: is self-registration
      open, and is admin approval of new accounts actually enabled?
  [ ] Review who can create or push to a PUBLIC project on your instance
      -- that setting is the other half of this bug's real exposure.
  [ ] Enable and watch GitLab's six named threat detections for this CVE,
      especially "ci lint workhorse worker crash" and "ci regexp guard
      rejection".
  [ ] Check CI-lint access logs for requests with no auth header paired
      with recently-pushed branches on public projects -- that pairing
      is this chain's fingerprint, a bare HTTP 502 is not.

Une note CVSS évalue la faille. Pas votre instance.

CVE-2026-97229 est une faille critique bien réelle, et les évaluations de gravité de GitLab et de la CISA sont toutes deux justes. Ce que le chiffre seul ne peut pas vous dire, c’est si votre instance est de ce genre grand ouvert pour lequel cette chaîne a été conçue, ou de ce genre où l’inscription est fermée et la visibilité des projets verrouillée. Cette seconde instance est une cible nettement plus réduite, même pour une faille CVSS 10.0 activement exploitée. La gravité note un composant. L’exposition est une propriété de votre configuration, et personne ne la note à votre place.

C’est exactement l’écart que je recherche dans une revue d’application web ou de pipeline CI/CD : pas seulement « est-ce corrigé », mais « étant donné la manière dont cette instance est réellement configurée, qu’est-ce que la moitié non authentifiée d’une faille donnée apporte vraiment ici à un attaquant ». Si vous exploitez GitLab en autohébergement, ou toute surface CI/CD comportant des éléments exposés au public, et que vous préférez que quelqu’un examine cette frontière avec vous plutôt que de vous en tenir à la parole d’une note CVSS, c’est exactement le type d’évaluation que je réalise. Dites-moi comment votre instance est réellement configurée, et nous définirons le périmètre.