GitLab recommande une mise à jour immédiate de ses installations auto-hébergées. L’éditeur a publié le 21 octobre 2026 plusieurs correctifs pour sa plateforme DevSecOps, dont un visant CVE-2026-110264, une vulnérabilité créditée du score maximal CVSS 10/10. Dans certaines conditions, un attaquant distant pourrait déclencher l’exécution de code sur un serveur GitLab sans même posséder de compte. Les versions affectées remontent à la branche 7.0, mais il serait trompeur d’affirmer qu’une exploitation active est déjà confirmée partout : au 24 octobre, les alertes officielles consultées ne signalent pas de campagne d’attaque avérée pour cette CVE.
GitLab : pourquoi cette vulnérabilité est critique
- Identifiant : CVE-2026-110264.
- Gravité : 10,0/10 en CVSS v3.1, la note maximale.
- Type : dépassement d’entier lors de la compilation d’une expression régulière spécialement construite.
- Conséquence possible : exécution de code arbitraire à distance sur le serveur GitLab.
- Authentification : aucune requise dans le scénario vulnérable décrit par l’éditeur.
- Produits concernés : GitLab Community Edition (CE) et Enterprise Edition (EE), en particulier les installations self-managed.
- Correctifs : GitLab 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 ou 18.11.13, selon la branche.
- GitLab.com : GitLab indique avoir déjà déployé les correctifs sur son service hébergé.
Quelle est l’origine technique de CVE-2026-110264 ?
Le problème se situe dans le traitement de certaines expressions régulières, via le compilateur intégré à l’environnement utilisé par GitLab. Le CERT Santé français identifie un dépassement d’entier dans le moteur Onigmo. Lorsqu’un système manipule incorrectement des calculs de taille ou de mémoire, une donnée conçue pour provoquer une erreur peut compromettre son exécution.
Le bulletin GitLab explique que, dans certaines conditions, une expression régulière malveillante peut mener à l’exécution de code arbitraire sur le serveur. Le score de 10 traduit la gravité du scénario évalué ; il ne signifie pas que n’importe quelle installation est exploitable de manière garantie ni qu’une compromission est déjà constatée.
Il serait dangereux de reporter le correctif sous prétexte qu’aucune attaque majeure n’a encore été rendue publique. L’accès à une plateforme GitLab peut exposer des dépôts privés, des secrets CI/CD et d’autres ressources d’entreprise selon les permissions et la configuration de l’instance.
Quelles versions de GitLab faut-il installer ?
Le bulletin officiel du 21 octobre précise les versions corrigées pour chaque branche. Les versions antérieures à la borne indiquée sont concernées :
| Branche GitLab CE/EE | Version minimale corrigée | Action |
|---|---|---|
| 18.11 et branches plus anciennes depuis 7.0 | 18.11.13 | Installer un correctif pris en charge ou migrer vers une branche maintenue |
| 19.0 | 19.0.10 | Mettre à jour |
| 19.1 | 19.1.9 | Mettre à jour |
| 19.2 | 19.2.9 | Mettre à jour |
| 19.3 | 19.3.6 | Mettre à jour |
| 19.4 | 19.4.3 | Mettre à jour |
| 19.5 | 19.5.1 | Mettre à jour |
Important : une vieille branche comme 7.x n’est pas « sécurisée » simplement parce que le tableau indique 18.11.13 : il faut migrer vers une branche prise en charge en respectant les chemins de mise à niveau de GitLab. Les versions corrigées listées correspondent aux correctifs disponibles sur les branches précisées et ne garantissent pas le support de tous les systèmes anciens.
GitLab précise que GitLab.com est corrigé. Pour GitLab Dedicated, les environnements utilisant les versions internes 19.3.5-internal0 et 19.4.2-internal0, ou plus récentes, incluent déjà les correctifs annoncés. Les clients d’offres managées doivent consulter le bulletin propre à leur instance.
Que risque une entreprise si son serveur GitLab est compromis ?
GitLab n’est pas seulement un espace de stockage de code. De nombreuses organisations s’en servent pour les pipelines d’intégration et de déploiement continus, les registres de conteneurs, les tickets et la coordination de projets. Un accès injustifié à l’instance pourrait entraîner, selon la configuration, des lectures de code, des fuites de jetons, des modifications de dépôts ou des manipulations de pipelines.
Il faut distinguer ce scénario possible d’une compromission généralisée établie : la présence d’une CVE notée 10 ne prouve pas qu’un acteur a déjà pénétré votre réseau. Le risque est néanmoins suffisamment grave pour justifier un correctif prioritaire.
Vérifier et corriger son serveur GitLab sans attendre
- Inventorier les instances : GitLab exposés publiquement, serveurs internes, environnements de test, appliances et déploiements en conteneurs.
- Relever la version : consulter l’interface d’administration ou la commande de version documentée pour votre mode de déploiement. Ne pas confondre l’image de conteneur téléchargée et la version réellement en production.
- Planifier la mise à jour : sauvegarder la configuration et les dépôts, puis appliquer la version corrigée compatible en suivant la documentation de mise à niveau GitLab.
- Vérifier la reprise : contrôler les pipelines essentiels, les connexions SSO, les dépôts, les runners et les journaux d’erreurs.
- Examiner les alertes : consulter les règles de détection officiellement publiées, surtout pour les instances exposées à Internet.
- En cas de soupçon sérieux : conserver les logs et les preuves avant tout nettoyage, demander une analyse à l’équipe de sécurité et envisager la rotation des secrets potentiellement exposés selon les résultats.
GitLab propose deux indicateurs de détection de tentatives : Onigmo native worker crash et Org mode render error burst. Ils figurent dans l’avis de CERT-EU qui recommande d’actualiser les serveurs accessibles depuis Internet et d’examiner les éventuels signes d’exploitation. Un crash ou une erreur isolée ne doit cependant pas être présenté automatiquement comme la preuve d’une intrusion.
Est-ce une faille déjà exploitée ?
Au 22 octobre, le CERT Santé indiquait « faille activement exploitée : non » et ne signalait pas de preuve de concept publique connue. Cette appréciation correspond à un état daté, susceptible d’évoluer rapidement. La publication de règles de détection ne démontre pas, à elle seule, une exploitation généralisée.
Le bulletin de GitLab porte aussi sur d’autres failles, dont des problèmes d’authentification. Dans une opération de maintenance, il est donc préférable de déployer la version corrigée complète, plutôt que tenter de ne traiter qu’un composant de la CVE-2026-110264.
Que faire si votre instance GitLab se trouve chez un prestataire ?
Si l’organisation utilise GitLab.com, l’éditeur indique que le service était déjà à jour lors de l’annonce. Si vous louez une instance GitLab sur un VPS ou dans une offre gérée par un tiers, demandez-lui de confirmer la branche, la version exacte et la date de correction. Un certificat HTTPS valide ne signifie pas que l’application est protégée contre cette faille.
Les administrateurs de sites WordPress peuvent retrouver d’autres actualités de sécurité dans notre dossier PHP2Shell consacré aux tentatives d’attaque avant la publication des correctifs. Les deux alertes sont distinctes et ne doivent pas être confondues.
FAQ : GitLab CVE-2026-110264
La faille GitLab nécessite-t-elle de se connecter ?
Non dans le scénario décrit par GitLab : une requête spécialement conçue peut, sous certaines conditions, permettre une exécution de code sans compte.
Quelle est la version GitLab la plus récente corrigée ?
Au 21 octobre, l’éditeur cite notamment 19.5.1, ainsi que plusieurs versions corrigées sur les branches précédentes. Il faut choisir une branche supportée et compatible avec votre installation.
GitLab.com est-il concerné ?
GitLab indique avoir déjà appliqué les correctifs sur son infrastructure SaaS.
Le score CVSS 10 prouve-t-il que mon instance a été piratée ?
Non. Il mesure la gravité d’un scénario de vulnérabilité, pas la présence constatée d’un pirate sur un serveur donné.
