Les entreprises qui hébergent elles-mêmes leur GitLab ont une mise à jour à faire passer en urgence. Mercredi 21 octobre, l’éditeur a publié une série de correctifs pour sa plateforme de développement, dont l’un comble une faille notée 10 sur 10, la note maximale de l’échelle CVSS. Elle permet, dans certaines conditions, à un attaquant qui n’a même pas de compte d’exécuter du code sur le serveur.
Plan de l'article
Une faille qui remonte à la version 7.0 #
La vulnérabilité porte la référence CVE-2026-110264. D’après les notes de version officielles de GitLab, il s’agit d’un dépassement d’entier dans le compilateur d’expressions régulières, le composant qui interprète les motifs de recherche utilisés un peu partout dans l’application. Une erreur de calcul à cet endroit peut être exploitée pour faire exécuter des instructions arbitraires au serveur.
Ce qui frappe, c’est l’ancienneté du problème. GitLab indique que toutes les versions depuis la 7.0 sont touchées, jusqu’aux versions corrigées publiées cette semaine. Autrement dit, la faille dormait dans le code depuis des années, à travers des dizaines de versions majeures.
L’éditeur ne donne pas le détail des conditions d’exploitation, ce qui est l’usage pour laisser aux administrateurs le temps d’appliquer le correctif avant que des attaquants ne s’en emparent. Les notes de version ne mentionnent pas d’exploitation active à ce stade.
Douze correctifs de sécurité dans la même livraison #
La faille critique n’arrive pas seule. GitLab liste au total douze correctifs de sécurité dans cette publication. Le plus sérieux après la CVE-2026-110264 est la CVE-2026-15723, notée 8,2 : sur les instances où SAML et LDAP sont activés ensemble, un utilisateur authentifié pouvait prendre le contrôle d’un compte LDAP existant.
Une troisième faille, la CVE-2026-112212 notée 7,5, concerne un empoisonnement de cache sur les points d’accès de découverte OAuth et OpenID Connect, qui pouvait rediriger certains flux d’authentification vers un serveur externe. Le reste de la liste est de gravité moyenne ou faible : fuites d’informations via des caches partagés, contournements de règles d’approbation des merge requests, ou encore accès aux fonctions d’IA payantes sans abonnement valide.
Les versions à installer
Les versions corrigées sont les 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 et 18.11.13, pour les éditions Community et Enterprise. GitLab « recommande fortement » de mettre à jour toutes les installations concernées dès que possible.
À lire L’Arcom ouvre une enquête sur Mym : contrôle de l’âge et transparence en question
Bonne nouvelle pour les utilisateurs de la version en ligne : GitLab.com tourne déjà sur la version corrigée, selon l’éditeur. Les clients de GitLab Dedicated, l’offre hébergée en instance dédiée, n’ont rien à faire non plus s’ils sont sur les versions internes déjà patchées. Ce sont donc avant tout les installations auto-hébergées, répandues dans les entreprises, qui sont exposées.
Que faire si votre entreprise utilise GitLab #
Le premier réflexe est de savoir quelle version tourne. L’information figure dans l’aide de l’interface ou dans la page d’administration de l’instance. Si elle est antérieure aux versions citées plus haut sur votre branche, la mise à jour doit passer en tête de liste.
Pour les équipes qui ne peuvent pas mettre à jour immédiatement, quelques mesures limitent l’exposition en attendant. Une instance qui n’a pas besoin d’être accessible depuis internet peut être placée derrière un VPN ou un filtrage par adresse IP. Les journaux d’accès méritent aussi un coup d’œil, à la recherche de requêtes inhabituelles. Ces précautions ne remplacent pas le correctif : la faille ne demande pas de compte, donc toute instance joignable de l’extérieur est une cible.
Pensez enfin aux serveurs oubliés. Il arrive qu’une organisation monte un GitLab pour un projet, puis le laisse tourner sans suivi. Ce sont souvent ces machines-là, pas l’instance principale, qui servent de porte d’entrée lors d’une intrusion.
À lire Ledger Atom : le français dévoile un coffre-fort numérique au format smartphone
Une journée chargée pour les administrateurs #
Le 21 octobre restera comme une journée très chargée pour les équipes de sécurité. Next parle d’une « journée noire » : le même jour, PHP a publié des correctifs pour deux failles permettant l’exécution de code à distance sans authentification (versions 8.2.35, 8.3.36, 8.4.27 et 8.5.12), et le site cite aussi Node.js, Fortinet et Oracle parmi les éditeurs concernés par des failles ce jour-là.
Pour une PME, cela veut dire prioriser. Les services exposés sur internet et qui ne demandent pas d’authentification pour être attaqués passent avant le reste. Dans cette catégorie, un GitLab auto-hébergé et un site sous PHP figurent en haut de la liste cette semaine.
Ce type d’épisode rappelle aussi l’intérêt d’un inventaire à jour des logiciels qui tournent dans l’entreprise. Sans liste des serveurs et des versions, impossible de savoir en une heure si l’on est concerné. Avec, la question se règle en quelques minutes, et le correctif peut être planifié avant la fin de la journée.
