Retour

2026/10/30

Les navigateurs protégés en quelques heures. Et Java en entreprise ? Comment LOGIQ a réagi à l’incident des certificats eMudhra

Intermédiaires eMudhra compromis : bloqués en quelques heures par les navigateurs, mais chaque JDK a son trust store. Correctifs Azul, BellSoft et actions LOGIQ.

Points clés

  • Le 17 octobre 2026, Mozilla a reçu un signalement indiquant que les clés privées de huit certificats d’AC intermédiaires eMudhra avaient été compromises. Les navigateurs les ont bloqués en quelques heures à quelques jours. eMudhra déclare n’avoir connaissance d’aucun élément indiquant que les clés aient été exploitées.
  • Java ne s’appuie pas sur les décisions de confiance du navigateur ni du système d’exploitation. Chaque JDK, ainsi que chaque image de conteneur ou application qui en embarque un, possède son propre trust store. Chacun d’eux doit être mis à jour séparément.
  • Azul a publié deux mises à jour hors cycle de Zulu, le 21 et le 24 octobre. La seconde existe parce que le premier correctif ne suffisait pas : le contournement du 21 octobre n’est donc plus suffisant à lui seul.
  • BellSoft indique des builds Liberica corrigés pour Java 8, 11, 17, 21, 25 et 27. LOGIQ a obtenu ces builds via son canal de support BellSoft et les a mis à la disposition de ses clients.
  • Que faire : recenser tous les runtimes Java que vous exploitez, vérifier l’éditeur et le build exacts, passer au build corrigé de cet éditeur, tester vos connexions TLS et rester attentif aux publications hors cycle.

Ce qui s’est passé

Le samedi 17 octobre 2026 à 20 h 06 UTC, Mozilla a reçu un signalement indiquant que les clés privées de huit certificats intermédiaires eMudhra avaient été compromises. Mozilla a bloqué ces huit certificats dans Firefox via OneCRL, sa liste de révocation centralisée, et la mise à jour avait atteint les utilisateurs aux paramètres standard à 22 h 59 UTC, moins de trois heures plus tard. Mozilla a rendu l’incident public le 20 octobre. Elle a également publié des versions correctives de Firefox pour les utilisateurs dont les paramètres bloquaient la mise à jour OneCRL, et a retiré du trust store NSS le certificat racine qui avait signé ces intermédiaires.

Le risque est la falsification de certificats. Quiconque détient l’une de ces clés pourrait émettre un certificat HTTPS pour un site qu’il ne contrôle pas. S’il parvenait en outre à s’interposer entre un client et ce site, il pourrait usurper son identité et lire ou modifier le trafic.

Rien n’indique à ce jour que cela se soit produit. Dans sa déclaration sur l’incident, eMudhra indique que les huit intermédiaires ont été révoqués le 18 octobre, qu’aucun d’eux n’avait émis de certificat d’entité finale, et qu’elle n’a « connaissance d’aucun élément indiquant que les clés faibles aient été récupérées ou exploitées par quiconque avant la divulgation du problème ». eMudhra attribue la cause à des clés faibles générées lors d’une cérémonie de clés en 2025. Elle précise ne pas avoir encore confirmé la cause racine exacte et que son enquête se poursuit. Les programmes de certificats racines des navigateurs ont retiré leur confiance à la racine eMudhra située au-dessus de ces intermédiaires, par précaution.

Cet article porte donc sur la fermeture d’une fenêtre d’exposition, et non sur une attaque avérée.

Pourquoi Java a besoin de son propre correctif

Les navigateurs et les systèmes d’exploitation disposent de mécanismes automatiques pour cesser de faire confiance à une autorité de certification, et ils les ont utilisés rapidement. Selon le compte rendu de l’incident publié par Azul, Chrome a bloqué les certificats le jour même, Apple le 19 octobre et Microsoft le 20 octobre.

Java n’hérite de rien de tout cela. Un JDK décide des certificats auxquels il fait confiance à partir de ses propres fichiers :

  • Son propre trust store. Chaque JDK est livré avec son propre fichier cacerts. Mettre à jour le bundle de certificats du système d’exploitation ou redémarrer un navigateur ne le modifie pas.
  • Pas de vérification de révocation par défaut. Comme l’indique la documentation d’Azul, Java fait confiance aux certificats racines dont dépendent ces intermédiaires et « ne vérifie pas la révocation par défaut ». La révocation des intermédiaires par eMudhra ne protège donc pas, à elle seule, un client Java.
  • De nombreuses copies. Un serveur peut exécuter le JDK du système, un JDK embarqué dans une application, un runtime jlink et plusieurs images de conteneur, chacun avec sa propre copie du trust store. Chaque copie reste exposée tant qu’elle n’a pas été mise à jour ou reconstruite.

Un service Java qui établit des connexions TLS sortantes peut donc encore accepter un certificat falsifié alors que tous les navigateurs de l’entreprise sont déjà protégés. C’est cette faille qui fait l’objet de cet article.

Deux mises à jour d’urgence chez Azul

Azul a publié deux mises à jour hors cycle d’Azul Zulu après sa version trimestrielle d’octobre :

  • 21 octobre : la première mise à jour hors cycle ajoute les huit intermédiaires compromis à la liste de blocage du JDK (blocked.certs à partir du JDK 11, blacklisted.certs dans les versions plus anciennes). Elle couvre Zulu 27, 25, 21, 17, 11, 8, 7 et 6. La liste des CVE d’Azul la référence sous CVE-2026-91403. Pour les runtimes qui ne pouvaient pas être mis à jour immédiatement, Azul a aussi publié un contournement manuel qui remplace le fichier de liste de blocage.
  • 24 octobre : Azul a constaté que la liste de blocage ne réglait pas entièrement le problème. La seconde mise à jour hors cycle corrige CVE-2026-114820 (JSSE, score de base 9.1) en retirant purement et simplement certains certificats d’AC de cacerts. À l’heure où nous écrivons, ces builds sont disponibles pour la ligne CPU d’Azul (correctifs de sécurité uniquement), à la fois sur la base CPU d’octobre 2026 (par exemple Zulu 21.53.114, 17.69.114, 11.91.114 et 8.97.0.112) et sur la base CPU de juillet 2026. Azul indique que des builds PSU suivront « probablement » dans une mise à jour distincte.

La mise à jour du 24 octobre change les recommandations. La page de contournement d’Azul avertit désormais que celui-ci « ne règle plus entièrement le problème », et Azul demande à tous ses clients de passer à la dernière version. Si vous avez appliqué la mise à jour du 21 octobre ou le contournement, il vous faut quand même le build du 24 octobre. Dans son propre compte rendu, Azul indique qu’il a fallu environ 12 heures entre la décision de régénérer les builds et la mise à disposition des builds de sécurité uniquement entre les mains des clients.

Ce que BellSoft a publié pour Liberica JDK

BellSoft a publié sa version régulière d’octobre 2026 de Liberica JDK le 21 octobre. Cette version trimestrielle recense 52 CVE corrigées et comprend des builds CPU pour Java 6 et 7 (6u521 et 7u521). Ses notes de version ne traitent pas du problème eMudhra.

BellSoft traite eMudhra dans un guide distinct, « Distrusting compromised eMudhra intermediates in Java » (dernière mise à jour le 27 octobre). Il indique comme builds corrigés Liberica JDK 8u513+9, 11.0.33.0.3+7, 17.0.21.0.3+5, 21.0.13.0.3+5, 25.0.5.0.3+5 et 27.0.1.0.3+5. Pour les systèmes qui ne peuvent pas encore être mis à jour, le guide propose une mesure d’atténuation temporaire : retirer les racines concernées du trust store. Il avertit que cela peut casser des chaînes de certificats légitimes et qu’il faut d’abord le tester.

Deux points sont importants lorsque vous comparez les éditeurs :

  • Les listes de CVE ne sont pas identiques. Azul et BellSoft publient chacun leur propre liste de CVE pour le cycle d’octobre, et les décomptes comme les notes diffèrent. Les deux identifiants CVE d’Azul cités plus haut proviennent des registres d’Azul. Le guide de BellSoft ne les mentionne pas. Consultez les notes de version de votre propre éditeur pour connaître les correctifs exacts de votre build, et ne supposez pas que la liste d’un éditeur s’applique au JDK d’un autre.
  • Java 6 et 7 ne figurent pas dans la liste eMudhra de BellSoft. Les derniers builds Java 6 et 7 de BellSoft sont disponibles, mais la liste des builds corrigés de son guide eMudhra commence à Java 8. Si vous utilisez Liberica 6 ou 7, demandez si votre build inclut la modification du trust store avant de vous y fier, ou appliquez la mesure d’atténuation de l’éditeur. Azul indique des builds du 24 octobre pour Zulu 6 et 7.

La réponse de LOGIQ

Nous distribuons à nos clients des builds Java de BellSoft et d’Azul et les aidons à migrer depuis d’anciennes versions d’Oracle JDK. Voici ce que nous avons fait, avec l’état de chaque action à l’heure où nous écrivons (29 octobre).

Réalisé

  • 21–22 octobre : analyse des avis des éditeurs. Nous avons reçu et analysé l’avis hors cycle d’Azul du 21 octobre ainsi que l’annonce de la version d’octobre 2026 de BellSoft. Nous avons ouvert le jour même des tâches de téléchargement et de dépôt pour les deux éditeurs. Nous avons traité les deux publications séparément, sans supposer que la version trimestrielle de BellSoft contenait le même correctif eMudhra que celle d’Azul.
  • 23 octobre : préparation des builds trimestriels Liberica. Nous avons téléchargé les builds Liberica JDK d’octobre 2026 depuis le portail de support de BellSoft et les avons ajoutés au dépôt à partir duquel nos clients effectuent leurs téléchargements.
  • 24–25 octobre : suivi de la seconde mise à jour Azul. Nous avons pris en compte l’avis d’Azul du 24 octobre, y compris sa recommandation de mettre à jour même si le build du 21 octobre était déjà installé.
  • 27–28 octobre : obtention des builds Liberica corrigés via BellSoft. Dans le cadre de notre relation de support commercial, nous avons demandé à BellSoft de mettre les builds les plus récents à disposition sur notre portail de support. BellSoft les a mis en ligne le 28 octobre, y compris les builds corrigés pour Java 8, 11, 17, 21, 25 et 27 ainsi que les derniers builds Java 6 et 7. Certains clients ont encore besoin de Java 8 en 32 bits : nous avons donc aussi demandé à BellSoft d’ajouter à notre portail les installeurs 32 bits 8u513+9 pour Windows et Linux. BellSoft les a ajoutés le jour même.
  • 28–29 octobre : mise à jour du dépôt et des correspondances de migration. Nous avons ajouté ces builds à notre dépôt de téléchargement clients et mis à jour nos recommandations de migration d’Oracle JDK vers Liberica pour qu’elles pointent vers eux, la mise à jour étant relue par un second ingénieur.

Clients Azul Zulu

Les builds Azul des 21 et 24 octobre sont disponibles pour les abonnés Azul auprès d’Azul. Le bon build dépend de votre version de Java, de la ligne utilisée (CPU ou PSU) et de la base sur laquelle vous êtes (octobre ou juillet). Consultez les notes de version d’Azul pour votre build exact, ou contactez-nous et nous vous aiderons à l’identifier.

Anciennes versions Java 6 et 7

Certains clients exploitent encore Java 6 ou 7, souvent dans des applications qui ne peuvent pas évoluer rapidement. Oracle ne fournit plus de mises à jour publiques pour ces versions, mais des solutions existent. Nous aidons nos clients à migrer d’anciens builds Oracle JDK 6 et 7 vers les derniers builds Liberica JDK 6 et 7, et les builds d’octobre 2026 de BellSoft pour ces deux versions nous sont accessibles via le portail de support de BellSoft. Lorsqu’un correctif ou un paquet dont nous avons besoin pour ces versions manque, nous le remontons à BellSoft via notre canal de support commercial. Pour cet incident, reportez-vous à la remarque ci-dessus : vérifiez que votre build Java 6 ou 7 inclut la modification du trust store liée à eMudhra avant de vous y fier.

Ce que vous devez faire maintenant

1. Recenser tous les runtimes Java

Répertoriez tous les endroits où Java s’exécute, pas seulement le JDK du système. Cela inclut les serveurs d’applications, les runtimes embarqués dans les produits d’éditeurs, les images jlink, les agents de build CI et chaque image de conteneur. Sous Linux, cette commande trouve les binaires Java d’un hôte :

find / -xdev -type f -path "*/bin/java" 2>/dev/null

Pour les images de conteneur, lancez la vérification à l’intérieur de l’image, par exemple docker run --rm --entrypoint java <image> -version.

2. Vérifier l’éditeur et le build exacts

La version majeure ne suffit pas. Il vous faut l’éditeur et le numéro de build complet pour les comparer à la liste des builds corrigés de l’éditeur :

java -XshowSettings:properties -version 2>&1 | grep -E "java.vendor =|java.runtime.version|java.home"

Comme indicateur rapide, vous pouvez aussi lister les racines eMudhra (emSign) présentes dans le trust store d’un runtime :

keytool -list -keystore "<java.home>/lib/security/cacerts" -storepass changeit | grep -i emsign

Lors de nos tests avec les images de conteneur publiques de BellSoft, un ancien build Liberica 21.0.10 listait cinq racines emSign, tandis que les builds corrigés 21.0.13.0.3+5 et 8u513 n’en listaient aucune. Un résultat vide est bon signe, mais ce n’est pas une preuve. Le correctif Azul du 21 octobre, par exemple, bloquait les intermédiaires sans retirer de racines. Le numéro de build est la vérification fiable. Notre article précédent sur la vérification des trust stores Java présente des contrôles plus détaillés.

3. Appliquer le dernier correctif applicable

  • Azul Zulu : passez au build hors cycle du 24 octobre correspondant à votre ligne (CPU ou PSU, base d’octobre ou de juillet), même si vous avez installé le build du 21 octobre ou appliqué le contournement. Si vous utilisez des builds PSU, surveillez la version PSU complémentaire d’Azul.
  • Liberica JDK : passez aux builds corrigés indiqués par BellSoft (8u513+9, 11.0.33.0.3+7, 17.0.21.0.3+5, 21.0.13.0.3+5, 25.0.5.0.3+5, 27.0.1.0.3+5).
  • Autres éditeurs et runtimes embarqués : consultez le bulletin de l’éditeur concerné. Un JDK intégré à un produit tiers est mis à jour par l’éditeur de ce produit, et non par les mises à jour de votre système d’exploitation.
  • Conteneurs : reconstruisez les images sur une image de base corrigée et redéployez-les. Corriger un conteneur en cours d’exécution ne modifie pas l’image.

4. Valider le TLS avant et pendant le déploiement

Retirer des racines d’un trust store peut casser des connexions légitimes, par exemple vers des sites qui utilisent encore des certificats chaînés aux racines eMudhra retirées. eMudhra indique qu’elle réémet les certificats clients concernés à partir d’une autre hiérarchie d’AC. Avant un déploiement à grande échelle, testez les connexions TLS sortantes dont dépendent vos applications, en particulier vers des partenaires ou des services susceptibles d’utiliser des certificats eMudhra. Déployez par étapes, redémarrez les processus Java pour qu’ils chargent le nouveau trust store, puis vérifiez la version en cours d’exécution.

5. Surveiller les publications hors cycle

Cet incident a donné lieu à deux publications Java d’urgence en quatre jours, et d’autres pourraient suivre, comme les builds PSU d’Azul. Abonnez-vous aux avis de sécurité de vos éditeurs, consultez directement leurs pages de publication au lieu de vous fier uniquement aux e-mails, et prévoyez des mises à jour Java en dehors du calendrier trimestriel.

La leçon à retenir

Les utilisateurs de Firefox ont été protégés en quelques heures, car les navigateurs disposent de leurs propres trust stores et d’un moyen automatique de les mettre à jour. Java en entreprise compte de nombreux trust stores, aucune vérification de révocation par défaut, et des mises à jour qui attendent que quelqu’un les installe. Combler cet écart exige un inventaire précis, des numéros de build exacts, un accès rapide aux builds des éditeurs et un processus qui n’attend pas le prochain correctif trimestriel. Si vous avez besoin d’aide pour identifier ou mettre à jour les runtimes Java de votre environnement, contactez LOGIQ.

Références