CVE-2026-110264 : faille critique GitLab notée 10/10, mettez à jour immédiatement

Le 21 octobre 2026, GitLab a publié en urgence sept versions correctives pour CVE-2026-110264, une faille notée 10 sur 10 (CVSS v3.1, vecteur AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H). Un attaquant non authentifié peut exécuter du code arbitraire sur le serveur distant en déposant un fichier Org-mode piégé dans un dépôt, une issue ou une merge request. Toutes les installations auto-hébergées de GitLab Community Edition et Enterprise Edition depuis la version 7.0 (2014) sont concernées : douze ans de versions vulnérables. Les administrateurs qui hébergent GitLab sur un VPS Linux, un serveur dédié ou une machine virtuelle doivent appliquer la mise à jour sans attendre.

Sources : avis de sécurité GitLab du 21 octobre 2026, rapports ThreatWire et CybersecurityNews.

Ce qu'il faut retenir

• Qui est touché : toute instance GitLab CE ou EE auto-hébergée, de la version 7.0 à la 19.5.0 incluse. Installations Omnibus (package système), Docker, Helm (Kubernetes) et compilées depuis les sources : toutes sont vulnérables, quel que soit le système d'exploitation ou la méthode de déploiement.
• Ce que risque le serveur : exécution de code à distance (RCE) sans authentification, sous l'utilisateur git. Un attaquant peut prendre le contrôle du serveur distant : code source, scripts CI/CD, variables d'environnement, clés de déploiement, tokens d'accès aux environnements de production.
• La correction : mettre à jour vers GitLab 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 ou 18.11.13 selon votre branche. Une migration est nécessaire si votre instance est sur une version antérieure à 18.11.
• GitLab.com (SaaS) : déjà corrigé par GitLab, aucune action de votre part.
• Pas d'exploit public connu au 23 octobre 2026. Les détails techniques complets restent sous embargo jusqu'en janvier 2027.

Comment fonctionne la faille

GitLab affiche les fichiers au format Org-mode (.org) via la bibliothèque Ruby org-ruby. Quand un fichier contient une ligne #+TODO:, le gem injecte le mot-clé brut dans une expression régulière compilée par Onigmo, le moteur regex intégré à Ruby.

Le bug se situe dans Onigmo : les compteurs de répétitions sont stockés dans un entier signé de 16 bits, plafonné à 32 767. Si un mot-clé contient plus de 32 767 répétitions génériques, le compteur déborde (integer overflow), passe en négatif et provoque une écriture mémoire hors limites lors de la compilation de l'expression. Cette écriture incontrôlée peut être transformée en exécution de code arbitraire par le processeur du serveur.

Le vecteur est particulièrement dangereux : sur une instance GitLab dont l'inscription est ouverte ou qui accepte des contributions externes, il suffit de créer une issue contenant un fichier .org piégé. Aucun mot de passe, aucun privilège, aucune interaction d'un administrateur n'est nécessaire. Ce bug existe depuis la version 7.0 de GitLab, publiée en 2014, et touche tous les systèmes Unix/Linux sur lesquels GitLab s'installe.

Quels serveurs et environnements sont concernés

CVE-2026-110264 touche toute instance GitLab auto-hébergée, quel que soit le mode d'installation ou l'infrastructure sous-jacente. Voici les configurations les plus courantes chez les administrateurs de serveurs :

Le système d'exploitation du serveur hôte (Ubuntu, Debian, Red Hat, Rocky Linux) n'a pas d'incidence sur la faille : le bug réside dans le code Ruby de GitLab, pas dans le noyau ou les bibliothèques système. Que votre GitLab tourne sur un serveur virtuel à 4 Go de RAM chez votre hébergeur ou un serveur dédié avec plusieurs processeurs physiques, la vulnérabilité reste exploitable de la même façon. La couche de virtualisation (KVM, VMware, Hyper-V) ne constitue pas non plus une protection.

Ce qu'un attaquant peut atteindre

Un serveur GitLab auto-hébergé concentre des données sensibles. Une prise de contrôle distant via cette faille donne accès :

• Au code source de tous les dépôts, y compris les dépôts privés ;
• Aux variables CI/CD et scripts de déploiement : clés API, tokens d'accès, mots de passe de bases de données (PostgreSQL, MySQL), clés SSH, identifiants de services tiers ;
• Aux registres de conteneurs et aux artefacts de build ;
• Aux clés GPG et tokens d'accès personnels des utilisateurs ;
• À la base de données PostgreSQL de GitLab (comptes, permissions, webhooks, adresses IP des runners) ;
• À la configuration du serveur web intégré (Nginx) : certificats TLS, nom de domaine, enregistrements DNS de l'instance, configuration réseau.

Pour un éditeur de scripts ou de mods (FiveM, Minecraft, Rust), un studio de développement ou toute équipe qui utilise GitLab pour versionner son code et déployer en production, les conséquences peuvent être totales : vol de propriété intellectuelle, compromission de la chaîne de déploiement, injection de code malveillant dans les builds distribués aux utilisateurs. Si vos pipelines CI/CD déploient des sites web, des applications ou des scripts Python, Ruby ou Shell sur d'autres serveurs, l'attaquant peut s'en servir comme rebond pour compromettre l'ensemble de l'infrastructure.

Versions corrigées

GitLab a publié des correctifs pour toutes les branches encore maintenues, ainsi qu'un rétroportage vers la branche 18.11. La migration vers l'une de ces versions est obligatoire pour corriger le bug :

Si votre instance tourne sur une version antérieure à 18.11 (par exemple GitLab 16.x ou 17.x), aucun correctif isolé n'existe : vous devez d'abord migrer vers une branche maintenue (voir la section migration ci-dessous).

Mettre à jour votre instance GitLab

La mise à jour provoque un temps d'arrêt : les migrations de base de données doivent se terminer avant que GitLab ne redémarre. Prévoyez une fenêtre de maintenance et prévenez vos utilisateurs. Ouvrez un terminal sur votre serveur (SSH ou console) et suivez la procédure correspondant à votre type d'installation.

Avant la mise à jour : sauvegardez

sudo gitlab-backup-cli backup create

Vérifiez aussi que vous disposez d'une sauvegarde distante de votre VPS ou serveur dédié. En cas de problème pendant l'upgrade, vous pourrez restaurer l'ensemble du serveur virtuel depuis la sauvegarde. Si votre hébergeur propose des snapshots, déclenchez-en un avant de commencer.

Installation Omnibus (la plus courante)

L'installation Omnibus utilise le gestionnaire de packages natif du système d'exploitation. Depuis le terminal :

# Debian / Ubuntu
sudo apt update
sudo apt install gitlab-ce
# ou gitlab-ee selon votre édition

# Red Hat / AlmaLinux / Rocky Linux
sudo dnf upgrade gitlab-ce

GitLab applique automatiquement les migrations de base de données au redémarrage. Suivez l'avancement dans les journaux depuis le terminal :

sudo gitlab-ctl tail

Si GitLab ne redémarre pas correctement après la mise à jour du package, lancez un reconfigure puis redémarrez les services manuellement :

sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart

Installation Docker

Si votre GitLab tourne dans un conteneur Docker sur votre VPS ou serveur dédié, mettez à jour l'image et redémarrez le conteneur. Consultez notre guide Docker Compose sur VPS Linux pour configurer vos services en conteneurs.

docker compose pull
docker compose up -d
docker compose exec gitlab gitlab-rake db:migrate:status

Installation Helm (Kubernetes)

helm repo update
helm upgrade gitlab gitlab/gitlab

Vérifier la version après mise à jour

Depuis le terminal, exécutez la commande suivante pour afficher la version installée :

sudo gitlab-rake gitlab:env:info

Confirmez que le numéro de version correspond à l'un des correctifs listés dans le tableau ci-dessus. Vérifiez aussi que tous les services sont actifs :

sudo gitlab-ctl status

Migrer depuis une version obsolète

Si votre instance GitLab est sur une version antérieure à 18.11, la migration vers une branche maintenue est le seul chemin pour corriger ce bug. GitLab impose un chemin de migration séquentiel : il est impossible de sauter directement de la version 15.x à la 19.x. Vous devez passer par chaque version intermédiaire majeure.

Exemple de chemin de migration pour une instance sur GitLab 16.5 :

# Étape par étape, depuis le terminal :
# 16.5.x -> 16.11.x -> 17.0.x -> 17.11.x -> 18.0.x -> 18.11.13
# Chaque étape nécessite de redémarrer GitLab et de laisser
# les migrations de base de données se terminer avant de continuer.

Avant de commencer la migration, vérifiez les ressources disponibles sur votre serveur : la migration peut exiger une charge importante en RAM et en processeur, surtout sur les instances avec beaucoup de projets. Si votre VPS ou machine virtuelle manque de ressources, envisagez d'augmenter temporairement la RAM avant de lancer l'opération.

Consultez la documentation officielle des chemins de migration GitLab pour identifier les étapes exactes selon votre version de départ.

En attendant la mise à jour

Si vous ne pouvez pas mettre à jour immédiatement, GitLab n'a pas publié de mesure de contournement officielle pour cette faille. En attendant, les administrateurs peuvent réduire la surface d'attaque :

• Désactivez l'inscription publique si elle est active (Admin > Settings > Sign-up restrictions) pour empêcher un attaquant anonyme de créer un compte et de déposer un fichier .org.
• Restreignez l'accès réseau par adresse IP : configurez le pare-feu du serveur pour n'autoriser que les adresses IP de votre équipe à joindre le serveur web de GitLab (ports 80/443). Les administrateurs distants peuvent passer par un tunnel SSH pour accéder à l'instance sans l'exposer sur Internet.
• Surveillez les journaux pour détecter des créations de fichiers .org inhabituelles dans les dépôts et les issues. Consultez les journaux du serveur avec journalctl.
• Activez l'audit système avec auditd pour tracer les actions suspectes sur le système de fichiers du serveur.

Ces mesures limitent l'exposition mais ne corrigent pas le bug. La seule protection complète reste la mise à jour du package GitLab.

Vérifier si votre instance a été compromise

La faille a été divulguée publiquement le 22 octobre 2026. Aucun exploit public n'est connu à ce jour et les détails techniques restent sous embargo jusqu'en janvier 2027, mais la prudence impose de vérifier :

• Recherchez les fichiers .org suspects créés récemment dans vos dépôts, issues et snippets, notamment ceux contenant des lignes #+TODO: inhabituellement longues.
• Vérifiez les processus lancés par l'utilisateur git depuis le terminal : un shell, un script inconnu, un téléchargement ou un reverse shell n'a rien à faire là.
• Passez en revue les tokens et clés : révoquez et renouvelez les tokens d'accès personnels, les tokens de déploiement, les variables CI/CD sensibles et les clés SSH si vous avez le moindre doute.
• Vérifiez les connexions réseau avec ss -tlnp (lister les ports en écoute) pour repérer un processus qui ouvrirait un port inhabituel sur votre adresse IP.
• Inspectez la base de données PostgreSQL de GitLab : cherchez des comptes utilisateurs inconnus, des tokens créés récemment ou des webhooks ajoutés sans autorisation.
• Changez les mots de passe de la base de données et des comptes administrateurs si le serveur a été exposé sans correctif pendant plusieurs jours.

Renforcer la sécurité de votre serveur

Au-delà de cette faille, un serveur GitLab auto-hébergé mérite les mêmes précautions que tout service exposé sur Internet. Voici les mesures essentielles pour les administrateurs de VPS et serveurs dédiés :

• Automatisez les mises à jour de sécurité du système d'exploitation pour que les correctifs des packages système s'appliquent sans attendre.
• Durcissez l'accès SSH : clé publique, port non standard, pas de connexion root. Tout accès distant au serveur doit passer par SSH.
• Surveillez les ressources de votre VPS ou serveur dédié depuis le terminal pour détecter une activité anormale (charge processeur, consommation RAM inhabituelle).
• Maintenez des sauvegardes distantes régulières pour pouvoir restaurer en cas de compromission.
• Configurez votre résolution DNS correctement et publiez GitLab en HTTPS avec un certificat valide pour le nom de domaine de votre instance.

Questions fréquentes

Conclusion

CVE-2026-110264 est la faille GitLab la plus grave de ces dernières années : un score CVSS maximal de 10/10, aucune authentification requise, un bug présent depuis douze ans dans toutes les versions. Le correctif existe et doit être appliqué sans tarder sur toute instance auto-hébergée, que le serveur soit un VPS, un serveur dédié ou une machine virtuelle dans un cluster de virtualisation. Les administrateurs doivent mettre à jour le package GitLab, vérifier la version depuis le terminal et configurer correctement le pare-feu et les accès distants pour limiter leur exposition aux prochaines vulnérabilités.

Si vous cherchez un VPS Linux avec accès root complet pour héberger votre GitLab, ou un serveur dédié pour les instances à forte charge avec des processeurs dédiés et de la RAM garantie, retrouvez toutes nos offres et nos guides d'administration serveur.