Alerte GitLab : exploit public pour une vulnérabilité RCE critique, le correctif était caché dans un bogue ordinaire

Introduction

Le 24 juillet 2026, l'équipe de recherche depthfirst a publié un exploit complet pour une vulnérabilité critique d'exécution de code à distance (RCE) affectant les instances auto-hébergées de GitLab Community Edition (CE) et Enterprise Edition (EE). Cette faille permet à un utilisateur authentifié disposant de permissions de push d'obtenir un shell sur le serveur avec les privilèges du processus git, simplement en téléchargeant un notebook Jupyter malveillant. Le plus alarmant est que GitLab avait déjà déployé un correctif le 10 juin dernier, mais l'avait classifié comme un simple « correctif de bogue » ordinaire, l'omettant du tableau des mises à jour de sécurité. Par conséquent, de nombreux administrateurs pourraient ne pas avoir appliqué le patch, laissant des milliers d'instances exposées à une attaque désormais facilitée par la disponibilité publique du code offensif.

Analyse technique

La vulnérabilité réside dans deux bogues distincts de corruption de mémoire dans l'analyseur JSON natif Oj (Optimized JSON), une gemme Ruby largement utilisée. Les versions d'Oj antérieures à la 3.17.3 ne gèrent pas correctement certaines structures JSON complexes, provoquant des dépassements de tampon et des lectures hors limites. Dans GitLab, le composant ipynbdiff – chargé d'afficher les différences entre les versions de notebooks Jupyter (fichiers .ipynb) – utilise en interne Oj::Parser.usual.parse pour traiter le contenu des fichiers. Un attaquant disposant d'un accès en écriture à un dépôt peut créer un notebook spécialement conçu et le télécharger via un push. Lorsque n'importe quel utilisateur (y compris l'attaquant lui-même) visualise le diff du notebook dans l'interface web, l'analyseur vulnérable est exécuté et la charge utile contenue dans le fichier prend le contrôle.

L'exploit publié par depthfirst opère en deux phases :

1. Fuite de mémoire : en exploitant le premier bogue, la charge utile force l'analyseur à révéler des adresses mémoire, contournant l'ASLR (Address Space Layout Randomization).
2. Exécution arbitraire : grâce à une technique de heap-spraying, un shellcode est injecté, modifiant le flux d'exécution du processus Puma (le serveur d'application de GitLab) pour exécuter des commandes choisies par l'attaquant.

L'exploit est optimisé pour GitLab 18.11.3 sur architecture x86-64. Sur les installations fraîches, le processus ne prend que quelques minutes, tandis que sur les serveurs en production depuis longtemps, il peut nécessiter plusieurs heures en raison de la fragmentation de la mémoire heap. L'adaptation à d'autres builds x86-64 est relativement simple (nécessitant uniquement la mise à jour des offsets et des gadgets ROP), tandis que le portage vers ARM64 implique une réécriture substantielle.

Les versions GitLab vulnérables sont :

• de la 15.2.0 à la 18.10.7
• de la 18.11.0 à la 18.11.4
• de la 19.0.0 à la 19.0.1

Les correctifs ont été introduits avec la publication d'Oj 3.17.3 (4 juin 2026) et intégrés dans les versions suivantes de GitLab : 18.10.8, 18.11.5 et 19.0.2. En interne, GitLab a également modifié ipynbdiff pour utiliser des analyseurs plus robustes, éliminant ainsi le vecteur d'attaque.

Impact

Obtenir un shell en tant qu'utilisateur git sur le serveur GitLab revient à compromettre presque totalement la plateforme. L'attaquant peut :

• Lire et modifier l'intégralité du code source hébergé.
• Accéder aux secrets Rails (clés de chiffrement, jetons de session) et aux informations d'identification des services (base de données, intégrations externes).
• Collecter les variables d'environnement CI/CD, les jetons d'accès, et potentiellement se déplacer latéralement vers d'autres services accessibles depuis l'hôte.
• Modifier les pipelines CI/CD pour déployer des charges utiles malveillantes ou exfiltrer des données à grande échelle.

Même si le processus attaqué est confiné à l'utilisateur git, l'ampleur des dégâts dépend de l'isolation du conteneur ou de la machine virtuelle sur laquelle GitLab s'exécute. Les instances fonctionnant sur des versions qui ne sont plus maintenues (de la 15.2 à la 18.9) ne reçoivent pas de portages (backports), et restent donc vulnérables sans aucun correctif officiel, à moins d'une migration forcée vers une version prise en charge. Au 24 juillet, aucune attaque active n'avait été signalée dans la nature, mais la publication de l'exploit modifie radicalement le paysage des menaces.

Atténuation

La priorité absolue est d'appliquer immédiatement la mise à jour vers l'une des versions contenant le correctif :

• GitLab 18.10.8
• GitLab 18.11.5
• GitLab 19.0.2 (ou versions ultérieures)

Les administrateurs qui se fient uniquement au tableau récapitulatif des « correctifs de sécurité » dans les annonces de version pourraient ne pas avoir installé le patch du 10 juin, car GitLab l'a étiqueté comme un « correctif de bogue ». Il est donc recommandé de vérifier manuellement la version en cours d'utilisation, en particulier dans les environnements appliquant des politiques de mise à jour sélectives.

Pour les déploiements via Helm ou Operator sur Kubernetes, il est essentiel de vérifier la version de l'image du service Webservice (qui exécute Puma) et non celle du chart ou de l'Operator, car cette dernière pourrait masquer un composant obsolète.

Il n'existe pas de contournement officiel ou validé pour ceux qui ne peuvent pas mettre à jour immédiatement. Restreindre l'accès aux dépôts et au rendu des diffs de notebooks aux seuls utilisateurs de confiance réduit la surface d'attaque, mais GitLab ne fournit pas d'option documentée pour désactiver complètement le chemin vulnérable. Pour des indications spécifiques, il est conseillé de contacter le support GitLab.

FAQ

1. Quelles versions de GitLab sont exactement concernées ?
Toutes les versions auto-hébergées depuis la 15.2.0 jusqu'à la 18.10.7, de la 18.11.0 à la 18.11.4, et de la 19.0.0 à la 19.0.1 sont vulnérables. Les versions antérieures à la 15.2.0 utilisent des analyseurs différents et ne sont pas exposées. Les versions 18.10.8, 18.11.5, 19.0.2 et suivantes contiennent le correctif.

2. Comment puis-je vérifier si mon instance a déjà été compromise ?
Pour le moment, aucun indicateur de compromission (IoC) public n'a été diffusé. Cependant, étant donné la nature de l'attaque (exécution de commandes arbitraires en tant qu'utilisateur git), il est conseillé de surveiller les journaux système pour détecter des processus inhabituels, des connexions réseau sortantes anormales ou des modifications inattendues des fichiers de configuration de GitLab. L'absence de signalement ne garantit pas que le système est sain : une mise à jour rapide reste la contre-mesure essentielle.

3. Pourquoi GitLab n'a-t-il pas émis d'alerte de sécurité avec un CVE ?
Au moment de la publication de l'exploit, GitLab n'avait pas encore commenté le choix de classer le correctif comme un « bogue ordinaire ». Habituellement, les vulnérabilités de cette gravité reçoivent un identifiant CVE et sont listées dans la section sécurité des annonces de version. Ce manque de transparence a probablement prolongé la période d'exposition pour de nombreux administrateurs. Des communications officielles supplémentaires sont attendues.