RCE GitLab via Oj : une chaîne de corruption mémoire cachée dans un patch non-sécurité
> En bref : Une chaîne de RCE GitLab bâtie sur deux bugs de corruption mémoire dans Oj (un parser JSON Ruby) permet à tout utilisateur authentifié capable de pousser dans un projet de lancer des commandes en tant que git sur GitLab auto-hébergé. Corrigé dans 18.10.8, 18.11.5 et 19.0.2 — mais le correctif du 10 juin a été classé en bug fixes, pas en sécurité, sans CVE. depthfirst a publié un PoC fonctionnel le 24 juillet.
Pourquoi ça vous concerne
GitLab, c'est l'endroit où vivent votre code source, vos secrets CI/CD et vos deploy keys. Une compromission de GitLab auto-hébergé est un incident supply chain : l'attaquant récupère votre code et votre pipeline en un seul mouvement. Si vous auto-hébergez GitLab pour des raisons de souveraineté ou de coût (beaucoup d'éditeurs SaaS français le font), cette chaîne atterrit directement sur votre infrastructure.
Le détail le plus gênant n'est pas le bug en lui-même — c'est que le correctif est sorti six semaines avant le PoC, et la plupart des opérateurs n'ont jamais su qu'il avait un enjeu sécurité. GitLab a listé le bump Oj 3.17.3 en bug fixes. Pas de CVE, pas de CVSS, pas d'advisory. Les équipes qui trient les releases selon la table sécurité n'avaient aucun signal pour monter de version en urgence.
La chaîne en termes simples
Le renderer de notebooks de GitLab (ipynbdiff) passe le JSON .ipynb contrôlé par le dépôt à Oj::Parser.usual.parse dans un worker Puma longue durée. Deux bugs Oj font fonctionner la chaîne :
start du parser.L'attaquant commit un notebook Jupyter forgé et ouvre son diff de commit. Ça leak un pointeur heap. En répétant assez de fois pour localiser libc en mémoire, deux notebooks supplémentaires déclenchent le payload en pointant le callback vers system(). Pas de droits admin, pas d'accès CI/runner, pas d'interaction victime, pas d'accès au projet d'un autre.
Les versions affectées et le piège Helm
Tous les tiers sont affectés, CE et EE, Free jusqu'à Ultimate :
Le piège : si vous déployez GitLab via Helm ou l'Operator, vérifiez la version GitLab dans l'image Webservice qui fait tourner Puma, pas la version du chart ou de l'Operator. Tout ce qui est en 15.2 à 18.9 n'a pas de backport — ces lignes sont hors des trains de patch sécurité-maintenus par GitLab, donc ces installs doivent passer à une release supportée.
Ce qu'il faut faire
git atteignent le code source, les secrets Rails, les identifiants de service et les données CI/CD.La leçon plus large : les correctifs sécurité qui n'en ont pas l'air
Le takeaway le plus important pour une équipe ops est procédural. Tous les correctifs sécurité ne sont pas publiés comme tels. La revue Oj plus large de depthfirst a produit neuf autres advisories CVE, aucun n'est cette chaîne. Le correctif GitLab est passé par HackerOne mais a été classé en bug fix dans les release notes. Votre process de patch ne peut pas se reposer uniquement sur la table « security fixes » — il doit trier les bumps de dépendances sur les parsers sécurité-sensibles (Oj, libxml2, Jackson, Fastjson) comme si c'étaient des CVE même quand aucune CVE n'est attachée. C'est comme ça que vous auriez attrapé ça le 10 juin plutôt que le 24 juillet.
Vous éditez un logiciel RH, paie ou recrutement ? CleanIssue réalise des audits de sécurité pour SaaS RH en conditions réelles, sans accès au code. Pour une première lecture de votre exposition, commencez par une revue externe de votre application.
Articles liés
Trois analyses proches pour continuer la lecture sur la meme surface de risque.
GitLab et CVE-2023-7028 : pourquoi cette faille de reset de mot de passe a inquiété tout le monde
CVE-2023-7028 permettait un takeover via reset de mot de passe sans interaction utilisateur dans certaines versions de GitLab. Voici pourquoi cette faille a tant marqué.
Gitea CVE-2026-20896 : un contournement d'authentification en un header, livré dans l'image Docker officielle
L'image Docker officielle de Gitea livrait `REVERSE_PROXY_TRUSTED_PROXIES=*`, donc avec l'authentification reverse-proxy activée, un client Internet non authentifié devenait celui qu'il prétendait être via le header X-WEBAUTH-USER. CVSS 9.8, exploitation active. Correctif : Gitea 1.26.3 / 1.26.4.
Supply chain : npm, composer, pip, quand vos dépendances sont l'attaque
Les attaques supply chain via les gestionnaires de paquets : typosquatting, dependency confusion, compromission de mainteneurs, et comment s'en protéger.
Sources
Services associés
Si ce sujet reflète un risque concret sur votre stack, voici les audits CleanIssue les plus pertinents.