Le 17 octobre 2026, un chercheur a signalé au Chrome Root Program que plusieurs autorités de certification intermédiaires gérées par eMudhra avaient généré leurs clés avec trop peu d’aléatoire. Les clés privées peuvent être retrouvées à partir des certificats publics. Quiconque y parvient peut créer un certificat pour n’importe quel domaine, y compris votre API, que les logiciels non mis à jour acceptent comme valide.
Les navigateurs ont été corrigés rapidement. Chrome a bloqué les certificats le soir même, et Android a reçu le blocage via Google Play Services deux jours plus tard. Apple les a également bloqués sur ses plateformes. Mais beaucoup de logiciels ne demandent pas au navigateur ou au système d’exploitation si un certificat est digne de confiance. Ils embarquent leur propre liste, et cette liste ne change que lorsque quelqu’un la met à jour ou la reconstruit.
Voici ce que nous avons vérifié pour les apps de nos clients et pour nos propres serveurs, pour que vous puissiez faire de même.
Ce qui peut réellement arriver
Quelqu’un qui contrôle le réseau entre votre app et votre API peut présenter un certificat falsifié pour le domaine de votre API. Une app qui fait encore confiance aux certificats compromis l’accepte sans le moindre avertissement. L’attaquant transmet le trafic au vrai serveur, si bien que l’app continue de fonctionner normalement, pendant que les identifiants, les tokens et les données clients passent entre ses mains.
Contrôler le réseau semble difficile, mais un faux point d’accès sur un salon, dans une gare ou dans un entrepôt suffit. C’est pourquoi le sujet concerne surtout les apps mobiles, et moins les serveurs dans un datacenter.
Qui est concerné
| Logiciel | Concerné ? | Que faire |
|---|---|---|
| Chrome, Firefox, Safari, Edge | Non, bloqué en quelques jours | Rien |
| Apps iOS et macOS natives | Non, bloqué par Apple | Rien |
| Apps Android natives | Non, mise à jour de Play Services le 19 octobre | Rien |
| Apps Flutter sur iOS, macOS et web | Non | Rien |
| Apps Flutter sur Android et Windows | Oui, jusqu’à un nouveau build | Reconstruire sur Flutter 3.47.8 / Dart 3.13.7 ou plus récent et publier |
| Flutter sur Linux | Dépend de la liste de certificats du système | Mettre à jour le paquet ca-certificates |
| Node.js | Anciennes versions | 22.23.4, 24.22.1, 26.12.1 ou plus récent |
Python avec certifi | Anciennes versions | certifi 2026.10.19 ou plus récent |
| Images Docker et serveurs Linux | S’ils ont été construits ou mis à jour avant le 20 octobre environ | Reconstruire avec les mises à jour de sécurité |
Pour les conteneurs, c’est la liste de certificats à l’intérieur de l’image qui compte, et elle est figée au moment où l’image a été construite. Alpine, Ubuntu et Debian 12 et 13 ont tous publié des paquets ca-certificates mis à jour entre le 20 et le 21 octobre, donc un rebuild qui installe les mises à jour de sécurité les récupère.
Un détail rend les choses plus délicates que la simple suppression d’un certificat racine. Les intermédiaires compromis étaient aussi signés de manière croisée par une ancienne racine de Sectigo, AAA Certificate Services, que de nombreux bundles de certificats contiennent encore. Supprimer uniquement la racine d’eMudhra ne suffit pas : soit cette ancienne racine disparaît aussi, comme dans la mise à jour de Debian, soit les intermédiaires sont bloqués directement, comme dans le correctif Flutter.
Comment vérifier votre app
Posez deux questions à la personne qui développe votre app :
- Sur quelle version de Flutter la dernière release Android et Windows a-t-elle été construite ?
- Si elle est antérieure à 3.47.8, quand le nouveau build sera-t-il publié ?
Si la réponse est un numéro de version et une date, vous êtes en bonne voie. Une fois le nouveau build en ligne, relever la version minimale de l’app garantit que plus personne n’utilise l’ancienne.
Il y a aussi un effet secondaire positif. Sur Android 14 et versions ultérieures, les apps construites sur la version corrigée de Flutter chargent leurs certificats racines de confiance depuis une partie d’Android que Google met à jour via les mises à jour système Play. La prochaine fois qu’un incident de ce type se produit, ces apps récupèrent les changements de certificats racines sans nouveau build.