GitLab a publié le 21 octobre 2026 des correctifs pour une faille GitLab critique, référencée CVE-2026-110264 et notée 10 sur 10. Elle peut permettre à un attaquant sans compte d'exécuter son propre code sur le serveur. Toutes les versions de GitLab Community Edition (CE) et Enterprise Edition (EE) depuis la 7.0, sortie en 2014, sont touchées. Les entreprises et administrations suisses qui hébergent GitLab elles-mêmes doivent installer une version corrigée.
GitLab sert à stocker le code source d'une organisation et à automatiser ses mises en production. Un serveur compromis met donc en jeu tout le code de l'organisation. Selon le site spécialisé Inside IT, aucune attaque n'avait encore été observée le 23 octobre 2026. Le média juge pourtant presque certain que cela change vite.
Que permet la faille GitLab CVE-2026-110264 ?
La faille vient d'un dépassement d'entier lors de la compilation d'une expression régulière, un motif de recherche dans du texte. D'après la fiche publiée le 22 octobre 2026 sur cve.org, une expression régulière piégée peut provoquer ce dépassement. Dans certaines conditions, un utilisateur non authentifié peut alors exécuter du code arbitraire sur le serveur GitLab.
La note de 10,0 est le maximum de l'échelle CVSS (Common Vulnerability Scoring System), dans sa version 3.1. Le vecteur publié décrit une attaque menée par le réseau, peu complexe, sans privilège et sans action d'un utilisateur. Les effets sur la confidentialité, l'intégrité et la disponibilité sont tous jugés élevés.
Le résultat établi est donc la gravité de la faille et la liste des versions touchées. Les « conditions » précises de l'attaque, en revanche, ne sont pas détaillées par GitLab. La faille a été signalée par le chercheur joaxcar dans le cadre du programme de récompense de GitLab sur la plateforme HackerOne.
Quelle version de GitLab installer ?
GitLab recommande à toutes les installations autogérées de passer immédiatement à l'une des sept versions corrigées. Le choix dépend de la branche déjà installée, comme le résume le tableau tiré de la note de version de GitLab.
| Branche installée | Version corrigée à installer |
|---|---|
| 19.5 | 19.5.1 |
| 19.4 | 19.4.3 |
| 19.3 | 19.3.6 |
| 19.2 | 19.2.9 |
| 19.1 | 19.1.9 |
| 19.0 | 19.0.10 |
| 18.11 | 18.11.13 |
| Avant 18.11 | Aucun correctif : migrer vers une branche corrigée |
Pour cette faille, GitLab a reporté le correctif, en plus de ses versions habituelles, sur les branches 18.11, 19.0, 19.1 et 19.2. Selon Inside IT, aucune mise à jour n'est en revanche proposée pour les versions antérieures à 18.11.13. Une instance plus ancienne doit donc changer de branche, ce qui demande davantage de préparation.
La mise à jour n'est pas toujours transparente. GitLab prévient qu'elle contient des migrations de base de données, notamment dans les versions 19.4.3 et 19.3.6. Sur un serveur unique, elle entraîne une interruption, le temps que les migrations se terminent. Une installation répartie sur plusieurs serveurs peut l'appliquer sans coupure, avec la procédure adaptée.
Pourquoi l'exploitation suit-elle vite un correctif ?
Un correctif publié rend la faille publique, et c'est ce qui accélère les attaques. Inside IT le dit en ces termes : en publiant ses correctifs, GitLab a fait connaître la faille. Les attaquants savent dès lors quel logiciel viser et quelles versions restent vulnérables.
La note de version donne d'ailleurs un indice sur la zone concernée. Elle mentionne, pour chaque branche, un correctif du traitement des expressions régulières de Ruby. GitLab garde les détails techniques de chaque faille privés pendant 90 jours après le correctif, mais la faille elle-même est désormais connue.
Le cas récent de PHP montre à quelle vitesse les choses peuvent aller. Pour la faille PHP PHP2Shell, Cloudflare bloquait des tentatives d'attaque neuf heures avant la publication officielle, après la rupture de l'embargo. Rien de tel n'a été signalé pour GitLab dans les sources consultées.
Ce qui ne concerne pas GitLab.com
Les clients qui utilisent GitLab en ligne, sans serveur propre, n'ont rien à faire. GitLab.com fonctionne déjà avec la version corrigée. Les clients de GitLab Dedicated, l'offre hébergée pour une seule organisation, sont protégés s'ils utilisent les versions 19.3.5-internal0 ou 19.4.2-internal0, ou plus récentes.
Seules les installations autogérées sont donc concernées : serveurs d'entreprise, d'administration, d'école ou d'hébergeur. GitLab précise que, faute de mention contraire, tous les types d'installation sont touchés, qu'il s'agisse du paquet complet, d'une installation depuis le code source ou d'un déploiement par chart Helm.
Onze autres failles corrigées au passage
Les mêmes versions corrigent onze autres failles, dont deux jugées élevées. La CVE-2026-15723, notée 8,2, permet de prendre le contrôle d'un compte LDAP existant quand deux réglages de connexion, OmniAuth SAML et la liaison automatique LDAP, sont activés ensemble. La CVE-2026-112212, notée 7,5, permet d'empoisonner un cache partagé pour rediriger certaines connexions OAuth ou OIDC vers un serveur externe. Les neuf autres sont jugées moyennes ou faibles.
Ce que doit faire une PME ou une administration en Suisse
La première étape consiste à savoir qui gère le serveur GitLab et quelle version il exécute. Les étapes suivantes découlent des indications de GitLab :
- comparer la version installée au tableau et installer la version corrigée de sa branche ;
- pour une version antérieure à 18.11, planifier la migration vers une branche corrigée ;
- sur un serveur unique, prévoir la courte interruption due aux migrations de base de données ;
- si un prestataire gère l'instance, lui demander s'il a installé l'une des sept versions corrigées ;
- utiliser les deux détections publiées par GitLab pour repérer des tentatives d'exploitation, nommées « Onigmo native worker crash » et « Org mode render error burst » ;
- s'abonner aux notifications de correctifs de GitLab, par courriel ou par flux RSS.
Ces gestes rejoignent les mesures de base en sécurité informatique d'une PME, qui commencent par des mises à jour rapides.
Ce qu'on ne sait pas encore
Plusieurs points restent ouverts dans les sources consultées :
- les conditions exactes qui rendent l'attaque possible ne sont pas publiées ;
- le nombre d'instances GitLab autogérées en Suisse, et la part encore vulnérable, ne sont pas connus ;
- aucune exploitation n'était signalée au 23 octobre 2026, mais la situation peut avoir changé depuis ;
- aucune des sources ne fait état d'un avertissement de l'Office fédéral de la cybersécurité (OFCS) sur cette faille.
