Cloudflare corrige ses systèmes après la compromission des clés de certificat d'eMudhra

Le 19 octobre 2026, Cloudflare a identifié que les clés privées de huit certificats intermédiaires d'eMudhra avaient été compromises. L'entreprise a immédiatement commencé à corriger son infrastructure et a publié des mises à jour pour ses logiciels clients afin d'empêcher une éventuelle interception du trafic. Cet incident affecte des autorités de certification largement reconnues et nécessite une action de la part des utilisateurs de certains services Cloudflare et d'applications auto-hébergées.

Ce qui s'est passé

La compromission implique des clés privées faibles associées à huit certificats intermédiaires émis par eMudhra. Étant donné que ces clés sont vulnérables, un attaquant pourrait forger des certificats pour n'importe quel domaine. Cela lui permettrait d'usurper l'identité de serveurs légitimes, d'intercepter le trafic chiffré ou de modifier les données en transit. Ces certificats étaient reconnus comme fiables par les principaux navigateurs, systèmes d'exploitation et l'infrastructure propre de Cloudflare, rendant l'impact potentiel large et grave.

L'équipe de sécurité de Cloudflare a détecté le problème vers 17h00 UTC le 19 octobre. Elle a priorisé la mise à jour des services critiques utilisant des certificats publics pour authentifier les points de terminaison distants. Cela incluait les proxys se connectant aux serveurs d'origine et les applications appelant des API externes. L'entreprise a également mis à jour les magasins de confiance partagés et les images de base pour fournir une voie d'atténuation commune aux services héritant de la confiance des certificats depuis ces sources. Au moment de la divulgation publique, Cloudflare n'a pas identifié d'exploitation active de cette vulnérabilité sur ses services.

Pour activer ces mesures d'atténuation, Cloudflare a effectué des rechargements, des redémarrages et des déploiements d'images à travers ses produits CDN, Developer et Zero Trust. Les applications avec des magasins de confiance intégrés ou personnalisés nécessitaient une évaluation et des mises à jour distinctes. L'entreprise souligne que cette correction traite des failles d'authentification basées sur les certificats, et non des faiblesses dans les algorithmes de chiffrement TLS eux-mêmes. Les travaux continuent pour garantir que tous les systèmes internes soient entièrement protégés.

Détails clés

• Les clés privées de huit certificats intermédiaires d'eMudhra ont été compromises en raison d'une faiblesse.
• Les attaquants peuvent forger des certificats pour n'importe quel domaine afin d'intercepter ou de modifier le trafic.
• Les utilisateurs de Cloudflare One Client doivent effectuer une mise à niveau vers v2.5.6 (Android), v1.12.16 (iOS) ou la version desktop 2026.8.2115.0.
• Les utilisateurs de Cloudflare Tunnel (cloudflared) doivent effectuer une mise à niveau vers la version 2026.10.2.
• Les clients utilisant le mode Full (strict) ou Strict pour le TLS d'origine doivent examiner leurs certificats personnalisés.
• Les mainteneurs de navigateurs ont utilisé des mécanismes de révocation rapide tels que Chrome CRLSets pour atténuer rapidement le problème.

Contexte

Les certificats Secure Sockets Layer (SSL) et Transport Layer Security (TLS) sont des fichiers numériques qui lient une clé cryptographique aux détails d'une organisation. Ils permettent des connexions chiffrées entre les serveurs web et les navigateurs. Le modèle de confiance repose sur des Autorités de Certification (CA) comme eMudhra pour vérifier l'identité avant d'émettre des certificats. Les certificats intermédiaires se situent entre la CA racine et le certificat de l'entité finale, créant une chaîne de confiance. Si une clé privée intermédiaire est compromise, l'intégrité de cette chaîne est rompue. Les attaquants peuvent alors émettre des certificats d'apparence valide pour des domaines qu'ils ne possèdent pas, contournant ainsi les avertissements de sécurité des navigateurs.

Les magasins de confiance sont des bases de données maintenues par les systèmes d'exploitation et les navigateurs qui listent les CA reconnues comme fiables. Lorsqu'un serveur présente un certificat, le client le vérifie par rapport à ce magasin. Dans cet incident, la faiblesse résidait dans la génération ou la gestion des clés par la CA, et non dans le protocole TLS lui-même. La remédiation consiste à retirer les certificats compromis des magasins de confiance ou à mettre à jour les logiciels pour les rejeter. Pour les environnements auto-hébergés, cela signifie souvent mettre à jour manuellement les paquets système ou les dépendances d'application qui gèrent leurs propres listes de confiance.

Pourquoi c'est important

Pour les équipes exploitant leur propre logiciel, cet incident met en lumière la fragilité de l'Infrastructure à Clé Publique Web (WebPKI). Contrairement aux utilisateurs de navigateurs qui reçoivent des mises à jour automatiques, les applications auto-hébergées peuvent compter sur des magasins de confiance statiques ou des paquets système obsolètes. Si votre application utilise un SDK qui délègue la vérification au système d'exploitation, une mise à jour système peut suffire. Cependant, si votre application intègre son propre magasin de confiance ou utilise une bibliothèque HTTP spécifique, vous devez mettre à jour ces dépendances directement. Ne pas le faire laisse vos services vulnérables aux attaques de type homme du milieu (man-in-the-middle).

Les développeurs doivent regarder sous la surface de leur pile logicielle. Mettre à jour un SDK de haut niveau peut ne pas changer la politique sous-jacente de vérification des certificats si la bibliothèque HTTP ou le runtime reste inchangé. Après avoir appliqué les correctifs, vous pouvez voir des erreurs de certificat dans les logs ou les tableaux de bord. Il est crucial de ne pas désactiver la vérification pour masquer ces erreurs. Ce faisant, vous supprimez la protection d'authentification que les mises à jour sont conçues pour restaurer. Valider la correction nécessite de tester le chemin TLS réel utilisé par l'application, et non simplement une vérification via un navigateur.

Cet événement souligne également la nécessité d'une surveillance robuste de la validité des certificats et de la confiance. Bien que les navigateurs puissent révoquer la confiance globalement via des mécanismes comme CRLSets, les serveurs individuels et les applications n'ont pas ce contrôle centralisé. Les équipes doivent gérer proactivement leurs configurations de confiance et surveiller les anomalies. Se fier uniquement aux paramètres système par défaut sans audits réguliers peut laisser des failles lorsqu'une CA est compromise. Des outils automatisés qui suivent le statut des certificats et les changements des magasins de confiance deviennent essentiels pour maintenir une posture de sécurité dans les environnements auto-hébergés.

Ce que vous pouvez faire

• Mettez à niveau les applications Cloudflare One Client et WARP vers les versions spécifiées pour votre plateforme immédiatement.
• Mettez à jour Cloudflare Tunnel (cloudflared) vers la version 2026.10.2 et redéployez les images de conteneur.
• Examinez et mettez à jour les magasins de confiance TLS mutuels si vous utilisez l'authentification client TLS configurée par le client.
• Vérifiez les configurations du serveur d'origine pour le mode Full (strict) ou Strict et remplacez tout certificat non reconnu comme fiable.
• Auditez les dépendances de l'application pour les paquets corrigés listés par Dennis Jackson de Mozilla et reconstruisez les images.
• Vérifiez les corrections en testant le chemin réel de vérification TLS de l'application, et non simplement la connectivité du navigateur.