Faille GitLab CVSS 10 (CVE-2026-110264) : mettre à jour un GitLab auto-hébergé

Le 21 octobre 2026, GitLab a publié une version corrective sur sept lignes à la fois : 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 et 18.11.13. La raison tient en un identifiant, CVE-2026-110264, et une note : 10,0 sur 10, le maximum de l'échelle CVSS. Un attaquant sans compte peut, dans certaines conditions, exécuter du code sur le serveur GitLab. Le code fautif remonte à GitLab 7.0, soit douze ans de versions.

GitLab auto-hébergé est courant dans les PME techniques, les ESN et les équipes qui veulent garder leur code en interne. C'est aussi, par construction, l'endroit où dorment vos secrets de déploiement. Cet article explique ce qu'on sait de la faille, comment vérifier si vous êtes exposé, dans quel ordre corriger, et ce qu'il faut regarder une fois la mise à jour faite.

Ce qu'on sait de la faille

GitLab n'a pas publié de description technique détaillée, ce qui est son usage pour une faille de ce niveau. La fiche CVE parle d'un dépassement d'entier (CWE-190) lors de la compilation d'une expression régulière spécialement construite. Le vecteur CVSS dit le reste : attaque par le réseau, faible complexité, aucun privilège, aucune interaction d'utilisateur, impact total sur la confidentialité, l'intégrité et la disponibilité, avec changement de périmètre, autrement dit la possibilité d'atteindre ce qui est au-delà du serveur GitLab lui-même.

Deux éléments relient cette faille au moteur d'expressions régulières de Ruby, le langage dans lequel GitLab est écrit : l'équipe Ruby a publié le 23 octobre des versions corrigées (4.0.9, 3.4.12 et 3.3.13) pour un dépassement provoqué par un motif comportant un très grand nombre de répétitions, et l'une des détections proposées par GitLab s'appelle « plantage natif d'un processus Onigmo », du nom de ce moteur. La faille a été signalée par le chercheur joaxcar via le programme de primes HackerOne de GitLab.

Au 22 octobre, GitLab n'avait connaissance d'aucune exploitation, et l'identifiant n'était pas dans le catalogue des failles exploitées de la CISA. Des dépôts publics y font référence ; celui qui a été examiné provoque un plantage, pas encore une exécution de code. Sur une faille à 10,0 sans authentification, c'est une question de jours.

Qui est concerné

• GitLab CE et EE auto-hébergés, toutes méthodes d'installation : paquets Omnibus, Docker, Helm sur Kubernetes, installation depuis les sources.
• Toutes les versions depuis 7.0 jusqu'aux correctifs : 18.11 avant 18.11.13, 19.0 avant 19.0.10, 19.1 avant 19.1.9, 19.2 avant 19.2.9, 19.3 avant 19.3.6, 19.4 avant 19.4.3, 19.5 avant 19.5.1.
• Les serveurs mis à jour le 12 octobre vers 19.4.2, 19.3.5 ou 19.2.8 pour la faille précédente restent vulnérables : le correctif est un cran au-dessus.
• Les versions antérieures à 18.11 n'ont pas de correctif : il faut monter au moins en 18.11.13, ce qui peut imposer plusieurs étapes intermédiaires.

GitLab.com est déjà corrigé. Si votre code est hébergé là, vous n'avez rien à faire pour cette faille. Si vous ne savez pas si votre entreprise a un GitLab à elle, la question mérite d'être posée aujourd'hui : il arrive qu'un serveur installé par un prestataire il y a cinq ans tourne encore, oublié, avec un accès internet.

Vérifier sa version

La page /help de votre instance affiche la version aux utilisateurs connectés. En ligne de commande :

# Paquet Omnibus
sudo gitlab-rake gitlab:env:info | grep -i 'GitLab information' -A 3
cat /opt/gitlab/embedded/service/gitlab-rails/VERSION

# Docker
docker exec gitlab cat /opt/gitlab/embedded/service/gitlab-rails/VERSION

# API, depuis n'importe où, avec un jeton
curl -H "PRIVATE-TOKEN: $TOKEN" https://gitlab.exemple.fr/api/v4/version

Comparez avec la liste des versions corrigées. Attention à la ligne : 19.3.5 n'est pas corrigée, 19.3.6 l'est.

Corriger : dans cet ordre

1. Sauvegarder avant tout. sudo gitlab-backup create pour les données, et une copie de /etc/gitlab/gitlab.rb et /etc/gitlab/gitlab-secrets.json, qui ne sont pas dans la sauvegarde standard. Sans ce second fichier, une restauration perd les variables CI chiffrées.
2. Vérifier le chemin de mise à jour. GitLab n'autorise pas tous les sauts. L'outil « Upgrade Path » de la documentation donne les versions intermédiaires obligatoires. Un serveur en 17.x passera par plusieurs étapes avant 18.11.13.
3. Mettre à jour vers la version corrigée de votre ligne, pas forcément la plus récente : rester sur sa ligne limite les surprises fonctionnelles. Paquet Omnibus : apt-get install gitlab-ee=19.4.3-ee.0 (ou gitlab-ce). Docker : changer l'étiquette de l'image, par exemple gitlab/gitlab-ee:19.4.3-ee.0, puis recréer le conteneur. Helm : la version de chart correspondante.
4. Attendre la fin des migrations de base de données, qui peuvent durer, puis vérifier l'état avec sudo gitlab-rake gitlab:check et la page /help.
5. Tester : connexion, clonage, un pipeline CI complet, les intégrations (registre de conteneurs, pages, webhooks).

Il n'existe aucun contournement officiel. Si la mise à jour est impossible dans la journée, la seule mesure qui compte est de couper l'exposition : retirer le serveur d'internet et ne le rendre accessible que par VPN ou depuis des adresses connues, le temps de planifier la mise à jour. Un GitLab accessible au monde entier sans correctif est une cible active.

Après la mise à jour : chercher des traces

Une faille publiée le 21 octobre a pu être tentée dès le 22. Quelques signaux à chercher dans les journaux, à partir des détections proposées par GitLab et des travaux sur la faille du 12 octobre :

• des plantages inexpliqués de processus Puma ou de workers natifs (/var/log/gitlab/puma/, journalctl), en particulier en rafale ;
• des requêtes qui se terminent en erreur 502 dans les journaux de Workhorse ou du reverse proxy, répétées depuis une même origine ;
• des erreurs de rendu en série sur des fichiers aux formats texte inhabituels ;
• des exécuteurs CI, des clés de déploiement, des jetons d'accès ou des utilisateurs administrateurs créés sans que personne ne s'en souvienne.

Si le doute existe, considérez les secrets comme compromis. Un serveur GitLab contient, en clair pour qui exécute du code dessus, les variables CI (mots de passe de bases, clés cloud, jetons de registre), les clés de déploiement vers vos serveurs de production, et les jetons d'accès des intégrations. Faites-les tourner tous, puis reconstruisez le serveur depuis une image saine et une sauvegarde antérieure au 21 octobre, plutôt que de nettoyer sur place.

Pourquoi un GitLab est la cible la plus rentable de votre infrastructure

Un serveur web compromis donne un site. Un serveur GitLab compromis donne le code source, l'historique, les secrets de production, et le droit de modifier ce qui sera déployé demain. C'est le chemin le plus court vers une attaque de chaîne d'approvisionnement, où l'on ne pirate pas votre produit mais ce qui le fabrique. Trois conséquences pratiques, valables même sans faille à 10,0 :

• Ne pas l'exposer à internet s'il n'y a pas besoin. Une équipe de quinze personnes et un exécuteur CI n'ont pas besoin que le serveur réponde au monde. VPN, liste d'adresses autorisées ou authentification en amont par le reverse proxy réduisent la surface à presque rien.
• Le traiter comme un composant de production, avec une mise à jour mensuelle planifiée. GitLab publie des correctifs de sécurité deux fois par mois ; un serveur qui a six mois de retard a six mois de failles connues.
• Limiter ce que les secrets permettent. Variables CI protégées et masquées, jetons à durée de vie courte, clés de déploiement en lecture seule quand c'est possible : si le serveur tombe, le dégât est borné.

Ce que j'en retiens

• CVE-2026-110264 permet une exécution de code sans compte sur tout GitLab auto-hébergé depuis la version 7.0 ; la note de 10,0 est méritée.
• La seule correction est la mise à jour vers 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3 ou 19.5.1, après sauvegarde et en respectant le chemin de mise à jour.
• Pas de contournement : sans mise à jour possible aujourd'hui, retirez le serveur d'internet.
• Après le correctif, cherchez des plantages et des 502 en rafale depuis le 21 octobre ; en cas de doute, faites tourner tous les secrets et reconstruisez.
• Un GitLab oublié avec une adresse publique est le meilleur cadeau qu'on puisse faire à un attaquant.

Vous avez un GitLab, ou vous n'êtes pas sûr d'en avoir un, et personne n'en a la charge ? Je peux l'inventorier, le mettre à jour, le sortir d'internet et mettre en place la maintenance qui évite la prochaine alerte. Décrivez-moi votre installation, je vous réponds rapidement.

Sources : fiche CVE-2026-110264 publiée par GitLab le 22 octobre 2026, version corrective GitLab du 21 octobre 2026, annonce de sécurité de Ruby du 23 octobre 2026, synthèses de Brandefense et Rapid7. Article à jour au 26 octobre 2026.