GitLab : une faille notée 10/10 touche douze ans de versions

Le 21 octobre, au moment où les équipes corrigeaient en urgence PHP, GitLab a publié un correctif critique pour une autre vulnérabilité notée 10 sur 10. CVE-2026-110264 peut permettre à un attaquant non authentifié d'exécuter du code sur un serveur GitLab. Elle concerne toutes les éditions Community et Enterprise auto-hébergées depuis la version 7.0, soit environ douze ans de versions.

Si votre organisation héberge son propre GitLab, c'est à traiter maintenant.

Ce que l'on sait

Selon l'avis de GitLab, la faille vient d'un dépassement d'entier lors de la compilation d'une expression régulière spécialement construite. Elle se situe dans Onigmo, le moteur d'expressions régulières utilisé par Ruby, que GitLab embarque dans ses paquets.

Score : CVSS 10,0, le maximum, avec une attaque possible à distance, sans compte et sans action d'un utilisateur.
Conditions : GitLab précise que l'exploitation est possible « sous certaines conditions », sans les détailler.
Exploitation : selon The Hacker News, GitLab n'a pas signalé d'exploitation active à ce jour.
Contournement : aucun n'est proposé. La mise à jour est la seule protection.

Ce n'est pas un cas isolé : selon la même source, une faille du même type, également notée 10, avait déjà été corrigée le 12 octobre. Une instance mise à jour il y a dix jours reste donc vulnérable.

Pourquoi un serveur GitLab est une cible de choix

Un serveur GitLab n'est pas un simple outil de développement. Il concentre souvent :

le code source de vos applications, et donc leurs failles éventuelles
les secrets des chaînes CI/CD : mots de passe, clés d'API, jetons cloud
les clés de déploiement qui donnent accès aux serveurs de production
les jetons d'accès des développeurs et des comptes de service

Prendre la main sur GitLab, c'est souvent obtenir les clés de tout le reste : la production, le cloud, et parfois les clients à qui vous livrez du logiciel.

Les versions corrigées

D'après GitLab, il faut passer à l'une des versions suivantes, selon votre branche :

19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9 ou 19.0.10
18.11.13 pour toutes les versions de 7.0 à 18.11

GitLab a exceptionnellement publié des correctifs pour des branches anciennes. Attention : selon The Hacker News, les versions 19.4.3 et 19.3.6 comportent des changements de base de données qui entraînent une interruption sur les installations à un seul serveur. Prévoyez la fenêtre de maintenance.

GitLab.com et GitLab Dedicated sont déjà corrigés : seules les instances auto-hébergées sont concernées.

Les mesures à prendre aujourd'hui

Identifier toutes vos instances. Y compris celles installées par une équipe projet, un prestataire ou pour un test, et oubliées depuis.
Mettre à jour en priorité ce qui est exposé. Une instance accessible depuis Internet passe avant tout le reste.
Réduire l'exposition. Un GitLab interne n'a pas de raison d'être joignable depuis Internet : placez-le derrière un VPN ou un accès filtré.
Surveiller. GitLab a publié deux règles de détection pour repérer d'éventuelles tentatives d'exploitation sur les instances auto-hébergées. Intégrez-les à votre supervision.
En cas de doute, renouveler les secrets. Si une instance exposée n'était pas à jour, considérez les secrets CI/CD, les clés de déploiement et les jetons comme potentiellement compromis.

Notre regard

En quarante-huit heures, PHP puis GitLab : deux briques présentes dans un très grand nombre d'organisations, deux failles critiques exploitables sans authentification. La différence entre les organisations qui corrigent dans la journée et celles qui découvrent un serveur oublié trois semaines plus tard tient à une chose : savoir précisément ce qui est exposé.

C'est l'objet de notre diagnostic d'exposition : nous cartographions ce qu'un attaquant voit de vous depuis Internet et nous vous donnons les actions prioritaires. Et si vous craignez qu'une instance ait déjà été visée, notre pôle forensic peut le vérifier. Parlons-en.