Après PHP, GitLab corrige une faille critique notée 10 sur 10 et présente depuis 2014

Les administrateurs système n’avaient pas fini de mettre à jour PHP que GitLab lançait sa propre alerte. Dans un avis publié ce mercredi 21 octobre, l’éditeur demande à toutes les entreprises qui hébergent GitLab sur leurs propres serveurs de mettre à jour sans attendre.

La faille permet à un attaquant de lancer les commandes de son choix sur la machine sans même avoir de compte. Elle se trouve dans chaque version depuis la 7.0, sortie en 2014. Les correctifs de PHP sont sortis le même jour à 16 heures, après une fuite qui avait forcé le projet à prévenir la veille, comme nous l’expliquions lors de l’annonce.

Gitlab : le Github maison

Les entreprises utilisent GitLab pour stocker le code source de leurs logiciels, puis pour le compiler et le déployer automatiquement. C’est un concurrent de la plateforme Github, sauf qu’avec GitLab, c’est vous qui hébergez le code source.

Dans son rapport annuel 2026, l’éditeur américain revendique plus de 50 millions d’utilisateurs inscrits. Les failles PHP menacent directement les paiements sur les boutiques en ligne. Celle de GitLab met d’abord en danger le code des entreprises.

La faille, référencée CVE-2026-110264, vient d’Onigmo, le moteur d’expressions régulières du langage Ruby. Quand Onigmo compile une expression piégée, un nombre devient trop grand et déborde de la place qui lui est réservée en mémoire (un integer overflow). Ce débordement permet d’exécuter du code malicieux.

GitLab note la faille 10 sur 10, le niveau le plus critique. Il faut absolument installer le correctif pour se protéger.

Patché le 12 octobre ? Il faut recommencer

Le 12 octobre, GitLab avait déjà corrigé une autre faille notée 10 dans le même compilateur (CVE-2026-97229), sur les versions 19.2 et suivantes. Or, les nouvelles versions corrigées arrivent juste après celles-là. Une instance passée en 19.4.2 il y a neuf jours redevient donc vulnérable et doit monter en 19.4.3.

Cette faille remonte à 2014, et GitLab a dû changer ses habitudes. D’ordinaire, l’éditeur ne corrige que la version du mois et les deux précédentes, soit la 19.5, la 19.4 et la 19.3. Il a cette fois publié des correctifs pour sept branches, jusqu’à la 18.11.13, une mesure qu’il réserve aux problèmes graves.

Ce qu’il faut faire sur votre serveur GitLab

Vérifiez la version de votre instance, affichée dans la page Aide de GitLab. Passez ensuite à la version corrigée de votre branche : 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 ou 18.11.13.

Si vous êtes sous la 18.11, aucune version de votre branche n’est corrigée. Il faut alors monter au moins jusqu’à la 18.11.13, parfois en plusieurs étapes.

Attention, les correctifs des branches 18.11 à 19.2 ne corrigent que la faille critique. Le 21 octobre, GitLab a corrigé douze failles en tout. Parmi elles, une permet de prendre le contrôle d’un compte quand SAML et LDAP, qui relient GitLab à l’annuaire de l’entreprise, sont liés automatiquement (notée 8,2). Une autre peut rediriger certaines connexions OAuth vers un serveur pirate (notée 7,5). Ces onze autres failles ne sont corrigées qu’à partir de la 19.3.6.

Prévoyez aussi une coupure. Les versions 19.4.3 et 19.3.6 modifient la base de données pendant la mise à jour, et sur un serveur unique, GitLab ne redémarre pas avant la fin de ces modifications. Si votre GitLab tourne sur plusieurs serveurs, vous pouvez appliquer le correctif sans interruption grâce à la procédure zero-downtime de l’éditeur.