GitLab corrige une faille critique d'exécution de code à distance affectant toutes les versions depuis 2014

GitLab a émis des mises à jour de sécurité d'urgence le 21 octobre pour remédier à une vulnérabilité critique permettant aux attaquants d'exécuter du code arbitraire sur des serveurs auto-hébergés sans authentification. La faille, identifiée sous le nom de CVE-2026-110264, affiche un score parfait de 10.0 sur le système de notation Common Vulnerability Scoring System (CVSS) et impacte chaque version du logiciel depuis la version 7.0, lancée en 2014.

Ce correctif est urgent même pour les administrateurs ayant appliqué la mise à jour de sécurité précédente le 12 octobre. Ce premier correctif ne couvrait que les versions 19.2 et ultérieures, laissant les installations plus anciennes exposées, tandis que les nouvelles versions corrigées se situent juste un niveau de patch au-dessus de ces récentes publications. Par conséquent, de nombreux systèmes considérés comme sécurisés restent vulnérables tant que cette dernière série de mises à jour n'est pas appliquée.

Que s'est-il passé ?

La vulnérabilité provient d'un débordement d'entier dans Onigmo, le moteur d'expressions régulières intégré à Ruby que GitLab inclut et patche dans ses propres distributions. Lorsque le compilateur traite une expression régulière spécialement conçue, il peut déclencher ce débordement, permettant potentiellement à un utilisateur non authentifié d'exécuter du code sur le serveur hôte. GitLab n'a pas divulgué les conditions spécifiques requises pour exploiter la faille, ce qui signifie que les administrateurs ne peuvent pas compter sur des modifications de configuration pour atténuer le risque.

GitLab a traité le problème en publiant des versions corrigées simultanément sur sept branches de release différentes. Cette portée large inclut quatre versions antérieures à la politique de support standard de GitLab, qui couvre généralement uniquement la version actuelle et les deux versions mensuelles précédentes. L'entreprise a déclaré avoir réservé cet effort exceptionnel de backporting aux problèmes graves, reconnaissant la nature répandue de la faiblesse sous-jacente du moteur.

Bien que GitLab signale qu'il n'y a aucune preuve que cette faille spécifique ait été exploitée dans la nature, et qu'elle n'apparaisse pas encore dans le catalogue CISA américain des vulnérabilités connues et exploitées, le profil de risque est extrême. Le même chercheur, connu sous le pseudonyme joaxcar, a signalé trois autres failles d'exécution de code dans le même moteur regex au cours du mois écoulé. Contrairement à ces problèmes précédents, limités aux nouvelles versions ou nécessitant un accès authentifié, cette vulnérabilité remonte à plus d'une décennie d'histoire logicielle et ne nécessite aucune connexion.

Détails clés

• ID de la vulnérabilité : CVE-2026-110264, notée 10.0 (Critique) sur l'échelle CVSS.
• Versions affectées : Toutes les instances GitLab auto-hébergées de la version 7.0 (2014) jusqu'aux dernières versions pré-patch.
• Cause racine : Débordement d'entier dans le compilateur d'expressions régulières Onigmo lors du traitement d'expressions élaborées.
• Vecteur d'attaque : Exécution de code à distance sans authentification ; aucune connexion ni interaction utilisateur n'est requise.
• Disponibilité du correctif : Patches publiés pour les versions 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 et 18.11.13.
• Détection : GitLab a fourni deux règles de détection au format Sigma, "Onigmo native worker crash" et "Org mode render error burst", pour surveiller les logs applicatifs.

Contexte

Les expressions régulières sont des motifs utilisés pour faire correspondre des combinaisons de caractères dans des chaînes de texte, largement employées en programmation pour la validation de données et les fonctions de recherche. Le moteur qui traite ces motifs, ici Onigmo, doit gérer efficacement des entrées complexes. Un débordement d'entier se produit lorsqu'un calcul produit un nombre supérieur à l'espace de stockage alloué, faisant basculer la valeur vers un nombre négatif ou un petit nombre positif. Dans un contexte de sécurité, cela peut corrompre les structures mémoire, permettant aux attaquants d'injecter et d'exécuter du code malveillant.

GitLab intègre sa propre version de l'interpréteur Ruby et de ses bibliothèques associées, y compris Onigmo. Comme ce moteur est embarqué dans chaque version de GitLab depuis la 7.0, la vulnérabilité est omniprésente dans l'ensemble du parc installé d'instances auto-hébergées. Les utilisateurs hébergés dans le cloud sur GitLab.com ne sont pas affectés, car le fournisseur gère l'infrastructure sous-jacente et a déjà déployé le correctif.

Pourquoi c'est important

Pour les équipes exécutant des instances GitLab auto-hébergées, cet incident met en lumière les risques cachés liés aux dépendances logicielles à long terme. Même si une organisation maintient un calendrier de patching rigoureux pour les versions récentes, la profondeur de cette vulnérabilité signifie que les instances legacy ou celles suivant des pistes de support étendues sont critiques exposées. Le fait que le patch du 12 octobre ne couvrait pas les versions plus anciennes crée un fossé dangereux où les administrateurs pourraient croire être protégés alors qu'ils ne le sont pas.

L'impact opérationnel de l'application de ce correctif n'est pas négligeable. Les mises à niveau vers les versions 19.4.3 et 19.3.6 incluent des modifications du schéma de base de données qui nécessitent une indisponibilité sur les serveurs mono-nœud. Pour les environnements haute disponibilité, cela impose une planification minutieuse utilisant les procédures de mise à niveau sans interruption de service de GitLab pour les configurations multi-nœuds. Les équipes doivent équilibrer la menace immédiate pour la sécurité contre la perturbation potentielle du service causée par le processus de patching.

De plus, l'absence de solution de contournement signifie qu'il n'y a pas de mesure provisoire. Les administrateurs ne peuvent pas simplement désactiver une fonctionnalité ou ajuster un paramètre pour bloquer le vecteur d'attaque. La seule protection définitive consiste à mettre à niveau vers l'une des versions patchées. Cela place une pression sur les équipes DevOps pour prioriser cette tâche de maintenance au-dessus des autres éléments de la feuille de route, retardant potentiellement le développement de fonctionnalités ou d'autres améliorations d'infrastructure.

Ce que vous pouvez faire

• Identifiez votre version actuelle de GitLab et croisez-la avec le tableau des versions corrigées pour déterminer le chemin de mise à niveau requis.
• Planifiez une fenêtre de maintenance immédiate pour les instances mono-nœud, en tenant compte des temps d'arrêt potentiels dus aux migrations de base de données.
• Déployez les règles de détection Sigma fournies dans votre système de gestion des logs pour surveiller les événements "Onigmo native worker crash" ou "Org mode render error burst".
• Vérifiez que les clusters multi-nœuds sont configurés pour les mises à niveau sans interruption avant d'initier le processus de patching afin d'éviter toute interruption de service.
• Passez en revue les logs d'accès pour détecter toute activité inhabituelle avant le patching, bien que l'exploitation puisse laisser peu de traces sans les règles de détection spécifiques.
• Communiquez l'urgence aux parties prenantes, en soulignant que ce correctif adresse une faille présente dans toutes les versions depuis 2014, et non seulement dans les releases récentes.