Mise à jour Java d’octobre 2026 et CVE-2026-91403 : corriger chaque JVM

Java a connu deux versions de sécurité en deux jours. Le 20 octobre 2026, le Critical Patch Update trimestriel d’Oracle a corrigé 55 vulnérabilités dans Java SE, dont 49 exploitables à distance sans se connecter. Le 21 octobre, Oracle a publié une Security Alert hors cycle pour CVE-2026-91403, une faille dans l’implémentation TLS de Java (JSSE) avec un score CVSS de 9.1, et les versions concernées incluent celles publiées la veille. L’IPA japonaise a averti le 21 octobre qu’une exploitation peut faire planter des applications ou permettre à un attaquant de prendre le contrôle de l’ordinateur. Ce guide vous indique vers quelles versions passer, comment trouver chaque environnement Java que vous utilisez et comment vérifier que la mise à jour est réellement prise en compte.

Ce qui a été corrigé le 20 octobre

Le Critical Patch Update d’octobre concerne Oracle Java SE 27, 26.0.2, 25.0.4.1, 21.0.12.1, 17.0.20.1, 11.0.32.1 et 8u503, et donc toutes les mises à jour antérieures de ces versions. Aucun des 55 correctifs Java n’est classé critique, mais 49 failles peuvent être exploitées à distance sans authentification.

Java 26 n’a reçu aucun correctif : ses mises à jour ont pris fin en septembre 2026. Si vous utilisez encore la 26, passez à la 27 ou à la version à support long 25.

CVE-2026-91403 : les nouvelles versions sont aussi concernées

CVE-2026-91403 se trouve dans JSSE, la partie de Java qui gère les connexions TLS. Selon Oracle, elle est facile à exploiter, ne nécessite ni compte ni interaction de l’utilisateur et peut être atteinte à distance via plusieurs protocoles, par exemple par un service web qui transmet des données aux API concernées. Une attaque réussie peut lire et modifier des données critiques (CVSS 9.1, AV:N/AC:L/PR:N/UI:N, impact élevé sur la confidentialité et l’intégrité).

Les versions concernées sont exactement celles du 20 octobre : Java SE 8u511, 11.0.33, 17.0.21, 21.0.13, 25.0.5 et 27.0.1, ainsi que GraalVM for JDK 17.0.21 et 21.0.13 et GraalVM Enterprise 21.3.20. La mise à jour d’octobre seule ne vous protège donc pas contre cette faille.

Oracle fournit le correctif pour Oracle JDK via le document de correctif cité dans la Security Alert, pour les clients ayant accès à My Oracle Support. Au moment de la rédaction, les pages publiques d’Oracle n’indiquent pas encore de nouveaux numéros de version, et Oracle n’a pas précisé si la faille est déjà exploitée. Le projet OpenJDK a publié son propre avis le 21 octobre : les builds basés sur OpenJDK (Eclipse Temurin, Amazon Corretto, Azul Zulu, Red Hat et les paquets des distributions Linux) reçoivent donc leurs correctifs de ces fournisseurs. Consultez la page de sécurité de votre fournisseur et installez la première version qui mentionne CVE-2026-91403. Nous mettrons cet article à jour dès que des numéros de version publics seront disponibles.

Étape 1 : trouver chaque environnement Java

java -version n’affiche que le Java présent dans votre PATH. Les serveurs en exécutent souvent plusieurs : un fourni avec une application, un dans un conteneur, un installé il y a des années dans /opt.

Sous Linux, listez chaque binaire Java avec sa version :

sudo find / -xdev -type f -name java -perm -u+x 2>/dev/null | while read -r j; do echo "$j: $("$j" -version 2>&1 | head -n 1)"; done

Affichez le Java réellement utilisé par les processus en cours d’exécution :

for p in $(pgrep -f java); do echo "$p $(sudo readlink -f /proc/$p/exe)"; done

Sous Docker, vérifiez la version de Java de chaque conteneur en cours d’exécution :

for c in $(docker ps --format '{{.Names}}'); do echo "$c: $(docker exec "$c" java -version 2>&1 | head -n 1)"; done

Sous Windows, dans PowerShell :

Get-ChildItem 'C:\Program Files','C:\Program Files (x86)' -Recurse -Filter java.exe -ErrorAction SilentlyContinue | ForEach-Object { "$($_.FullName): $((& $_.FullName -version 2>&1 | Select-Object -First 1))" }

N’oubliez pas les logiciels qui embarquent leur propre Java, comme Jenkins, Elasticsearch, Keycloak, les produits Atlassian, les distributions groupées de Tomcat, les agents de build et les serveurs de jeux.

Étape 2 : mettre à jour

Ubuntu et Debian (paquets OpenJDK) :

sudo apt update && apt list --upgradable 2>/dev/null | grep -i jdk
sudo apt install --only-upgrade 'openjdk-*'

Red Hat, Rocky, AlmaLinux et Fedora :

sudo dnf upgrade 'java-*-openjdk*'

Oracle JDK : installez la version d’octobre correspondant à votre branche depuis la page de téléchargement d’Oracle, puis le correctif CVE-2026-91403 depuis My Oracle Support dès que possible. Vérifiez d’abord la licence : à partir de 21.0.13, les mises à jour d’Oracle JDK 21 ne sont plus couvertes par les conditions gratuites No-Fee Terms and Conditions, et un usage commercial peut nécessiter un abonnement payant. Pour les autres builds OpenJDK comme Temurin ou Corretto, installez la version la plus récente du fournisseur.

Conteneurs : une mise à jour sur l’hôte ne modifie pas un conteneur. Récupérez l’image de base mise à jour, reconstruisez vos images et redéployez-les.

Étape 3 : redémarrer et vérifier

Java charge son code au démarrage : un service en cours d’exécution conserve donc l’ancienne version jusqu’à son redémarrage. Après une mise à jour de paquet sous Linux, cette commande liste les processus Java qui utilisent encore les fichiers remplacés :

sudo ls -l /proc/*/exe 2>/dev/null | grep -i 'java.*(deleted)'

Redémarrez ces services, exécutez à nouveau les commandes de l’étape 1 et comparez les versions avec le tableau ci-dessus.

En attendant l’installation du correctif CVE-2026-91403

• Ne laissez accéder aux services Java par le réseau que les systèmes qui en ont besoin, en particulier pour les services qui acceptent des connexions TLS depuis Internet.
• Lorsque c’est possible, terminez les connexions TLS en amont du service Java, par exemple dans un reverse proxy, afin que moins de connexions TLS non fiables atteignent JSSE. Cela réduit l’exposition, mais ne remplace pas le correctif.
• Surveillez les journaux des services Java exposés à Internet pour repérer les erreurs TLS inhabituelles et les plantages, et gardez des sauvegardes prêtes.

La suite

Oracle a fait passer Java à des versions de sécurité plus fréquentes. La prochaine, un Critical Security Patch Update, est prévue le 17 novembre 2026, et le prochain Critical Patch Update trimestriel le 19 janvier 2027. Notez ces deux dates dans votre agenda et répétez à chaque fois les trois étapes ci-dessus.

Si vous ne savez pas avec certitude lesquels de vos systèmes exécutent Java, ou si un service Java a peut-être déjà été attaqué, nos équipes de sécurité managée et de réponse à incident peuvent vous aider.