GitLab publie en urgence une importante série de correctifs de sécurité ce 21 octobre 2026. Douze vulnérabilités sont corrigées, dont une faille critique notée 10 sur 10 qui pourrait permettre à un attaquant non authentifié d’exécuter du code arbitraire directement sur un serveur GitLab.
L’éditeur demande aux entreprises utilisant une instance GitLab auto-hébergée de procéder à la mise à jour immédiatement. GitLab.com est déjà corrigé, tout comme les environnements GitLab Dedicated suffisamment récents.
Une faille critique présente depuis GitLab 7.0
La vulnérabilité la plus dangereuse est référencée CVE-2026-110264. Elle concerne le compilateur d’expressions régulières utilisé par GitLab et repose sur un débordement d’entier.
Dans certaines conditions, une expression régulière spécialement préparée peut provoquer une corruption de la mémoire du processus Ruby. GitLab considère que cette faiblesse peut aller jusqu’à l’exécution de code à distance sans authentification et sans interaction de la victime.
Le score CVSS maximal de 10.0 s’explique par ce scénario : l’attaque peut être réalisée depuis le réseau, ne nécessite aucun privilège préalable et peut compromettre simultanément la confidentialité, l’intégrité et la disponibilité du serveur.
Le périmètre est particulièrement large. GitLab indique que toutes les versions CE et EE depuis GitLab 7.0 sont concernées lorsqu’elles n’ont pas reçu l’un des nouveaux correctifs.
Une erreur dans le moteur d’expressions régulières de Ruby
Les correctifs intégrés par GitLab permettent de comprendre plus précisément l’origine du problème. Ils modifient Onigmo, le moteur d’expressions régulières utilisé par Ruby.
Dans certaines constructions très complexes, Onigmo compte des identifiants internes dans un entier classique mais les stocke ensuite dans une valeur signée sur 16 bits. Au-delà d’un certain seuil, cette valeur peut déborder et devenir négative.
Lors de l’utilisation de l’expression régulière, cette valeur incorrecte peut ensuite conduire à un accès mémoire hors limites. Le correctif consiste notamment à refuser les expressions dépassant ces limites avant leur compilation.
GitLab ne publie pas encore le scénario complet permettant de déclencher la vulnérabilité depuis son application. Comme pour ses autres failles de sécurité, les détails techniques complets ne seront rendus publics qu’après une période de protection destinée à laisser aux administrateurs le temps de mettre à jour leurs serveurs.
Deuxième faille critique dans les expressions régulières en neuf jours
La découverte est d’autant plus notable qu’elle intervient seulement neuf jours après une autre vulnérabilité GitLab notée 10 sur 10.
Le 12 octobre, GitLab avait corrigé CVE-2026-97229, une autre faille liée à la compilation d’expressions régulières. Celle-ci pouvait également permettre à un utilisateur non authentifié d’exécuter du code arbitraire sur le serveur via une expression spécialement conçue dans certaines configurations CI/CD.
Les deux vulnérabilités sont distinctes. La nouvelle CVE-2026-110264 possède surtout un périmètre beaucoup plus large puisque GitLab considère les versions remontant jusqu’à la branche 7.0 comme affectées.
GitLab fournit déjà des indicateurs pour rechercher une exploitation
GitLab a publié deux mécanismes de détection destinés aux administrateurs d’instances auto-hébergées afin de rechercher d’éventuelles traces d’exploitation de CVE-2026-110264.
Ils surveillent notamment des plantages anormaux du moteur Onigmo ainsi que des vagues inhabituelles d’erreurs lors du rendu de contenu au format Org.
La publication de ces règles ne signifie pas que GitLab a observé des attaques dans la nature. L’entreprise ne signale actuellement aucune exploitation confirmée publiquement, mais recommande malgré tout une mise à jour immédiate.
Une seconde faille permet de prendre le contrôle d’un compte LDAP
La mise à jour corrige également CVE-2026-15723, notée 8,2 sur 10. Elle concerne les entreprises utilisant simultanément OmniAuth SAML et la liaison automatique avec LDAP.
Dans cette configuration précise, un utilisateur déjà authentifié pouvait potentiellement s’approprier le compte GitLab existant d’un utilisateur LDAP, sans aucune intervention de la victime.
Le problème provenait d’une validation insuffisante des données utilisées lors de la recherche de l’adresse email LDAP et de l’association automatique des identités.
OAuth et OpenID Connect également touchés
Une troisième vulnérabilité importante, CVE-2026-112212, reçoit un score de 7,5 sur 10. Un attaquant non authentifié pouvait, dans certaines conditions, empoisonner le cache contenant les informations de découverte OAuth ou OpenID Connect.
L’objectif pouvait être de faire apparaître dans ces documents des URL contrôlées par l’attaquant. Certains flux d’authentification pouvaient alors être redirigés vers un serveur externe.
Cette attaque nécessite davantage de conditions et une interaction utilisateur, mais elle pourrait permettre la récupération d’informations sensibles liées à une procédure d’authentification.
Des projets privés et identifiants internes également concernés
Les neuf autres vulnérabilités corrigées sont moins critiques mais touchent plusieurs mécanismes sensibles de GitLab.
L’une permettait notamment à un utilisateur authentifié de récupérer les titres, descriptions et chemins complets de milestones appartenant à des projets privés auxquels il n’était pourtant pas membre.
Une autre pouvait exposer, dans certaines conditions, des identifiants internes du serveur présents dans des en-têtes de réponse insuffisamment filtrés.
GitLab corrige également une faiblesse permettant de récupérer l’adresse email entrante d’un projet via GraphQL et de créer des work items malgré les restrictions normalement imposées à un token limité à read_api.
La version Enterprise corrige de son côté plusieurs problèmes permettant de contourner des restrictions SAML ou LDAP, des politiques d’approbation de merge requests, des contrôles GitLab Duo ou encore de supprimer certains enregistrements de vulnérabilités avec des permissions qui n’auraient normalement pas dû le permettre.
Sept versions corrigées publiées simultanément
Pour couvrir les différentes branches encore utilisées, GitLab a publié simultanément les versions suivantes :
- 19.5.1
- 19.4.3
- 19.3.6
- 19.2.9
- 19.1.9
- 19.0.10
- 18.11.13
Pour CVE-2026-110264, toute installation antérieure à ces versions doit être considérée comme vulnérable sur la branche correspondante.
GitLab.com est déjà corrigé. Les utilisateurs du service SaaS n’ont donc aucune action à effectuer. Les clients GitLab Dedicated utilisant les versions internes récentes indiquées par l’éditeur disposent également déjà du correctif.
Les serveurs GitLab auto-hébergés doivent être mis à jour immédiatement
L’alerte concerne avant tout les entreprises, administrations et développeurs qui exploitent leur propre instance GitLab. Ces serveurs contiennent souvent une quantité considérable d’informations sensibles : code source privé, secrets CI/CD, variables d’environnement, clés de déploiement, tokens, packages et accès à des infrastructures de production.
Une exécution de code sur le serveur GitLab peut donc avoir des conséquences beaucoup plus importantes que la seule compromission de l’application elle-même. Un attaquant pourrait potentiellement utiliser cet accès comme point de départ vers les dépôts, les pipelines de déploiement et d’autres ressources internes.
GitLab recommande explicitement de mettre à jour toutes les instances concernées sans attendre. Certaines versions nécessitent également des migrations de base de données : une installation sur un seul serveur peut subir une courte interruption pendant la mise à jour, tandis qu’une infrastructure multi-nœuds peut appliquer le correctif sans coupure en suivant la procédure prévue par GitLab.
Avec une vulnérabilité CVSS 10 permettant théoriquement une exécution de code sans compte, la priorité est néanmoins claire : les instances GitLab accessibles depuis Internet ne devraient pas rester sur une version vulnérable.
Source originale : Cyberattaque.org.
Image d’illustration : Centaur server room (2293424530).jpg — VIA Gallery from Hsintien, Taiwan — CC BY 2.0, via Wikimedia Commons.
