GitLab RCE via Oj : chaîne notebook, correctif silencieux

Que permet cette chaîne GitLab ?

Selon depthfirst et The Hacker News, le moteur de rendu de notebooks Jupyter de GitLab (ipynbdiff) passe le JSON d'un fichier .ipynb contrôlé par le dépôt à Oj::Parser.usual.parse, dans un worker Puma de longue durée. Deux bugs Oj s'enchaînent : un dépassement d'une pile d'imbrication à taille fixe qui finit par contrôler le rappel start de l'analyseur, et une troncature d'une clé d'objet très longue en un champ signé de 16 bits, qui renvoie un pointeur de tas vivant restitué dans l'affichage du diff. Après plusieurs essais pour localiser la bibliothèque C en mémoire, des notebooks supplémentaires déclenchent l'exécution de commandes.

Il n'y a besoin ni de droits d'administration, ni d'accès à l'intégration continue ou aux runners, ni d'interaction d'une victime, ni d'accès au projet d'un autre utilisateur : un droit de push et la consultation d'un diff de commit suffisent.

Quelles versions sont concernées ?

Toutes les éditions CE et EE de GitLab :

• 15.2.0 à 18.10.7, corrigé en 18.10.8 ;
• 18.11.0 à 18.11.4, corrigé en 18.11.5 ;
• 19.0.0 à 19.0.1, corrigé en 19.0.2.

La gem Oj est touchée de la 3.13.0 à la 3.17.1 et corrigée en 3.17.3 (la 3.17.2 ne contient pas les deux correctifs). GitLab 15.1 et antérieurs utilisaient JSON.parse sur ce chemin et sont hors de la chaîne. GitLab.com était déjà corrigé et les clients Dedicated n'avaient pas d'action à mener. Les versions 15.2 à 18.9 n'ont pas de rétroportage : elles doivent passer à une version supportée.

Avec Helm ou l'Operator, vérifiez la version de GitLab dans l'image Webservice qui fait tourner Puma, pas celle du chart.

Pourquoi le correctif est-il passé inaperçu ?

La chronologie publiée par depthfirst : signalement à Oj le 21 mai 2026, correctifs fusionnés le 27 mai, Oj 3.17.3 publié le 4 juin, signalement à GitLab le 5 juin, confirmation le 8 juin, correctifs de GitLab le 10 juin. Pourtant, la montée de version d'Oj figurait dans la section des corrections de bugs de la version du 10 juin, sans CVE ni score, et les notes ne mentionnent pas la chaîne. Les équipes qui trient les mises à jour sur la table des correctifs de sécurité n'avaient aucun signal d'urgence ; l'exploit public est arrivé six semaines plus tard.

Comment détecter une exposition ou une exploitation ?

1. Relevez la version de GitLab (pied de page de l'interface ou gitlab-rake gitlab:env:info) et comparez-la aux versions corrigées.
2. Auditez qui peut pousser dans vos projets, en particulier les contributeurs externes et les comptes de service.
3. Cherchez dans les journaux d'accès des consultations de diffs de notebooks et de commits inhabituels, et des redémarrages de workers Puma : la phase de recherche mémoire dure plusieurs minutes et laisse des traces.
4. Cherchez les commandes lancées sous l'utilisateur git : processus fils inattendus du worker, connexions sortantes, nouveaux fichiers.

Comment corriger ?

Passez à 18.10.8, 18.11.5 ou 19.0.2. Aucune mesure de contournement validée n'est proposée par GitLab ou depthfirst pour les exploitants qui ne peuvent pas mettre à jour. Tant que vous n'êtes pas à jour, resserrez les droits de push. Si une exposition est plausible, traitez comme exposés les secrets de l'instance : variables CI/CD, clés de déploiement, jetons d'enregistrement de runners, secrets Rails et identifiants de service, puis faites-les tourner.

Que change l'accès d'un agent IA à GitLab ?

Le prérequis de la chaîne est « un utilisateur authentifié qui peut pousser ». Or les agents de programmation en ont de plus en plus le droit : un agent ouvre des branches, pousse des commits, ajoute des notebooks et des fichiers de données, parfois depuis un compte de service. Si ce compte est détourné par une injection de prompt (OWASP LLM01) dans une issue, une demande de fusion ou un fichier lu, l'attaquant obtient le seul prérequis nécessaire. L'agent lui-même peut pousser le fichier piégé, sans qu'un humain relise un notebook JSON.

GitLab est aussi l'endroit où se concentrent les secrets : variables CI/CD, clés de déploiement, jetons d'API. Une exécution de code sur l'instance les remet à l'attaquant, donc remet les outils auxquels les agents CI sont connectés (LLM02, LLM06). Voir l'affaire voisine Azure DevOps MCP et le détournement par commentaire de PR et la sécurité MCP.

Le défaut de gouvernance se transpose aussi : un robot de mise à jour des dépendances ou un agent qui trie les notes de version applique des mises à niveau selon l'étiquette « sécurité ». Ici, cette étiquette manquait. Traitez les mises à jour d'analyseurs sensibles (JSON, XML, images) comme des correctifs de sécurité, même sans CVE. Les contrôles utiles côté agent : droits de push limités à des branches de travail, protection des branches principales, revue humaine obligatoire des fichiers binaires ou structurés, secrets hors de la portée de l'agent, et validation humaine des fusions. Sur la chaîne GitLab via Oj, voir aussi la sécurité des agents IA.

Comment trier les mises à jour qui n'ont pas de CVE ?

Ajoutez à votre processus une règle simple : toute montée de version d'une bibliothèque qui analyse des données non fiables (JSON, XML, YAML, images, archives, PDF) est examinée comme un correctif de sécurité potentiel. Lisez le journal des modifications de la dépendance et les tickets associés, pas seulement la table de sécurité de l'éditeur. Quand un composant critique comme GitLab embarque la dépendance, suivez aussi ses publications de correctifs de bugs sur les trains maintenus, et fixez un délai maximal entre une publication et son déploiement.

Que vérifier côté agent avec la chaîne GitLab via Oj ?

Un test de red team d'agent place une instruction piégée dans une issue ou un fichier que l'agent de code lit, et observe ce qu'il pousse, avec quels droits et quels secrets il voit. Côté offre, le Red Team Agent Express regarde si un notebook piégé peut mener un agent GitLab jusqu'à l'exécution de code (5 jours, 1 900 €). La méthode détaille la démarche.

Quelle leçon en tirer ?

Tous les correctifs de sécurité ne sont pas annoncés comme tels. Triez les montées de version des composants qui analysent des données non fiables comme des correctifs de sécurité, et considérez chaque compte capable de pousser du code, humain ou agent, comme un point d'entrée.