GitLab a publié le 29 octobre 2026 une série de mises à jour de sécurité destinée à retirer la confiance accordée à huit certificats intermédiaires de l’autorité eMudhra, dont les clés privées ont été compromises. 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 relayé l’alerte le 30 octobre sous la référence CERTFR-2026-AVI-1427. Le risque identifié est un contournement de la politique de sécurité, référencé CVE-2026-111943.
Une rupture de confiance dans la vérification des certificats
Dans son bulletin de mise à jour, GitLab explique avoir supprimé de ses magasins de certificats la confiance accordée à huit autorités intermédiaires eMudhra. Le problème dépasse la seule plateforme de développement : un certificat signé au moyen d’une clé compromise peut, selon les conditions de vérification du client, servir à usurper l’identité d’un service lors d’une connexion chiffrée.
Le dossier technique consacré à l’incident eMudhra, initialement publié le 20 octobre, indique que les clés privées en cause étaient récupérables à partir des certificats en raison d’une génération défectueuse. Les principaux navigateurs ont engagé des mesures de blocage, mais certains outils et bibliothèques utilisent leurs propres listes de certificats de confiance. La correction du navigateur ou du système d’exploitation ne suffit donc pas nécessairement à sécuriser tous les composants d’une chaîne de développement.
GitLab, Runner et AI Gateway doivent être contrôlés séparément
Pour GitLab Community Edition et Enterprise Edition, l’éditeur recommande notamment les versions corrigées 19.5.3, 19.4.5, 19.3.7, 19.2.10, 19.1.10, 19.0.11 et 18.11.14, selon la branche utilisée. Les installations auto-hébergées doivent être mises à jour ; GitLab indique avoir déjà corrigé son infrastructure hébergée.
Deux composants appellent une vérification distincte. GitLab Runner auto-hébergé doit passer à la version 19.5.1 : la mise à jour du serveur GitLab ne met pas automatiquement à jour les agents qui exécutent les tâches d’intégration et de déploiement continus (CI/CD). Les images utilisées par ces tâches peuvent également embarquer leur propre paquet de certificats et nécessiter une reconstruction. Pour AI Gateway, les versions corrigées varient selon les branches, de 18.11.8 à 19.5.3, comme le précise le bulletin de l’éditeur.
Un contrôle à intégrer aux opérations de maintenance
Pour les équipes qui administrent des dépôts de code, des pipelines CI/CD et des environnements de développement sensibles, la priorité est de dresser l’inventaire des instances auto-hébergées et des composants associés, puis de vérifier leurs versions et leurs magasins de certificats. Le bulletin GitLab avertit également que certaines mises à jour comportent des migrations de base de données : une installation sur un seul serveur peut subir une interruption pendant l’opération, tandis qu’une architecture à plusieurs nœuds peut suivre une procédure adaptée.
Les documents consultés établissent une compromission des clés et la nécessité de retirer les certificats concernés de la chaîne de confiance. Ils ne permettent pas d’affirmer qu’une intrusion a été constatée dans une installation GitLab particulière. L’enjeu opérationnel est d’appliquer les correctifs à l’ensemble des composants qui vérifient les certificats, plutôt qu’au seul serveur principal.
