Le Centre gouvernemental de veille, d’alerte et de réponse aux attaques informatiques (CERT-FR), rattaché à l’Agence nationale de la sécurité des systèmes d’information (ANSSI), a publié le 30 octobre 2026 un avis de sécurité concernant GitLab. Référencée CVE-2026-111943, la vulnérabilité est classée comme un risque de contournement de la politique de sécurité. Elle touche plusieurs versions des éditions Community et Enterprise de GitLab, ainsi que son composant AI Gateway.
Le problème ne porte pas sur un accès frauduleux déjà établi à une plateforme GitLab donnée. Il résulte de la confiance accordée à des certificats intermédiaires d’une autorité de certification dont les clés privées ont été compromises. Dans sa note de mise à jour du 29 octobre, GitLab indique avoir retiré de ses magasins de certificats huit certificats intermédiaires eMudhra concernés.
GitLab, Runner et AI Gateway doivent être vérifiés séparément
GitLab recommande la mise à jour des installations autohébergées vers les versions corrigées : 18.11.14, 19.0.11, 19.1.10, 19.2.10, 19.3.7, 19.4.5 ou 19.5.3, selon la branche déployée. Le CERT-FR recense ces seuils dans son avis. La plateforme GitLab.com fonctionne déjà avec une version corrigée, précise l’éditeur.
Pour les administrateurs de chaînes d’intégration et de déploiement continus (CI/CD), un point mérite une attention particulière : la mise à jour du serveur GitLab ne met pas automatiquement à jour GitLab Runner. GitLab demande de porter les Runner autohébergés à la version 19.5.1 et de reconstruire les images de tâches qui embarquent leur propre ensemble de certificats d’autorités de confiance. Les instances AI Gateway autohébergées doivent également recevoir une version corrigée, dont 19.5.3 pour la branche 19.5, avec des versions spécifiques pour les branches antérieures.
Un incident de certification aux effets plus larges que GitLab
Le dossier technique consacré aux certificats eMudhra, publié le 20 octobre puis actualisé le 28, documente la compromission des clés privées de huit autorités intermédiaires. Une telle clé peut servir à produire des certificats susceptibles d’être acceptés par un logiciel qui continue de faire confiance à l’autorité compromise. Les navigateurs et plusieurs systèmes ont déjà pris des mesures de blocage, mais certaines applications disposent de leurs propres magasins de certificats et nécessitent une mise à jour distincte.
Les responsables d’exploitation doivent donc vérifier les versions de leurs serveurs, de leurs exécutants CI/CD et des passerelles d’intelligence artificielle, puis suivre les procédures de mise à niveau de l’éditeur. GitLab avertit que certaines migrations de base de données peuvent interrompre le service sur une installation à serveur unique ; une architecture à plusieurs nœuds peut suivre une procédure de mise à niveau sans interruption, sous réserve d’une préparation adaptée. Le CERT-FR n’attribue pas à cet avis un nombre d’organisations compromises ni un bilan d’attaques observées.
