L'essentiel au 1er novembre 2026
- Avis : CERTFR-2026-AVI-1427 (30 octobre), CVE-2026-111943, risque « contournement de la politique de sécurité ».
- Cause : huit autorités intermédiaires eMudhra aux clés trop simples, issues d'une cérémonie de génération de clés en avril 2025.
- Exploitation : aucune connue à ce jour ; navigateurs protégés, outils non-navigateur plus exposés.
- À faire : GitLab CE/EE, GitLab Runner 19.5.1, AI Gateway, magasins de certificats des images CI et des langages.
Ce qui s'est passé : de la clé « numéro 4 » à l'avis du CERT-FR
Le samedi 17 octobre 2026 à 20 h 06 UTC, Mozilla reçoit un signalement : les clés privées de huit certificats intermédiaires d'eMudhra sont compromises. Selon Scott Helme, l'une d'elles est littéralement « le nombre 4 » ; d'autres valent 56, 115 ou 237, alors qu'une clé P-384 devrait être un nombre aléatoire de 384 bits (The Register, 20 octobre 2026). Chrome et Firefox bloquent les certificats en quelques heures. eMudhra reconnaît dans sa déclaration (déclaration d'eMudhra, mise à jour du 30 octobre) qu'une étape de la cérémonie de génération de clés d'avril 2025 a produit un second jeu de clés faibles, publié dans les magasins de racines des navigateurs. L'erreur est restée environ 18 mois sans être détectée, à travers deux cycles d'audit. L'entreprise précise que les huit intermédiaires sont révoqués, que sept n'ont jamais servi en production et que le seul déployé n'a émis aucun certificat. Environ 30 800 certificats rattachés à la racine ECC distrustée, appartenant à un seul écosystème client américain, sont touchés. Le 30 octobre, elle a annoncé la nomination de KPMG comme examinateur externe indépendant. Une incohérence mérite d'être signalée : la déclaration d'eMudhra date la révocation du 18 octobre dans une mise à jour, et « dans les 14 heures » suivant la confirmation du problème dans une autre. Le site de divulgation indépendant donne pour sa part la chronologie des blocages par les éditeurs de navigateurs et de systèmes : Microsoft le 20 octobre, Apple le 22 octobre (site de divulgation).Documents de référence (sources primaires)
CERT-FR, avis CERTFR-2026-AVI-1427 — Vulnérabilité dans GitLabPublié le 30 octobre 2026 ; liste complète des versions GitLab CE/EE et AI Gateway concernées.GitLab, note de version 19.5.3 (29 octobre 2026)Versions corrigées, consignes pour GitLab Runner et AI Gateway, avertissement sur l'interruption de service.eMudhra, déclaration sur l'incident de sécurité des certificatsChronologie, périmètre, révocation et mesures, dernière mise à jour du 30 octobre 2026.Pourquoi GitLab, et pourquoi pas seulement GitLab
Les navigateurs reçoivent les révocations automatiquement et exigent que les certificats figurent dans des journaux publics (Certificate Transparency). Or ces certificats n'ont jamais été journalisés : un navigateur à jour les refuse. Les autres logiciels, eux, ne vérifient en général pas la révocation. Le site de divulgation cite les outils en ligne de commande, les applications qui embarquent leur propre liste d'autorités (Electron, par exemple) et les proxys qui interceptent le TLS (eMudhra, site de divulgation). GitLab a donc retiré les huit certificats de ses magasins : c'est le contenu du correctif de la version 19.5.3 et des branches maintenues, de 18.11.14 à 19.4.5. La mise à jour du serveur ne suffit pas : GitLab Runner vérifie les certificats de son côté et doit passer en 19.5.1, les images de jobs qui embarquent leur propre paquet ca-certificates doivent être reconstruites, et l'AI Gateway auto-hébergée a ses propres versions corrigées (GitLab, note de version). Le sujet déborde GitLab. Selon Endor Labs, des correctifs existent pour Python (certifi 2026.10.19), Go (1.27.3 et 1.26.10, suivi sous le même identifiant CVE-2026-111943), Node.js (22.23.4, 24.22.1, 26.12.1), Alpine (ca-certificates 20261020-r0) ainsi que pour les paquets Debian et Ubuntu. En revanche, le magasin cacerts de Java n'apparaît pas dans la liste, Red Hat n'avait pas de paquet à la date de The Hacker News (contournement : retirer les racines et reconstruire), et un conteneur construit avant le correctif reste vulnérable tant qu'il n'est pas reconstruit (Endor Labs, The Hacker News).Ce que cela change pour les équipes tech des Hauts-de-France
Il n'existe pas, à notre connaissance, de chiffre public sur le nombre d'instances GitLab auto-hébergées dans la région. Le seul repère d'échelle disponible est ancien : une étude d'Euratechnologies relayée par Le Monde Informatique (22 mars 2023) comptait 17 522 établissements informatiques en Hauts-de-France en 2021, dont 95 % de PME, et la Métropole européenne de Lille concentrait près de 63 % des emplois numériques régionaux. Ce sont des données de 2021, à lire comme un ordre de grandeur et non comme un état actuel. Concrètement, trois profils sont concernés. Les ESN et agences web de la métropole lilloise qui hébergent leurs dépôts et leurs pipelines sur un GitLab maison ; les PME industrielles ou logistiques qui ont une petite équipe de développement interne et un serveur de build oublié dans un coin du réseau ; les startups qui déploient depuis des images Docker anciennes. Dans les trois cas, le point faible n'est pas l'application visible par les clients, mais la chaîne de livraison : un serveur de build qui accepte un faux certificat peut télécharger une dépendance falsifiée ou envoyer des secrets vers un faux service. C'est la même logique que dans notre article sur le compromis de l'outil en ligne de commande OVHcloud ; voir aussi nos articles sur les failles GLPI et sur l'alerte CERT-FR Metabase. Il faut aussi relativiser. Le risque réel suppose un attaquant capable de se placer sur le trajet réseau (Wi-Fi hostile, DNS détourné, proxy compromis) avec un certificat forgé à partir d'une clé faible. Rien n'indique que cela ait eu lieu, et eMudhra affirme qu'aucun indice d'usage n'existe avant la divulgation.Cinq vérifications à faire cette semaine
- Inventoriez vos GitLab. Auto-hébergé ou GitLab.com ? Seules les instances auto-hébergées (et leurs Runner et AI Gateway) sont à traiter ; GitLab.com est déjà corrigé.
- Mettez à jour dans le bon ordre. Sauvegarde, puis serveur (18.11.14 à 19.5.3 selon votre branche), puis Runner en 19.5.1, puis AI Gateway. Sur un serveur à un nœud, prévoyez une coupure.
- Reconstruisez vos images CI et vos conteneurs. Une image bâtie avant le correctif garde l'ancienne liste d'autorités. Repartez d'une image de base à jour.
- Testez le magasin de certificats. Sur Linux,
grep -c "emSign" /etc/ssl/certs/ca-certificates.crtdoit renvoyer 0. Python : certifi 2026.10.19 ou plus ; Go : 1.26.10 ou 1.27.3 ; Node.js : versions corrigées ci-dessus. - Ne supprimez pas les racines à la main sans test. Retirer une racine coupe aussi les certificats légitimes émis sous elle ; préférez un bundle à jour, et vérifiez que vos propres sites ne chaînent pas vers emSign ECC Root CA - G3 (Chrome l'a retirée le 27 octobre).
Vérification rapide d'un serveur Linux
grep -c "emSign" /etc/ssl/certs/ca-certificates.crt # 0 = aucune racine emSign dans le magasin système
Méthode proposée par Endor Labs. Endor Labs indique aussi des hôtes de test où une erreur de certificat est le résultat attendu ; un test réussi ou échoué ne prouve pas toujours grand-chose à lui seul, vérifiez aussi vos proxys.
Ce que nous ne savons pas
Nous n'avons pas pu ouvrir directement la fiche CVE-2026-111943 et nous nous appuyons sur le CERT-FR, la note de GitLab et la presse spécialisée. Nous ne connaissons ni le score CVSS, ni le nombre d'instances GitLab exposées en France ou dans la région, ni l'existence d'une exploitation. Les causes profondes de l'erreur d'eMudhra ne sont pas encore confirmées par l'entreprise, qui annonce une analyse via le processus CCADB. Nous mettrons cet article à jour si de nouvelles informations sont publiées.FAQ : l'incident eMudhra et GitLab
Mon site web est-il en danger à cause d'eMudhra ?
Probablement pas directement. Les navigateurs courants ont bloqué les huit certificats intermédiaires en quelques heures et exigent la Certificate Transparency, or ces certificats n'ont jamais été journalisés (The Hacker News). Le risque concerne surtout les logiciels qui ne sont pas des navigateurs : outils en ligne de commande, bibliothèques, serveurs de build et applications qui embarquent leur propre liste d'autorités.
Quelles versions de GitLab faut-il viser ?
Selon l'avis CERTFR-2026-AVI-1427 et la note de GitLab du 29 octobre 2026 : 18.11.14, 19.0.11, 19.1.10, 19.2.10, 19.3.7, 19.4.5 ou 19.5.3 pour GitLab CE/EE auto-hébergé. GitLab Runner doit passer en 19.5.1, et l'AI Gateway auto-hébergée a ses propres versions corrigées. GitLab.com est déjà corrigé.
La mise à jour de GitLab va-t-elle couper le service ?
Sur une instance à un seul nœud, oui : GitLab précise que les migrations de base de données doivent se terminer avant le démarrage, et que les versions 19.5.3 et 19.4.5 contiennent des migrations régulières. Une installation multi-nœuds peut suivre la procédure sans interruption. Prévoyez une fenêtre de maintenance et une sauvegarde.
Les clés ont-elles été utilisées par des pirates ?
Aucune exploitation n'est connue à ce jour. eMudhra indique qu'il n'y a pas d'indice d'usage avant la divulgation, et Chrome n'a trouvé aucun certificat malveillant dans les journaux de transparence. Mais The Hacker News rappelle qu'aucune source ne permet de détecter un usage passé hors de ces journaux, qui ne couvrent que les certificats journalisés.
Comment savoir si mon serveur fait encore confiance aux certificats concernés ?
Sur Linux, la commande grep -c "emSign" /etc/ssl/certs/ca-certificates.crt doit renvoyer 0 (méthode proposée par Endor Labs). Pour un conteneur, lancez-la dans l'image, pas sur l'hôte. Pour Java, le magasin cacerts du JDK n'apparaît pas dans la liste des correctifs : considérez-le comme non confirmé tant que l'éditeur de votre JDK n'a pas publié de mise à jour.
Sources : CERT-FR, CERTFR-2026-AVI-1427 · GitLab, version 19.5.3 · eMudhra, déclaration · site de divulgation · The Register, 20 octobre 2026 · The Hacker News · Endor Labs · Le Monde Informatique, 22 mars 2023
