Faille GitLab - CVE-2026-110264 - exécution de code sans authentification

La faille GitLab CVE-2026-110264 peut permettre une exécution de code sur le serveur sans authentification. GitLab la classe critique, avec un score CVSS de 10/10, et publie les correctifs ce 21 octobre 2026.

Les éditions Community Edition (CE) et Enterprise Edition (EE) sont concernées. Le défaut touche la compilation d’une expression régulière spécialement conçue : un dépassement d’entier peut mener à une exécution de code, sous certaines conditions. Source : bulletin de sécurité GitLab.

Pour une instance auto-hébergée, la priorité est claire : identifier la version réellement exécutée et engager la mise à jour. Un GitLab ne contient pas seulement des dépôts. Selon son utilisation, il participe aussi aux tests, à la construction des applications et à leur déploiement en production.

Une faille sur le serveur, pas seulement sur les runners

Il faut distinguer deux composants : GitLab organise les projets et les pipelines ; les runners exécutent les tâches qui leur sont confiées. Ici, le correctif à appliquer concerne le serveur GitLab. Actualiser uniquement les runners ne traite donc pas cette vulnérabilité.

L’enjeu dépasse la disponibilité de l’interface web. Dans une chaîne de déploiement, les accès et les secrets associés aux projets peuvent ouvrir des portes vers d’autres environnements. Nous recommandons d’évaluer cette exposition en regardant les droits réellement accordés : déploiement sur la production, publication d’images, accès à un registre ou appels aux API d’un hébergeur.

Une compromission du serveur ne signifie pas automatiquement une compromission de toute la production. Mais plus la chaîne dispose de privilèges étendus, plus les conséquences potentielles méritent d’être examinées. La séparation des accès de déploiement fait justement partie des mesures de sécurisation documentées par GitLab.

Cet enjeu accompagne aussi le choix d’une chaîne CI/CD GitLab sur une infrastructure maîtrisée : garder la main sur ses outils implique d’en assurer la maintenance.

Quelles versions corrigent la CVE-2026-110264 ?

Le périmètre annoncé commence à GitLab 7.0. Les seuils corrigés sont les suivants :

Branche	Versions vulnérables	Version corrigée
7.0 à 18.11	Avant 18.11.13	18.11.13
19.0	Avant 19.0.10	19.0.10
19.1	Avant 19.1.9	19.1.9
19.2	Avant 19.2.9	19.2.9
19.3	Avant 19.3.6	19.3.6
19.4	Avant 19.4.3	19.4.3
19.5	Avant 19.5.1	19.5.1

GitLab.com et GitLab Dedicated sont annoncés corrigés par l’éditeur. Source : publication officielle des correctifs.

Pour une installation ancienne, ce tableau donne une cible de sécurité, pas l’autorisation de sauter toutes les étapes de migration. Le chemin de mise à niveau GitLab reste à respecter. Par ailleurs, un correctif exceptionnel sur une ancienne branche ne remplace pas le retour vers une version régulièrement maintenue.

Vérifier la version réellement en service

Sur une installation utilisant le paquet Linux GitLab, cette commande affiche les informations de l’instance :

sudo gitlab-rake gitlab:env:info

Avec l’image Docker officielle, si le conteneur s’appelle gitlab :

docker exec gitlab gitlab-rake gitlab:env:info

Il faut lire la version dans la section GitLab information, et non celle de Ruby ou de Git. Sur une architecture distribuée, exécuter ce contrôle sur les nœuds applicatifs Rails. Source : tâches de maintenance GitLab.

Modifier un tag dans un fichier Compose ne prouve pas que le serveur a été mis à jour. Le conteneur en cours d’exécution doit avoir été remplacé par celui utilisant l’image corrigée. Pour la production, GitLab recommande de fixer explicitement la version de l’image, plutôt que de dépendre d’un tag mouvant.

Corriger vite, avec un chemin de reprise

Nous recommandons de traiter l’opération comme une intervention prioritaire, avec un périmètre court et vérifiable :

1. Recenser les instances et leurs versions, y compris les plateformes secondaires ou de recette encore accessibles.
2. Choisir la cible et vérifier les étapes intermédiaires, ainsi que les notes propres au mode de déploiement.
3. Disposer d’une sauvegarde exploitable, sans oublier les fichiers de configuration et les secrets nécessaires à une restauration.
4. Préparer l’interruption et les pipelines en cours, puis appliquer la procédure adaptée : paquet Linux, Docker ou Kubernetes.
5. Contrôler après redémarrage : version, migrations, accès aux dépôts et exécution d’un pipeline représentatif.

La préparation officielle d’une mise à niveau GitLab détaille notamment les sauvegardes, le retour arrière, les migrations et la gestion des tâches CI/CD. Une instance à nœud unique nécessite une interruption ; une architecture multinœud ne permet un déploiement sans coupure qu’en suivant la procédure correspondante.

Si la mise à jour ne peut pas être engagée immédiatement, nous recommandons de réduire temporairement l’exposition réseau aux seuls accès nécessaires. Cela réduit les possibilités d’accès ; ce n’est ni un correctif ni une garantie de protection contre la faille.

Examiner les journaux, pas seulement le numéro de version

GitLab signale deux détections : « Onigmo native worker crash » et « Org mode render error burst ». Les ressources sont liées depuis la section consacrée aux tentatives d’exploitation.

Ces signaux orientent l’analyse. Une erreur isolée ne prouve pas une compromission, et leur absence ne certifie pas que le serveur est sain. Notre recommandation : conserver les journaux disponibles et rapprocher les événements applicatifs des accès réseau et des modifications inhabituelles.

En présence d’indices sérieux, il faut poursuivre au-delà du patch : examiner les comptes, les changements de configuration et les accès de déploiement ; révoquer ou renouveler les secrets exposés en tenant compte de leurs dépendances. La documentation de réponse à incident GitLab fournit les vérifications à adapter au contexte.

Auto-héberger GitLab implique d’exploiter toute la chaîne

Le sujet n’est pas de renoncer à l’auto-hébergement. Une plateforme GitLab maîtrisée permet de choisir où résident les dépôts, comment les accès sont organisés et quels environnements peuvent être déployés. Cette autonomie repose sur une exploitation suivie : veille, mises à jour, sauvegardes, supervision et tests de reprise.

Chez Forget About IT, nous intégrons ces opérations à l’infogérance des infrastructures Linux. L’objectif : réduire le délai entre une alerte utile, l’identification du périmètre concerné et une correction effectivement validée.

Votre GitLab est devenu une pièce critique de vos déploiements ? Faisons le point sur sa maintenance et ses dépendances.

Questions fréquentes

Mettre à jour GitLab Runner suffit-il ?

Non. Il faut mettre à jour le serveur GitLab concerné. Les runners constituent une autre composante de la chaîne CI/CD : leur mise à jour ne remplace pas celle de l’instance GitLab.

Peut-on passer directement d’une ancienne version à la dernière ?

Pas systématiquement. GitLab impose des étapes intermédiaires pour certains parcours de mise à niveau. Il faut vérifier le chemin officiel et laisser les migrations en arrière-plan se terminer entre les étapes requises.

Le correctif suffit-il si le serveur a déjà été compromis ?

Non. Corriger la vulnérabilité ne retire pas une éventuelle persistance et ne révoque pas les secrets déjà dérobés. Une suspicion de compromission nécessite une investigation et le traitement des accès exposés.