La vulnérabilité ne repose pas sur une faiblesse du chiffrement HTTPS lui-même. Elle concerne plutôt la confiance accordée à certains certificats numériques lors de l’établissement d’une connexion sécurisée.
Selon Red Hat, des autorités de certification racines présentes dans les magasins de confiance d’OpenJDK et d’Oracle Java ont signé des certificats intermédiaires eMudhra associés à des clés privées faibles. Un attaquant capable d’exploiter ces clés pourrait créer des certificats pour des noms d’hôtes arbitraires, susceptibles d’être acceptés par un client Java vulnérable.
Comment une attaque pourrait-elle se dérouler ?
Le scénario envisagé est celui d’une attaque de type man-in-the-middle (homme du milieu).
- L’attaquant parvient à se placer sur le chemin réseau entre une application Java et le service distant.
- Il présente un certificat frauduleux correspondant au nom du serveur légitime.
- Si la chaîne de certificats est considérée comme fiable par le client vulnérable, celui-ci peut accepter la connexion.
- L’attaquant peut alors potentiellement intercepter ou modifier les échanges protégés par cette connexion.
Le risque dépend donc de la validation des certificats et du contexte d’utilisation. Le fait qu’un certificat soit accepté ne signifie pas automatiquement que toutes les communications d’une application sont compromises, mais il peut supprimer une garantie essentielle de l’authentification TLS.
Versions de Java et de GraalVM concernées
L’avis officiel d’Oracle répertorie les versions suivantes comme affectées :
| Produit | Versions concernées |
|---|---|
| Oracle Java SE | 8u511 et 8u511-perf |
| Oracle Java SE | 11.0.33 |
| Oracle Java SE | 17.0.21 |
| Oracle Java SE | 21.0.13 |
| Oracle Java SE | 25.0.5 |
| Oracle Java SE | 27.0.1 |
| Oracle GraalVM for JDK | 17.0.21 et 21.0.13 |
| Oracle GraalVM Enterprise Edition | 21.3.20 |
Les versions antérieures peuvent également être vulnérables. Oracle précise cependant que les versions ne bénéficiant plus d’un support actif n’ont pas été testées dans le cadre de cet avis. Il est donc recommandé de migrer vers une version prise en charge.
Les applications serveur utilisant JSSE pour traiter des données provenant de services distants doivent être examinées en priorité. L’avis concerne aussi certains environnements clients exécutant des applications Java Web Start ou des applets en bac à sable qui chargent du code non fiable.
La liste complète et les instructions d’installation figurent dans l’avis de sécurité Oracle CVE-2026-91403.
Comment corriger la vulnérabilité ?
Oracle recommande d’installer la mise à jour de sécurité appropriée pour chaque déploiement Java ou GraalVM concerné. Au 24 octobre 2026, les versions corrigées mentionnées dans l’avis sont disponibles : les administrateurs ne doivent donc pas traiter cette mesure comme un simple correctif futur.
1. Mettre à jour Java et GraalVM
Identifiez les environnements Java installés sur les serveurs, postes de travail, conteneurs et systèmes d’intégration continue. Vérifiez leur version réelle, puis appliquez le correctif correspondant au produit et à la branche utilisés.
Les installations intégrées à une application ou distribuées par un fournisseur tiers peuvent nécessiter une procédure de mise à jour distincte.
2. Appliquer la mesure d’atténuation sur les certificats si nécessaire
Pour les systèmes qui ne peuvent pas être mis à jour immédiatement, Oracle fournit des instructions spécifiques visant à bloquer les certificats concernés.
La procédure consiste à remplacer le fichier de certificats bloqués par la version fournie par Oracle, tout en préservant les entrées personnalisées déjà présentes. Pour Java 8, le fichier utilisé porte le nom blacklisted.certs, alors que d’autres versions utilisent blocked.certs.
Cette opération doit être effectuée en suivant les instructions exactes du fournisseur. Une modification incorrecte peut perturber des connexions légitimes ou supprimer des paramètres propres à l’environnement.
Les étapes détaillées sont disponibles dans les instructions Oracle consacrées à eMudhra.
3. Vérifier la révocation des certificats TLS
Oracle recommande également d’examiner les contrôles de révocation TLS. Les propriétés Java suivantes peuvent être pertinentes selon l’application et son environnement :
-Dcom.sun.net.ssl.checkRevocation=true
-Dcom.sun.security.enableCRLDP=trueCes paramètres ne doivent pas être considérés comme un remplacement du correctif. Leur efficacité dépend notamment de la disponibilité des informations de révocation, de la configuration TLS et du comportement de l’application.
Pour les fichiers JAR signés, la vérification peut également inclure l’option de contrôle de révocation de jarsigner, conformément à la documentation applicable. Les équipes doivent tester ces réglages avant de les déployer à grande échelle.
Pourquoi cette mise à jour est-elle urgente ?
La note CVSS 3.1 de 9,1 sur 10 reflète un scénario d’attaque distant, de faible complexité, ne nécessitant ni authentification ni interaction de l’utilisateur selon la matrice Oracle. Les impacts portent principalement sur la confidentialité et l’intégrité des données, tandis qu’aucun impact sur la disponibilité n’est indiqué dans cette évaluation.
La vulnérabilité rappelle que la sécurité HTTPS dépend autant de la qualité du chiffrement que de la fiabilité des certificats utilisés pour authentifier les serveurs.
Les entreprises devraient donc inventorier leurs installations Java, vérifier les chaînes de confiance utilisées par leurs applications et appliquer les correctifs sans attendre le prochain cycle régulier de maintenance. Les équipes exploitant des versions hors support devraient planifier une migration vers des versions maintenues.
Pour compléter cette démarche, consultez les informations officielles sur les mises à jour de sécurité Oracle et les recommandations de Red Hat concernant CVE-2026-91403.
Conclusion
La faille CVE-2026-91403 met en évidence un risque majeur lié à la confiance accordée aux certificats numériques dans Oracle Java SE et GraalVM. En raison de clés privées faibles associées à certains certificats intermédiaires eMudhra, un attaquant pourrait, dans certaines conditions, usurper l’identité d’un serveur et compromettre la confidentialité ou l’intégrité des échanges TLS.
Oracle a publié une mise à jour d’urgence le 21 octobre 2026 et fournit des mesures d’atténuation pour les environnements qui ne peuvent pas être corrigés immédiatement. Les administrateurs doivent vérifier toutes les versions concernées, appliquer les correctifs officiels et contrôler la configuration de validation des certificats.
La priorité est de corriger les installations vulnérables et de ne pas confondre une connexion chiffrée avec une connexion dont l’identité du serveur est nécessairement fiable.
SOURCE : Cyber Security News
