Faille Java CVE-2026-91403 : 8 certificats eMudhra compromis, le guide essentiel

Cette faille Java ne ressemble pas aux autres : il n’y a pas de bug de mémoire à corriger dans le code de la JVM. Le problème vient de la chaîne de confiance TLS. Java est livré avec une liste de certificats racines auxquels il fait confiance (le fichier cacerts). Si une autorité de certification se fait voler ses clés, un attaquant peut fabriquer des certificats que Java acceptera comme valides, et intercepter des connexions HTTPS que ton application croit sécurisées.

Dans cet article de veille, on reprend l’histoire dans l’ordre : la compromission chez eMudhra, ce qu’elle change pour Java (sans entrer dans l’exploitation), puis la correction et les commandes précises à lancer selon ta façon d’installer Java.

Chronologie de la faille Java

Les navigateurs ont réagi vite, et Google indique n’avoir trouvé aucun certificat émis par les intermédiaires compromis dans les journaux Certificate Transparency avant leur blocage. Mais Java ne se met pas à jour comme un navigateur : chaque JDK, chaque JRE et chaque application qui embarque son propre Java garde son propre magasin de certificats. C’est ce qui rend cette faille Java longue à corriger partout.

En bref : la faille Java en chiffres

	CVE-2026-91403
Composant	JSSE (Java Secure Socket Extension, TLS)
Cause	Huit autorités intermédiaires eMudhra aux clés compromises
Gravité	Critique · CVSS 3.1 9.1
Vecteur	AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Authentification requise	Non
Oracle Java SE touché	8u511, 8u511-perf, 11.0.33, 17.0.21, 21.0.13, 25.0.5, 27.0.1
GraalVM touché	GraalVM for JDK 17.0.21 et 21.0.13 · Enterprise Edition 21.3.20
Date de publication	21 octobre 2026

Le vecteur CVSS se lit simplement : attaque à distance, faible complexité, aucun privilège ni interaction, avec un impact élevé sur la confidentialité et l’intégrité, mais pas sur la disponibilité. Logique : un faux certificat permet de lire et de modifier un trafic chiffré, pas de faire planter la JVM. Oracle précise que les versions hors support Premier ou Extended n’ont pas été testées, mais qu’elles sont probablement concernées elles aussi.

Ce que change la faille Java : la chaîne de confiance TLS

Quand ton application Java se connecte en HTTPS à une API, JSSE vérifie que le certificat du serveur a été signé par une autorité de confiance. Cette vérification remonte une chaîne : certificat du serveur, puis autorité intermédiaire, puis racine présente dans cacerts. Si la chaîne aboutit à une racine de confiance, la connexion est acceptée.

Les huit autorités intermédiaires d’eMudhra étaient signées par la racine emSign ECC Root CA – G3. Leurs clés privées étant compromises, quelqu’un qui les détient peut signer un certificat pour n’importe quel domaine, et ce certificat remonterait jusqu’à une racine que Java considère comme fiable. L’alerte Oracle corrige le problème en faisant en sorte que Java ne fasse plus confiance à ces intermédiaires. Oracle n’a pas publié son analyse technique détaillée, et les sources consultées n’expliquent pas comment les clés ont été compromises.

Oracle cite deux situations exposées : les API JSSE utilisées par un service web, et les déploiements qui exécutent du code non fiable venu d’Internet (applications Java Web Start ou applets en bac à sable).

Suis-je concerné par cette faille Java ?

Commence par lister tous les Java installés. Sur un même poste, on en trouve souvent plusieurs : celui de ton IDE, celui de Maven ou Gradle, celui d’une application de bureau, celui du système.

# Version du Java par défaut
java -version

# Linux : lister les JDK installés
update-alternatives --list java

# macOS
/usr/libexec/java_home -V

# Windows (PowerShell)
Get-Command java -All | Select-Object Source

Ensuite, vérifie si la racine eMudhra est présente dans le magasin de certificats de chaque JDK :

# JDK 11 et plus
keytool -list -cacerts -storepass changeit | grep -i emsign

# JDK 8
keytool -list -keystore "$JAVA_HOME/jre/lib/security/cacerts" -storepass changeit | grep -i emsign

• Applications Spring Boot, clients d’API, microservices : concernés, car ils établissent des connexions TLS sortantes avec JSSE.
• Applications de bureau JavaFX ou Swing : concernées si elles se connectent à Internet en HTTPS. C’est le cas de nombreux projets comme notre gestionnaire de scripts ScriptPro en JavaFX s’il appelle des services en ligne.
• Applications qui utilisent leur propre truststore : concernées seulement si ce magasin contient les certificats eMudhra visés.

Comment corriger la faille Java

Oracle Java SE et GraalVM

Installe la mise à jour indiquée dans le document CPU426 lié depuis l’alerte Oracle CVE-2026-91403. Oracle ne fournit des correctifs que pour les versions sous support Premier ou Extended : si ta version n’en fait plus partie, migre vers une version supportée. Java Management Service peut t’aider à repérer les installations vulnérables dans un parc.

OpenJDK autonome (Temurin, Zulu, Corretto…)

Commence par vérifier si ton fournisseur a publié une build corrigée (Azul a par exemple publié des builds Zulu qui bloquent les huit certificats). Sinon, la page de consignes OpenJDK propose deux options. La première : sauvegarder cacerts et retirer les racines listées dans ces consignes. L’exemple ci-dessous montre la racine emSign ; reporte-toi à la page OpenJDK pour la liste complète des alias à retirer.

# 1. Sauvegarde du magasin de certificats
cp "$JAVA_HOME/lib/security/cacerts" "$JAVA_HOME/lib/security/cacerts.bak"

# 2. Retrait de la racine emSign ECC Root CA – G3
keytool -delete -cacerts -storepass changeit -alias "emsigneccrootcag3 [jdk]"

# 3. Redémarre les applications Java, puis recommence pour chaque JDK

La seconde option consiste à activer le contrôle de révocation, pour que Java refuse les certificats révoqués :

java -Dcom.sun.net.ssl.checkRevocation=true \
     -Dcom.sun.security.enableCRLDP=true \
     -jar mon-application.jar

# Pour vérifier un JAR signé (JDK 17 et plus)
jarsigner -verify -revcheck -strict mon-application.jar

Java installé par ta distribution Linux

Sur RHEL, AlmaLinux, Rocky, Fedora, Arch ou Gentoo, mettre à jour les certificats du système suffit probablement. Sur Debian, Ubuntu et Devuan, mettre à jour les paquets ne suffit pas : il faut régénérer le magasin Java.

# Debian / Ubuntu / Devuan
sudo apt update
sudo apt install --only-upgrade ca-certificates ca-certificates-java
sudo rm /etc/ssl/certs/java/cacerts
sudo update-ca-certificates --fresh

Effets de bord : ce qui peut casser après la correction

Retirer une racine, c’est volontairement refuser certaines connexions. Après la correction de la faille Java, toute connexion vers un serveur dont le certificat remonte à emSign ECC Root CA – G3 échouera avec une erreur du type PKIX path building failed. C’est le comportement attendu.

• Si c’est ton propre serveur qui utilise un certificat eMudhra, remplace-le : eMudhra propose des certificats de remplacement gratuits via ses partenaires, émis par Sectigo.
• Si c’est un service tiers, contacte son éditeur : Chrome et Firefox refusent déjà ces certificats, il devra en changer.
• Le contrôle de révocation a besoin d’accéder aux serveurs de révocation : sur un réseau très fermé, prévois l’ouverture des flux correspondants.

Comprendre la chaîne de certificats en 2 minutes

Imagine une carte d’identité. Tu fais confiance à la carte parce qu’elle a été délivrée par une mairie, elle-même habilitée par l’État. Si quelqu’un vole le tampon officiel d’une mairie, il peut fabriquer de « vraies » fausses cartes que tout contrôleur acceptera. La seule parade : déclarer ce tampon invalide partout.

En TLS, l’État, c’est la racine, la mairie, c’est l’autorité intermédiaire, et la carte, c’est le certificat du site. Les clés d’eMudhra sont le tampon volé. Retirer leur confiance dans Java, c’est prévenir tous les contrôleurs de ne plus accepter ce tampon.

Ce que cette faille Java nous apprend

Cette faille Java est un bon rappel de la façon dont fonctionne vraiment la confiance sur Internet, et des angles morts qu’elle laisse dans nos applications.

1. Ton application fait confiance à des dizaines d’organisations. Chaque racine présente dans cacerts peut, directement ou via ses intermédiaires, garantir l’identité de n’importe quel site. Il suffit qu’une seule d’entre elles soit compromise pour que la sécurité de toutes tes connexions HTTPS soit en jeu. C’est pour ça que les navigateurs et les éditeurs de langages surveillent de près les autorités de certification et n’hésitent pas à retirer leur confiance.

2. Les magasins de certificats se multiplient sans qu’on les voie. Navigateurs, système d’exploitation, Java, Python, Node.js, conteneurs, appliances réseau : chacun a souvent sa propre liste. Lors d’un incident comme celui d’eMudhra, les navigateurs sont corrigés en quelques heures, mais un JRE embarqué dans un vieux logiciel métier peut rester vulnérable pendant des mois. Tenir un inventaire de tes runtimes est la seule façon de ne pas en oublier.

3. Pour les applications sensibles, un truststore dédié reste une option. Une application qui ne parle qu’à quelques API bien connues peut utiliser un magasin limité aux seules autorités nécessaires. Elle n’est alors plus exposée aux incidents qui touchent les autres autorités. En contrepartie, il faut maintenir ce magasin à chaque renouvellement de certificat côté serveur : c’est un choix à réserver aux cas où le gain de sécurité justifie l’effort.

Enfin, cet incident montre l’importance du contrôle de révocation, souvent désactivé par défaut pour des raisons de performance ou de connectivité. L’activer dans tes applications critiques permet de réagir plus vite au prochain certificat compromis, sans attendre une mise à jour de Java.

Checklist complète après la faille Java

• Inventorie chaque runtime : JDK de développement, JRE de production, Java embarqué dans tes IDE et tes applications.
• Corrige chaque magasin cacerts, un par un, selon la méthode adaptée à son installation.
• Reconstruis tes images Docker basées sur Java pour embarquer le magasin corrigé.
• Contrôle tes truststores personnalisés (fichiers .jks ou .p12 de tes applications).
• Vérifie les produits qui embarquent Java (serveurs d’applications, outils de CI, logiciels métier) et suis les consignes de leurs éditeurs.
• Note le prochain rendez-vous : Oracle prévoit sa prochaine mise à jour le 17 novembre 2026.

# Trouver tous les magasins cacerts d’une machine Linux
sudo find / -name cacerts -path "*security*" 2>/dev/null

# Vérifier chacun d’eux
for f in $(sudo find / -name cacerts -path "*security*" 2>/dev/null); do
  echo "== $f"; keytool -list -keystore "$f" -storepass changeit | grep -ci emsign
done

Faille Java : les erreurs à éviter

• Mettre à jour un seul JDK : la faille Java se corrige magasin par magasin, et la plupart des machines en ont plusieurs.
• Croire que mettre à jour ca-certificates suffit sur Ubuntu : il faut aussi régénérer /etc/ssl/certs/java/cacerts.
• Oublier de redémarrer : une JVM déjà lancée garde l’ancien magasin en mémoire.
• Supprimer des racines au hasard : retire uniquement celle indiquée dans les consignes officielles, après sauvegarde.

FAQ

Est-ce une faille dans le code de Java ?

Non. La JVM n’a pas de bug : le problème vient de certificats en qui Java avait confiance et dont les clés ont été compromises chez eMudhra. La correction consiste à retirer cette confiance.

OpenJDK est-il concerné ou seulement Oracle Java ?

Les deux. L’alerte Oracle vise Oracle Java SE et GraalVM, et les consignes OpenJDK couvrent les distributions OpenJDK autonomes, avec des commandes spécifiques.

La faille Java est-elle exploitée activement ?

Les sources consultées ne confirment aucune exploitation. Google indique n’avoir trouvé aucun certificat émis par les intermédiaires compromis dans les journaux Certificate Transparency avant leur blocage.

Mon application affiche « PKIX path building failed » après la correction : que faire ?

Le serveur contacté utilise probablement un certificat lié à la racine retirée. Il doit changer de certificat. Ne désactive surtout pas la vérification TLS pour contourner l’erreur.

Et les autres langages ? Cette faille Java concerne le magasin de certificats de Java, mais l’incident eMudhra touche tous les logiciels qui faisaient confiance à la même racine. Python, Node.js ou les outils en ligne de commande s’appuient souvent sur le magasin du système ou sur leur propre liste. Une faille Java comme celle-ci est donc l’occasion de vérifier l’ensemble de tes environnements, pas seulement tes JDK.

Retiens enfin que la faille Java CVE-2026-91403 ne se voit pas : aucune erreur, aucun plantage, aucun message dans les journaux tant qu’un attaquant n’en profite pas. C’est ce qui la rend facile à oublier. Note dans ton suivi la date de correction de chaque machine : face à la prochaine faille Java de ce type, tu sauras immédiatement où tu en es.

Pour une équipe, la meilleure protection face à une faille Java liée aux certificats reste l’automatisation : des images Docker reconstruites chaque semaine, un JDK à jour dans la CI et un contrôle de version au démarrage de chaque service.

Faille Java : le résumé à retenir

• La faille Java CVE-2026-91403 vient de la compromission des clés de huit autorités intermédiaires eMudhra.
• Elle touche JSSE, la brique TLS de Java, avec un score CVSS 9.1 : risque d’interception de connexions HTTPS.
• Oracle Java SE 8, 11, 17, 21, 25 et 27 ainsi que GraalVM sont concernés, et OpenJDK doit être corrigé lui aussi.
• La correction passe par le correctif Oracle, le retrait de la racine eMudhra du cacerts ou le contrôle de révocation, selon l’installation.
• Chaque JDK et JRE doit être traité, puis chaque application redémarrée.

Si tu ne retiens qu’une chose de cette faille Java : la sécurité TLS repose sur une liste de confiance, et cette liste doit être entretenue comme ton code. Traite la faille Java aujourd’hui sur chacune de tes installations.

Conclusion

Cette faille Java rappelle qu’une application peut être vulnérable sans une seule ligne de code fautive : il suffit qu’un maillon de la chaîne de confiance cède. Prends le temps d’inventorier tes JDK, de corriger leurs magasins de certificats et de redémarrer tes services. La même semaine, la faille critique PHP, la faille Node.js Node2Shell et la faille GitLab CVSS 10 ont elles aussi été corrigées.

Sources

• Oracle Security Alert Advisory : CVE-2026-91403
• NVD : CVE-2026-91403
• CSO Online : eMudhra quits global TLS certificate market
• Braindetox : Java CVE-2026-91403 Alert, eMudhra Intermediate CA Distrust
• CyberPress : Oracle patches critical Java security flaw