Introduction
Une forge GitLab auto-hébergée, c'est bien plus qu'un dépôt de code : c'est le système nerveux d'un pipeline de développement entier. Les secrets CI/CD, les artefacts de build, les webhooks vers la production — tout transite par là. C'est précisément pourquoi le correctif d'urgence publié le 21 octobre 2026 par GitLab mérite une attention immédiate : une faille notée CVSS 10.0 permettait à n'importe qui, sans la moindre authentification, d'exécuter du code arbitraire sur le serveur.
Un débordement d'entier dans un composant embarqué
La vulnérabilité CVE-2026-110264 réside dans Onigmo, le moteur d'expressions régulières que Ruby — et par extension GitLab — embarque nativement. Lorsque GitLab rend un fichier au format Org-mode (.org), il compile les expressions régulières présentes dans certains mots-clés du document. En manipulant un champ #+TODO: avec un nombre de répétitions dépassant 32 767, un attaquant déclenche un débordement d'entier : l'identifiant de répétition passe en négatif, provoquant une écriture hors limites en mémoire. Cette corruption suffit à prendre le contrôle du processus Onigmo — et donc du serveur GitLab lui-même.
Ce qui rend cette faille particulièrement redoutable : aucune authentification n'est requise. Il suffit de faire rendre un fichier .org malicieux par le serveur — via un dépôt public, une issue, ou tout autre mécanisme exposant le rendu de ce format — pour déclencher l'exploit. Un PoC public est déjà disponible.
Douze ans de versions concernées
La vulnérabilité est présente dans toutes les versions de GitLab CE et EE depuis la version 7.0, publiée en 2014. GitLab a publié des correctifs pour l'ensemble des branches encore maintenues : 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 et 18.11.13. L'amplitude des backports témoigne de l'étendue du problème : des installations vieilles de plusieurs années restaient exposées sans que personne ne le sache.
Les instances hébergées sur GitLab.com ont été corrigées en amont, sans intervention requise côté client. L'urgence concerne exclusivement les déploiements self-managed — toutes les organisations ayant choisi d'héberger leur forge sur leur propre infrastructure. Il n'existe aucune mesure de contournement : la mise à jour est la seule issue.
Pourquoi la forge CI/CD est une cible de premier ordre
Compromettre un serveur GitLab ne se limite pas à lire le code source. Un attaquant qui obtient l'exécution de code dispose d'un accès potentiel aux variables CI/CD — qui stockent fréquemment des clés d'API, des identifiants cloud et des tokens de déploiement —, aux artefacts de build, aux clés de signature, et à l'intégralité des pipelines de livraison. La compromission d'une forge peut ainsi devenir le point d'entrée d'une attaque en profondeur sur la chaîne d'approvisionnement logicielle, bien au-delà du périmètre GitLab lui-même.
Pour les équipes qui ne peuvent pas appliquer le correctif immédiatement, GitLab recommande de surveiller deux signaux dans les logs : les crashs du worker natif Onigmo, et les rafales d'erreurs de rendu Org-mode.
La surface d'attaque des dépendances natives
Cette affaire illustre une réalité souvent sous-estimée dans les plateformes DevOps : les composants embarqués — moteurs de rendu, bibliothèques de parsing, interpréteurs — constituent une surface d'attaque peu visible mais structurelle. Onigmo n'est pas un plugin optionnel que l'on aurait pu désactiver ; il est tissé dans le cœur du rendu GitLab depuis ses premières versions.
Pour les équipes de plateforme, c'est un rappel que la gestion des dépendances ne s'arrête pas aux fichiers de manifeste applicatifs : elle doit descendre jusqu'aux composants natifs compilés dans les distributions. Les outils d'analyse de composition logicielle (SCA) et les bulletins de sécurité des éditeurs restent les premiers remparts contre ce type de vulnérabilité enfouie — celle que personne ne surveille parce qu'elle n'apparaît dans aucun lock file.