eMudhra : 8 certificats CA compromis, GitLab impose des patches en urgence

Les faits

Le 17 octobre 2026, un chercheur en sécurité indépendant signale à eMudhra — autorité de certification publique indienne accréditée WebTrust et intégrée dans les magasins de confiance d'Apple, de Microsoft et de Mozilla — que les clés privées de plusieurs de ses certificats intermédiaires peuvent être mathématiquement recalculées à partir des seuls certificats publics. Le problème est une erreur dans le processus de génération de clés (key ceremony) : les paramètres cryptographiques utilisés lors de la génération étaient insuffisamment aléatoires, rendant les clés faibles et récupérables.

eMudhra réagit rapidement : le 18 octobre, l'autorité révoque les huit certificats intermédiaires concernés. Apple met à jour sa liste de révocation le 19 octobre, Microsoft le 20 octobre. Le 29 octobre, GitLab publie une série de patches de sécurité qui retirent explicitement la confiance accordée à ces huit intermédiaires eMudhra dans ses composants internes. La CVE associée, CVE-2026-111943, est classée par le CERT-FR comme un risque de « contournement de la politique de sécurité ».

La gravité de l'incident tient au rôle central de ces certificats dans les chaînes de confiance TLS. Un certificat intermédiaire dont la clé privée est récupérable permet à son découvreur de signer des certificats feuilles légitimes en apparence pour n'importe quel domaine couvert par la chaîne. En d'autres termes, si un acteur malveillant avait découvert cette faiblesse avant le chercheur, il aurait pu émettre des certificats TLS valides pour des domaines tiers — permettant des attaques man-in-the-middle non détectées par les navigateurs et les clients TLS non mis à jour.

L'ampleur pour les utilisateurs de GitLab est particulièrement large. GitLab est utilisé par des centaines de milliers d'organisations pour leurs pipelines CI/CD. La demande de mise à jour ne concerne pas uniquement l'instance GitLab principale : elle s'étend aux GitLab Runner auto-hébergés (qui doivent être portés à la version 19.5.1 minimum) et aux images de jobs CI/CD qui embarquent leur propre bundle de certificats CA. Ces images doivent être reconstruites — un point souvent négligé lors des incidents de mise à jour de PKI.

Le CERT-FR indique dans son avis du 30 octobre 2026 que plusieurs versions de GitLab sont concernées : 19.5.x antérieures à 19.5.3, 19.4.x antérieures à 19.4.5, 19.3.x antérieures à 19.3.7, 19.2.x antérieures à 19.2.10, 19.1.x antérieures à 19.1.10, 19.0.x antérieures à 19.0.11, et les branches 18.x antérieures à 18.11.14. L'éditeur insiste sur le fait que GitLab Core, Runner et AI Gateway doivent être mis à jour séparément, car ils embarquent des bundles de certificats CA distincts.

L'incident soulève une question de gouvernance plus large : comment les équipes sécurité surveillent-elles les révocations de certificats intermédiaires ? La plupart des outils de monitoring TLS se concentrent sur l'expiration des certificats feuilles. La révocation d'un intermédiaire, si elle n'est pas poussée via OCSP Stapling ou CRL téléchargée proactivement, peut passer inaperçue pendant des heures — fenêtre pendant laquelle le risque man-in-the-middle reste ouvert.

Sur le plan réglementaire, l'article 21 de la directive NIS2 impose aux entités essentielles et importantes de gérer les risques liés à la chaîne d'approvisionnement. Une dépendance à une PKI tierce sans surveillance active constitue un vecteur de risque systémique. Les entités régulées par NIS2 ou DORA doivent documenter leurs dépendances PKI et démontrer leur capacité à réagir à ce type d'incident dans leurs exercices de gestion de crise.

Impact et exposition

Toutes les organisations utilisant GitLab en version antérieure aux patches du 29 octobre 2026 sont exposées. Les environnements CI/CD avec des Runners auto-hébergés ou des images de jobs personnalisées sont particulièrement à risque si leurs bundles CA ne sont pas mis à jour. Plus largement, tout système ayant fait confiance aux certificats eMudhra pour des connexions TLS actives avant révocation aurait pu être ciblé par une attaque man-in-the-middle lors de la fenêtre du 17 au 20 octobre 2026.

Recommandations

• Immédiat : mettre à jour GitLab vers 19.5.3, 19.4.5, 19.3.7, 19.2.10, 19.1.10, 19.0.11 ou 18.11.14 selon votre version de déploiement.
• Mettre à jour les GitLab Runner auto-hébergés vers la version 19.5.1 ou supérieure.
• Reconstruire toutes les images Docker de jobs CI/CD qui embarquent leurs propres stores de certificats CA.
• Auditer les connexions TLS actives et les stores de certificats de confiance sur les serveurs d'applications et reverse proxies.
• Mettre en place une surveillance proactive des révocations OCSP et CRL pour les certificats intermédiaires utilisés dans vos chaînes de confiance.