Faille GitLab CVE-2026-110264 : notée 10 sur 10, elle touche les serveurs auto-hébergés depuis 2014

25 octobre 2026 · 5 min de lecture

Le 21 octobre 2026, GitLab a corrigé la faille GitLab CVE-2026-110264, notée 10 sur 10 : sur une version non corrigée, un attaquant sans compte peut exécuter du code sur un serveur GitLab installé par l’entreprise elle-même. Toutes les versions depuis la 7.0, sortie en juin 2014, sont touchées. Pour une ETI, la question est simple : combien d’instances GitLab tournent chez elle et chez ses prestataires, et sont-elles à jour ?

Que s’est-il passé ?

GitLab a publié le 21 octobre 2026 des versions correctives pour douze failles, dont une seule critique : CVE-2026-110264, notée 10,0 au score CVSS. Selon l’avis de l’éditeur, un dépassement d’entier dans le compilateur d’expressions régulières permet à un utilisateur non authentifié d’exécuter du code arbitraire sur le serveur GitLab.

La faille a été signalée par un chercheur dans le cadre du programme de récompense de GitLab sur HackerOne. L’avis ne fait état d’aucune exploitation ; SecurityOnline indiquait le même jour qu’aucune exploitation n’était confirmée et qu’aucune preuve de concept n’était publique. GitLab publie deux règles de détection pour aider les installations auto-hébergées à repérer des tentatives.

Quelles versions la faille GitLab CVE-2026-110264 touche-t-elle, et lesquelles la corrigent ?

Les éditions Community et Enterprise sont touchées depuis la version 7.0 jusqu’aux versions corrigées : 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 et 18.11.13.

Le correctif a été reporté sur les branches 18.11 à 19.2. Une installation antérieure à la 18.11 n’a pas de version corrigée dans sa branche : elle doit être mise à niveau, au moins jusqu’à 18.11.13. Selon GitLab, GitLab.com tourne déjà sur la version corrigée, et les instances GitLab Dedicated aux versions 19.3.5-internal0, 19.4.2-internal0 ou suivantes n’ont rien à faire. Ce sont donc les installations auto-hébergées, sur serveur, machine virtuelle ou conteneur, qui doivent agir.

Pourquoi un correctif appliqué le 12 octobre ne suffit-il pas ?

Parce que la faille du 21 octobre en est une autre : le 12 octobre, GitLab avait déjà corrigé CVE-2026-97229, elle aussi notée 10 et sans authentification, dans le compilateur d’expressions régulières de l’intégration continue (CI/CD).

Cette première faille ne touchait que les branches 19.2 à 19.4, corrigées en 19.2.8, 19.3.5 et 19.4.2 ; l’agence de cybersécurité de Singapour l’a signalée le 14 octobre. Ces versions restent touchées par CVE-2026-110264, que seules corrigent 19.2.9, 19.3.6 et 19.4.3.

La série est plus longue. Le 23 septembre, GitLab a corrigé deux failles notées 9,9 dans l’analyse et la compilation des expressions régulières ; elles demandaient un compte sur l’instance. Le 10 septembre, une faille notée 10, CVE-2026-85706, permettait de lire des fichiers du serveur sans authentification ; la CISA l’a ajoutée le 11 septembre à son catalogue des vulnérabilités exploitées (KEV).

Pourquoi les GitLab auto-hébergés sont-ils une cible ?

Parce qu’une forge logicielle concentre ce qui ouvre le reste du SI : le code source, l’intégration continue et, souvent, des jetons d’accès, des clés et des mots de passe.

Exécuter du code sur le serveur GitLab peut donner accès à ces secrets, puis aux environnements où le code est déployé. Quand l’instance est ouverte sur Internet pour les développeurs et les prestataires, une faille sans authentification suffit. Les attaquants s’y intéressent : la faille du 10 septembre est exploitée, selon la CISA. GitLab revendique, selon sa propre estimation, plus de 50 millions d’utilisateurs inscrits ; chaque organisation qui l’héberge elle-même doit corriger sa propre instance.

Quelle réponse propose Ekera ?

Devant une telle alerte, la première question est : où avons-nous GitLab, qui l’exploite, et qu’est-ce qui en dépend ? Ekera construit une cartographie du système d’information à partir de vos documents et de vos exports (inventaires, contrats, annuaire), sans accès direct à votre SI : applications, serveurs, fournisseurs et dépendances, du processus au serveur, chaque élément relié à sa source.

La surveillance continue relie les failles publiées aux composants et aux processus touchés, puis présente des propositions que vos équipes décident. Vous pouvez aussi demander à la carte, en français, ce qu’arrêterait la coupure d’une forge logicielle : la réponse cite ses sources, et chaque chiffre vient du moteur de calcul, jamais du modèle. L’exemple chiffré des Ateliers Morvan (exemple fictif) montre à quoi ressemble cette carte.

Sources

1. GitLab, « GitLab Critical Patch Release: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13 », 21 octobre 2026
2. CVE.org, fiche CVE-2026-110264, « Integer Overflow or Wraparound in GitLab », publiée le 22 octobre 2026
3. SecurityOnline, « GitLab Critical Patch Release Fixes 12 GitLab Vulnerabilities », 21 octobre 2026
4. GitLab, « GitLab Critical Patch Release: 19.4.2, 19.3.5, 19.2.8 », 12 octobre 2026
5. Cyber Security Agency of Singapore, alerte AL-2026-141, « Critical Vulnerability in GitLab Community Edition and Enterprise Edition », 14 octobre 2026
6. GitLab, « GitLab Critical Patch Release: 19.4.1, 19.3.3, 19.2.7 », 23 septembre 2026
7. GitLab, « GitLab Critical Patch Release: 19.3.2, 19.2.6, 19.1.8 », 10 septembre 2026
8. CISA, « Known Exploited Vulnerabilities Catalog », entrée CVE-2026-85706, ajoutée le 11 septembre 2026
9. GitLab, étiquette de la version 7.0.0, juin 2014
10. GitLab, « About GitLab », chiffres de juin 2026

Article préparé avec l’agent de veille d’Ekera à partir des sources citées, relu et validé par l’équipe avant publication. Ekera cartographie le système d’information (SI) des ETI, chiffre ce qu’une attaque arrêterait et prépare les preuves NIS2. Découvrir Ekera.