Une vulnérabilité de GitLab notée 10,0 sur 10 pourrait permettre à des attaquants d’exécuter du code malveillant sur les serveurs concernés, mettant en danger les systèmes de développement et de déploiement logiciels.
GitLab a publié des mises à jour de sécurité le 12 octobre 2026, corrigeant 24 vulnérabilités dans Community Edition (CE) et Enterprise Edition (EE). La plus grave, CVE-2026-97229, pourrait permettre l’exécution de code à distance sans authentification dans certaines conditions. Les administrateurs des installations autogérées concernées sont invités à effectuer la mise à jour immédiatement.
Des chercheurs en sécurité ont reproduit l’exploit, confirmant une voie d’attaque concrète. Bien qu’aucune attaque contre des organisations n’ait été confirmée, des serveurs GitLab compromis pourraient exposer le code source, les identifiants et l’infrastructure de déploiement connectée.
Une faille de GitLab expose les serveurs à l’exécution de code à distance
L’avis de sécurité de GitLab du 12 octobre identifie un dépassement d’entier dans le compilateur d’expressions régulières de l’intégration et du déploiement continus (CI/CD). Une validation insuffisante pourrait permettre à une expression spécialement conçue, intégrée à une configuration CI/CD malveillante, de déclencher l’exécution de code arbitraire.
Selon son évaluation CVSS, la vulnérabilité présente une faible complexité d’attaque et ne nécessite ni authentification ni interaction de l’utilisateur.
La société de cybersécurité Rapid7 a reproduit l’exploit contre une instance CE de GitLab 19.4.1 qui n’avait pas été corrigée. Les chercheurs ont exécuté des commandes du système d’exploitation avec les privilèges de l’gitutilisateur.
L’attaque démontrée nécessitait une configuration CI/CD malveillante et un chemin de dépôt spécialement conçu. Sur les instances autorisant l’inscription publique et la création de projets, les attaquants pouvaient réunir ces conditions préalables en créant leurs propres projets.
L’exploit n’a pas réussi contre la version corrigée 19.4.2. Au 13 octobre, Rapid7 ne signalait aucune exploitation confirmée de CVE-2026-97229 dans la nature.
GitLab a corrigé une autre vulnérabilité critique en août, après l’observation de tentatives d’exploitation. Ces attaques impliquaient une faille distincte.
La version d’octobre corrige également CVE-2026-92883, une vulnérabilité de type cross-site scripting notée 8,7, ainsi que CVE-2026-16301, une faille d’autorisation notée 8,5 qui affecte les pipelines des branches protégées.
Correctifs GitLab et mesures de sécurité
GitLab identifie les versions suivantes comme correctifs pour CVE-2026-97229 :
- GitLab 19.2 : version 19.2.8.
- GitLab 19.3 : version 19.3.5.
- GitLab 19.4 : version 19.4.2.
GitLab.com est déjà corrigé, et les clients de GitLab Dedicated n’ont aucune action à effectuer. La version 19.3.5 corrige également un problème de demande de fusion introduit dans la version 19.3.4, désormais remplacée.
Ces versions corrigent CVE-2026-97229, mais les administrateurs ne doivent pas supposer qu’elles résolvent toutes les vulnérabilités affectant leur installation. L’avis de GitLab mentionne également CVE-2026-84284, qui affecte toutes les versions 19.3. Les administrateurs doivent consulter l’avis complet et suivre les recommandations de GitLab pour installer la dernière version de sécurité prise en charge.
Jusqu’à l’installation des mises à jour, restreindre l’accès aux projets non fiables peut réduire l’exposition à la voie d’attaque démontrée. Des mesures de protection supplémentaires peuvent contribuer à contenir une compromission, mais elles ne remplacent pas l’application des correctifs.
Les équipes de sécurité doivent :
- Vérifier le déploiement des correctifs : Inventorier les instances concernées, donner la priorité aux serveurs exposés à Internet et confirmer la réussite des mises à niveau.
- Restreindre l’accès aux éléments non fiables : Désactiver l’inscription publique superflue et empêcher les utilisateurs non fiables de créer ou de modifier des projets publics.
- Isoler l’infrastructure de développement : Segmenter les serveurs et les runners GitLab des réseaux sensibles et des systèmes de production.
- Protéger les identifiants CI/CD : Appliquer des listes d’autorisation pour les jetons de tâche et le principe du moindre privilège ; renouveler les identifiants potentiellement exposés en cas de suspicion de compromission.
- Surveiller les activités suspectes : Examiner les exécutions inattendues de pipelines, les modifications de dépôts, les processus inhabituels sur les serveurs et les tentatives d’authentification suspectes.
- Tester les plans de réponse aux incidents : Vérifier les procédures d’isolement des serveurs compromis, de préservation des preuves et de restauration de configurations fiables.
Ces contrôles renforcent également la sécurité dans les chaînes d’outils de développement, en particulier lorsque des pipelines automatisés accèdent à une infrastructure sensible.
Une compromission distincte du registre de modules de Coder en septembre a montré comment une infrastructure de développement fiable pouvait être détournée pour distribuer du code malveillant. Le rôle central de GitLab dans la fourniture de logiciels fait des serveurs compromis une passerelle potentielle vers le code source, les identifiants et les systèmes de production. Corriger les instances vulnérables et restreindre l’accès à l’infrastructure connectée peut contribuer à contenir les dégâts.
À lire : Une autre vulnérabilité GitLab ajoutée au catalogue des vulnérabilités exploitées de la CISA en septembre montre pourquoi l’analyse des activités suspectes doit accompagner l’application urgente des correctifs.