GitLab : une RCE non authentifiée à 10.0 via le rendu Org-mode

La troisième faille regex de GitLab en un mois, et la pire

Le 21 octobre 2026, GitLab a publié un correctif critique pour les éditions Community et Enterprise auto-hébergées. En tête, CVE-2026-110264, notée 10.0, le maximum. Encore une faille dans le moteur d'expressions régulières, après les deux corruptions mémoire de septembre et le dépassement d'entier du 12 octobre. Mais celle-ci change de catégorie sur deux points qui comptent.

D'abord, elle est non authentifiée. Pas de compte, pas de projet à créer, pas de pipeline à soumettre. Les failles regex précédentes demandaient au moins un accès à faible privilège ; celle-ci se déclenche par le simple rendu d'un contenu que GitLab affiche. Ensuite, elle remonte jusqu'à la version 7.0, sortie en 2014. Douze ans de versions concernées par une seule ligne d'avis. Si vous hébergez un GitLab, quelle que soit son ancienneté, il faut partir du principe qu'il est vulnérable tant qu'il n'est pas sur une version corrigée.

Dernier détail, et pas le moindre : le correctif du 12 octobre ne protège pas contre elle. Les instances mises à jour il y a neuf jours restent exposées.

Les faits, tels que l'avis les pose

Un 10.0 ne laisse aucune marge d'interprétation sur la gravité théorique. Le vecteur le justifie poste par poste : attaque par le réseau (AV:N), complexité faible (AC:L), aucun privilège (PR:N), aucune interaction d'un utilisateur légitime (UI:N), et surtout S:C, le périmètre change. La corruption ne reste pas dans l'application, elle atteint le processus serveur et tout ce qu'il peut toucher. Reste la formule de l'avis, « sous certaines conditions ». GitLab ne détaille pas lesquelles, et nous y revenons plus bas : c'est la seule zone d'ombre d'un avis par ailleurs sans ambiguïté.

Le mécanisme

GitLab rend des contenus que vous déposez dans vos dépôts, vos wikis, vos tickets ou vos extraits de code. Parmi les formats de balisage supportés, il y a Org-mode, le format de notes d'Emacs, reconnu aux fichiers .org. Pour l'afficher en HTML, GitLab passe par la bibliothèque org-ruby.

C'est là que tout se joue. D'après les analyses de détection publiées autour du correctif, et non l'avis lui-même qui reste discret sur ce point, org-ruby construit une expression régulière à partir de certains mots-clés du document, dont le mot-clé #+TODO:, sans assainir ce qu'il y insère. Le contenu de votre fichier Org se retrouve donc directement dans le texte d'une regex, que GitLab compile ensuite avec Onigmo, le moteur d'expressions régulières de Ruby.

Onigmo, en compilant un motif façonné, déborde. Les analyses décrivent un compteur de répétitions trop grand qui fait reboucler un identifiant stocké sur un entier signé de 16 bits ; le calcul de taille qui en découle est faux, le moteur réserve trop peu de mémoire, et l'écriture qui suit sort du tampon prévu. De là, la borne haute décrite est une écriture contrôlée transformée en appel système, exécuté dans le contexte du compte git qui fait tourner GitLab.

Il faut garder la tête froide sur ce dernier saut. Le cœur documenté, c'est le débordement, donc la corruption mémoire et le plantage du worker qui rend la page. L'exécution de code est l'aboutissement que l'avis retient en parlant de RCE, mais le passage de l'un à l'autre dépend de la configuration, du durcissement et du travail d'exploitation, qui n'est pas trivial. Aucun code d'exploitation public ne circulait pour cette CVE à la publication du correctif.

Kill chain

De l'anonyme à l'exécution de code

Phase 1Débordement mémoire

Phase 2Exécution de code (conditionnelle)

Ce que « non authentifié » veut dire ici

La question qui décide de votre exposition réelle : qui, chez vous, peut faire rendre un fichier Org-mode par GitLab sans se connecter ? L'avis dit « sous certaines conditions » et n'énumère pas les chemins. On raisonne donc sur ce que GitLab rend à un visiteur anonyme.

Un projet public suffit : son dépôt, son wiki, ses tickets et ses extraits de code sont lisibles sans compte, et GitLab y rend les fichiers .org. Sur une instance qui autorise l'inscription libre ou la création de projets publics, un attaquant crée lui-même le contenu piégé puis le fait rendre. Sur une instance fermée, il lui faut un projet public préexistant, ou un autre point d'entrée qui déclenche le rendu Org sans session. C'est précisément ce flou que recouvre la formule de l'avis, et c'est la raison pour laquelle il ne faut pas lire « sous certaines conditions » comme « probablement pas chez moi ».

Pourquoi le correctif du 12 octobre ne suffit pas

Neuf jours plus tôt, le 12 octobre, GitLab corrigeait déjà un dépassement d'entier à 10.0 dans le même moteur de regex, CVE-2026-97229, par les versions 19.2.8, 19.3.5 et 19.4.2. De quoi croire le sujet clos. Il ne l'est pas.

Les deux failles partagent la racine, Onigmo et son débordement d'entier, mais pas le point d'entrée. CVE-2026-97229 passait par le compilateur de regex de la chaîne CI/CD : une expression régulière façonnée dans une configuration de pipeline. CVE-2026-110264 passe par le rendu Org-mode. Le correctif du 12 octobre a fermé le chemin CI/CD sans toucher au chemin Org. Résultat : une instance passée en 19.4.2 le 12 octobre reste exposée à la 110264, et doit repasser en 19.4.3.

Timeline

Un mois de failles regex sur GitLab

Les failles authentifiées

1. 23 septembre 2026

   CVE-2026-89078 et CVE-2026-93577

   un double free et un dépassement d'entier, notés 9.9, dans l'évaluation des regex CI/CD. Un compte à faible privilège est requis. Corrigés dans 19.2.7, 19.3.3 et 19.4.1.

Le premier chemin non authentifié

1. 12 octobre 2026

   CVE-2026-97229

   un dépassement d'entier à 10.0 dans le compilateur de regex CI/CD, cette fois non authentifié. Corrigé dans 19.2.8, 19.3.5 et 19.4.2. Un code d'exploitation public circule peu après.

Le rendu Org-mode

1. 21 octobre 2026

   CVE-2026-110264

   un dépassement d'entier à 10.0 dans Onigmo, atteint par le rendu d'un fichier Org-mode, non authentifié, concernant toutes les versions depuis la 7.0. Le correctif du 12 octobre ne le couvre pas. Corrigé dans 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3 et 19.5.1.

Versions concernées

L'avis pose une seule plage continue pour tout l'historique d'avant la 19.0, puis une borne par branche récente. Le correctif est sorti le 21 octobre 2026.

La ligne qui doit retenir l'attention, c'est la première. Tout ce qui tourne sous 18.11.13 est concerné, sans distinction de branche : une 16.x, une 17.x, une 18.4 oubliée. GitLab n'a rétroporté le correctif que sur la dernière 18.11 ; pour une version plus ancienne, la remédiation passe par une montée de version, pas par un simple patch.

Vérifier son exposition

Comme pour les failles regex précédentes, il n'y a pas de test à distance sans risque. Prouver l'exposition supposerait d'envoyer à l'instance le fichier Org façonné, donc de chercher à faire déborder le moteur et planter le worker qui rend la page. C'est exactement le déni de service qu'on veut éviter sur un actif de production. Contrairement à une lecture de fichier qu'on confirme en lisant un fichier public inoffensif, il n'existe ici aucun marqueur bénin qui prouve le débordement sans le provoquer. La version reste le seul juge fiable.

Trois façons de la relever, toutes depuis l'intérieur :

• 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. De l'extérieur, un GitLab moderne ne livre pas son numéro de version à un visiteur anonyme, par prudence. On peut confirmer qu'une instance est bien un GitLab auto-hébergé, et c'est déjà l'essentiel du travail d'inventaire, mais pas lire son niveau de correctif sans authentification. C'est une limite réelle pour tout recensement mené depuis l'extérieur, et c'est pourquoi le vrai sujet n'est pas le test mais la découverte des instances.

Côté détection a posteriori, GitLab a publié deux règles Sigma qui s'appliquent aux journaux applicatifs : « Onigmo native worker crash » et « Org mode render error burst ». Elles ne préviennent pas une exploitation silencieuse réussie, mais elles signalent les plantages et les rafales d'erreurs de rendu qui trahissent les tentatives. Leur absence ne prouve rien ; leur présence, beaucoup.

Remédiation

1. Mettez à jour vers la version corrigée de votre branche : 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3 ou 19.5.1. Y compris si vous avez appliqué le correctif du 12 octobre : une 19.4.2 doit passer en 19.4.3. C'est la seule remédiation qui ferme réellement le chemin Org-mode.
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 de 2019 et qui coche à la fois « non authentifié » et « très en retard ».
3. En attendant la montée de version, réduisez la surface exposée : revoyez quels projets sont publics, coupez l'inscription libre si elle n'est pas nécessaire, et si vous n'utilisez pas Org-mode, sachez qu'il n'existe pas de bascule propre pour le désactiver sans toucher au reste du rendu. La mise à jour reste la réponse.

GitLab, cible récurrente

En un mois, GitLab aura connu une lecture de fichier non authentifiée à 10.0, deux corruptions mémoire authentifiées à 9.9, un dépassement d'entier non authentifié à 10.0 le 12 octobre, et maintenant celui-ci. Le vecteur change à chaque fois, 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 premier choix, et son moteur de regex s'est révélé un gisement de failles.

Un pentest annuel n'attrape aucune de ces failles : une divulgation du 21 octobre 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

Cette faille est non authentifiée, mais sa confirmation à distance passerait par l'exploitation, donc par un risque de plantage que nous refusons de faire courir à un actif de production. Notre scanner ne prétend donc pas prouver l'exploitabilité de l'extérieur. Sa valeur est sur ce qui manque le plus souvent : retrouver l'instance GitLab qu'on avait oubliée, et la marquer comme sensible.

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 à tenir à jour, et surveille en continu pour qu'un nouveau GitLab exposé ou une version en retard déclenche une alerte le jour même. Nous publions aussi le template Nuclei de détection par version pour cette CVE, une détection volontairement non destructive qui situe l'instance sans jamais envoyer la charge.

Questions fréquentes

Faut-il un compte pour exploiter cette faille ?

Non. Le vecteur porte PR:N : aucune authentification n'est requise. C'est ce qui la distingue des deux corruptions mémoire du 23 septembre, qui demandaient un compte à faible privilège. L'avis précise « sous certaines conditions » sans les détailler ; en pratique, la condition la plus évidente est qu'un contenu Org-mode soit rendu à un visiteur anonyme, par exemple via un projet public.

Si j'ai appliqué le correctif du 12 octobre, suis-je protégé ?

Non. Le correctif du 12 octobre (CVE-2026-97229) a fermé le chemin CI/CD du même moteur, pas le chemin Org-mode. Une instance en 19.2.8, 19.3.5 ou 19.4.2 reste exposée à CVE-2026-110264 et doit repasser en 19.2.9, 19.3.6 ou 19.4.3.

Jusqu'à quelle version faut-il remonter dans le temps ?

Toutes les versions depuis la 7.0, sortie en 2014, sont concernées. Il n'y a pas de branche ancienne épargnée. Pour tout ce qui est antérieur à la 18.11, le correctif unique est la 18.11.13 ; une 16.x ou une 17.x doit donc monter de version, pas seulement appliquer un patch sur place.

Est-elle activement exploitée ?

À la publication du correctif, aucune exploitation dans la nature n'était rapportée, aucun code d'exploitation public ne circulait pour cette CVE, et elle ne figurait pas au catalogue des failles activement exploitées de la CISA. Passer du débordement documenté à une exécution de code fiable demande un travail 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, et un PoC existe déjà pour la faille sœur du 12 octobre.

Comment vérifier ma version sans risquer de planter l'instance ?

Par la version, jamais par un test actif. Sur le serveur, sudo gitlab-rake gitlab:env:info donne la version exacte ; en interface, /help l'affiche une fois connecté ; par l'API, GET /api/v4/version la renvoie avec un jeton. Envoyer un fichier Org façonné pour « voir si ça passe » revient à tenter l'exploitation, avec le déni de service au bout. On ne le fait pas sur un actif de production.

Ce qu'il faut retenir

Un contenu rendu par le serveur est une entrée comme une autre. Dès qu'un mot-clé de document se retrouve, non filtré, dans le texte d'une expression régulière, le moteur qui la compile doit borner ses cas limites, sinon il finit par écrire là où il ne faut pas. Pour vous, 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. Avec une faille non authentifiée qui remonte à 2014, chaque GitLab oublié est une porte ouverte. C'est un travail d'inventaire, pas d'exploit.

Vérifiez votre exposition sur flawfence.com