if ( !emtpy($headline_subheadline ) ) : ?>
Le fournisseur recommande fortement aux clients de mettre à niveau vers les versions corrigées dès que possible.
endif; ?>
GitLab a publié mercredi des versions mises à jour de ses éditions Community Edition (CE) et Enterprise Edition (EE) qui corrigent une douzaine de bugs et de problèmes de sécurité, dont certains permettent diverses actions non authentifiées.
Le plus grave des problèmes de sécurité, qualifié de critique en termes de gravité, est CVE-2026-110264, un problème de dépassement d’entier. « GitLab a résolu un problème qui, sous certaines conditions, aurait pu permettre à un utilisateur non authentifié d’exécuter du code arbitraire sur le serveur GitLab en raison d’un dépassement d’entier lors de la compilation d’une expression régulière spécialement conçue », a déclaré GitLab dans son bulletin. « En plus de nos versions de correctifs standard, nous avons rétroporté ce correctif vers les versions 18.11.13, 19.0.10, 19.1.9 et 19.2.9 de GitLab CE/EE. »
Les versions concernées de GitLab CE/EE incluent toutes les versions de 7.0 avant 18.11.13, 19.0 avant 19.0.10, 19.1 avant 19.1.9, 19.2 avant 19.2.9, 19.3 avant 19.3.6, 19.4 avant 19.4.3 et 19.5 avant 19.5.1.
Les versions corrigées sont les versions 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 et 18.11.13.
Les correctifs corrigent également une faille de grande gravité identifiée comme CVE-2026-15723, un problème d’authentification incorrect dans la recherche de courrier électronique à liaison automatique OmniAuth vers LDAP qui affecte GitLab CE/EE, ce qui est un problème, a déclaré GitLab, car « lorsque la liaison automatique OmniAuth SAML et LDAP était activée, un utilisateur authentifié aurait pu reprendre un compte existant soutenu par LDAP sans aucune interaction de la part de l’utilisateur ciblé, en raison d’une saisie incorrecte. désinfection dans le chemin de recherche de courrier électronique LDAP utilisé lors de la liaison d’identité OmniAuth.
Il s’agit du quatrième problème de sécurité critique que GitLab rencontre en deux mois. Plus tôt en octobre, il a corrigé une faille d’expression régulière de gravité maximale et, en septembre, il a corrigé CVE-2026-85706, également classé parfait 10 en termes de gravité. Un autre rapport de septembre a également révélé un problème préoccupant : un jeton de longue durée qui met en danger la sécurité des CI/CD.
Une action immédiate est nécessaire
Les analystes et les consultants ont convenu que les lacunes actuelles sont graves et méritent une action immédiate.
« Ce qui me frappe vraiment, c’est la source sous-jacente de la vulnérabilité », a déclaré Noah Kenney, consultant principal chez Digital 520. « Le problème provient d’un débordement d’entier au sein du compilateur d’expressions régulières, plutôt que d’une fonctionnalité développée spécifiquement par GitLab. »
Il a souligné que cette distinction est importante car elle met en évidence les risques associés aux dépendances et aux composants logiciels partagés. « Les organisations peuvent investir massivement dans la sécurisation de leurs propres applications tout en restant exposées aux vulnérabilités introduites par les bibliothèques et les frameworks sous-jacents », a-t-il déclaré. « Le fait que ce problème affecte potentiellement les versions remontant à GitLab 7.0 démontre combien de temps ces vulnérabilités peuvent persister avant d’être identifiées et corrigées. »
Kenney a ajouté que les RSSI devraient accorder une attention particulière à une brève mention dans le message GitLab.
« Enfouie dans les corrections de bugs, même pas dans la liste CVE, se trouve une ligne concernant la suppression de l’indicateur de confiance des outils MCP fournis par le client dans Workhorse », a-t-il déclaré. « En termes simples, GitLab a trouvé une voie permettant à un agent d’IA de recevoir des outils auxquels il n’aurait pas dû faire confiance et l’a fermé en silence. Cela soulève un problème important concernant les limites de confiance dans les systèmes compatibles avec l’IA. »
Frank Dickson, analyste principal chez Dickson Research, a noté que ces failles sont particulièrement troublantes en raison de la nature hautement intégrée des systèmes GitLab.
« GitLab n’est pas seulement un référentiel de code. Il contient le code source, les pipelines CI/CD et très souvent les secrets que ces pipelines utilisent pour se déployer en production », a-t-il déclaré. « Posséder le serveur GitLab signifie posséder les clés du royaume. Un attaquant n’a pas besoin de s’introduire en production lorsque le système qui construit la production le fera à sa place. »
Dickson a également souligné le fait que le déploiement de ces correctifs pourrait nécessiter beaucoup de temps.
« Prévoyez les temps d’arrêt », a-t-il déclaré. « Les notes de publication de GitLab indiquent que ce correctif inclut les migrations de bases de données et que les instances à nœud unique seront indisponibles pendant leur exécution. Quelqu’un demandera d’attendre le week-end. Attendre est une acceptation du risque. Cette décision appartient à un dirigeant, pas à l’équipe DevOps. «
Risques supplémentaires
En outre, il a souligné que la nature de ces failles indique clairement que de nombreux autres fournisseurs d’entreprise pourraient également souffrir de problèmes similaires.
« La faille réside dans Ruby, pas seulement dans le code de GitLab. Les notes de version de GitLab montrent que le correctif est livré comme un correctif pour la gestion des expressions régulières de Ruby, et l’une de ses détections porte le nom d’Onigmo, le moteur d’expression régulière de Ruby », a déclaré Dickson. « GitLab n’est peut-être pas la seule application Ruby à présenter ce bug. Les RSSI devraient demander à leurs autres fournisseurs. «
De plus, Ty Coffee, directeur du cabinet de conseil UHY, a souligné que le bug LDAP augmente le risque qu’une enquête post-violation puisse accidentellement pointer du doigt un employé innocent.
« Si un attaquant s’empare d’un compte sauvegardé par LDAP, tout ce qu’il fait est enregistré sous le nom d’un employé légitime, et votre piste d’audit pointe alors vers la mauvaise personne », a déclaré Coffee. « Les RSSI doivent également vérifier les serveurs GitLab fantômes et hérités, tels que les instances gérées par une équipe, les anciennes copies DR, les serveurs de l’entreprise acquise, (car) cela affecte les anciennes versions et cela signifie que les boîtes oubliées sont dans le champ d’application. »
