Une faille critique permettrait de pirater sans compte les serveurs GitLab des entreprises
GitLab a publié le 21 octobre des correctifs pour une faille présente dans toutes les versions depuis la 7.0. Aucune attaque n'est signalée à ce stade : les versions à installer et les signes à guetter.

Dix jours après une première faille de gravité maximale, GitLab doit de nouveau corriger en urgence. Le 21 octobre, l'éditeur de cette plateforme de développement, qui sert en entreprise à héberger le code source et à automatiser les déploiements, a publié sept versions corrigées. Elles comblent une faille référencée CVE-2026-110264, notée 10 sur 10 sur l'échelle de gravité CVSS.
D'après l'avis de GitLab, un utilisateur sans compte pourrait, « dans certaines conditions », exécuter le code de son choix sur le serveur. Les éditions Community et Enterprise sont touchées, depuis la version 7.0 : douze ans de versions, a relevé The Hacker News. GitLab.com et les instances GitLab Dedicated sont déjà corrigées. Seules les installations gérées par les entreprises elles-mêmes doivent être mises à jour.
Une recherche de texte piégée pourrait suffire
La faille se trouve dans le composant qui compile les expressions régulières, ces motifs de recherche de texte. Selon BleepingComputer, ce moteur analyse et valide les expressions régulières présentes dans les fichiers de configuration. Une expression spécialement fabriquée peut y provoquer un dépassement de capacité d'un nombre entier (en anglais integer overflow). GitLab ne détaille pas les conditions nécessaires.
Le découvreur est un chercheur connu sous le pseudonyme joaxcar, qui l'a signalée via le programme de récompenses de GitLab sur la plateforme HackerOne. C'est le même qui avait trouvé la faille corrigée mi-octobre. Selon BleepingComputer, elle touchait déjà le compilateur d'expressions régulières, dans la partie consacrée à l'intégration continue.
Pas d'attaque connue, mais des précédents
Pour l'instant, ni GitLab ni l'agence américaine de cybersécurité (CISA) ne signalent d'exploitation. Les précédents incitent pourtant à ne pas attendre. Selon BleepingComputer, la CISA a classé cinq failles de GitLab comme exploitées depuis novembre 2021, dont une par un rançongiciel. Une faille critique corrigée le mois dernier a même rejoint son catalogue des failles exploitées dès le lendemain du correctif. La fondation Shadowserver recense plus de 2 700 instances GitLab Community Edition exposées sur Internet.
Les mêmes versions corrigent onze autres failles. Deux sont jugées élevées : CVE-2026-15723 (8,2 sur 10), qui pourrait permettre de prendre le contrôle d'un compte lors de l'association automatique entre une connexion externe et l'annuaire LDAP ; et CVE-2026-112212 (7,5), un empoisonnement de cache qui touche la découverte des services de connexion OAuth et OpenID Connect.
Quelle version installer, et comment vérifier
- Selon votre branche, passez à la 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 ou 18.11.13.
- L'avis ne liste aucun correctif pour les branches antérieures à la 18.11 : il faut migrer vers une branche maintenue.
- Les versions 19.4.3 et 19.3.6 modifient la base de données. Un serveur unique sera indisponible pendant la mise à jour ; les installations sur plusieurs serveurs peuvent suivre la procédure de GitLab sans interruption.
- GitLab publie deux règles de détection pour repérer d'éventuelles tentatives, à rechercher dans vos journaux : « Onigmo native worker crash » et « Org mode render error burst ».
Une instance GitLab contient le code source, les secrets des chaînes de déploiement et souvent des accès à la production. Reste à savoir combien de temps il faudra avant que des détails techniques ou un code d'exploitation circulent. C'est souvent à ce moment que les attaques commencent.
Méthode : veille assistée par intelligence artificielle, sources vérifiées, article relu et validé par Frédéric LENQUETTE. Notre charte éditoriale.
Partager cet article