Java: alerta CVE-2026-91403 (JSSE, 9.1) y el parche crítico de Oracle de octubre de 2026

Un día después del parche trimestral de octubre, Oracle y OpenJDK publicaron CVE-2026-91403: Java confía en los intermediarios comprometidos de eMudhra. Qué versiones están afectadas, qué almacén de certificados usa cada JDK y cómo corregirlo.

Por Equipo Xterra Engine 22 de octubre de 2026 4 min de lectura

Java SE, alerta CVE-2026-91403 en JSSE del 21-10-2026, CVSS 9.1

El 20 de octubre de 2026 Oracle publicó su parche crítico trimestral (Critical Patch Update, CPU), con 55 correcciones para Java SE. Al día siguiente, Oracle y el grupo de vulnerabilidades de OpenJDK publicaron una alerta fuera de calendario, CVE-2026-91403, con 9.1 en CVSS 3.1: las versiones recién publicadas siguen confiando en los ocho certificados intermedios comprometidos de la autoridad eMudhra. Este artículo explica qué implica, cómo saber qué almacén de certificados usa cada instalación de Java y qué opciones de corrección documenta OpenJDK.

Explicación para quien no administra servidores

Java está detrás de gran parte del software empresarial: sistemas bancarios, ERP, servidores de aplicaciones, integraciones y aplicaciones Android en su construcción. Cuando un programa Java se conecta a otro sistema por HTTPS, decide si confía en él consultando una lista de autoridades certificadoras incluida en la propia instalación de Java.

Esa lista todavía incluye a unas autoridades intermedias cuyas claves se filtraron. Mientras no se corrija, alguien con acceso a la red intermedia podría presentar un certificado falso y hacerse pasar por un banco, un proveedor o una API, y el programa Java lo aceptaría. Por eso la alerta tiene severidad crítica aunque no se trate de un error de programación en Java.

Qué es CVE-2026-91403

La alerta de Oracle sitúa la vulnerabilidad en JSSE (Java Secure Socket Extension), el componente que implementa TLS, y la califica con 9.1: explotable por red, sin autenticación ni interacción del usuario, con impacto alto en confidencialidad e integridad. El aviso de OpenJDK precisa la causa: ocho certificados de CA intermedia comprometidos.

Las versiones afectadas son las más recientes de cada rama: Java SE 8u511, 11.0.33, 17.0.21, 21.0.13, 25.0.5 y 27.0.1, además de GraalVM for JDK 17.0.21 y 21.0.13 y GraalVM Enterprise 21.3.20. OpenJDK incluye 8u512 y todas las versiones anteriores. Oracle advierte que las versiones sin soporte no fueron probadas, pero probablemente también están afectadas.

Qué almacén de certificados usa cada Java

La corrección depende de dónde toma cada instalación su lista de autoridades. OpenJDK distingue dos casos y una prueba independiente publicada en lilting.ch lo confirma:

JDK independiente (Oracle, Temurin, Corretto, Zulu, archivos .tar o .zip): usa su propio archivo cacerts dentro de la instalación. Requiere la versión corregida del proveedor o el bloqueo manual.
OpenJDK empaquetado por la distribución (Debian, Ubuntu, Fedora, RHEL, Oracle Linux, Arch, Gentoo): suele usar el almacén del sistema operativo. Actualizar ca-certificates suele bastar.
Homebrew y FreeBSD: empaquetan los certificados junto a Java; hay que actualizar el paquete de Java.

Árbol de decisión para corregir CVE-2026-91403 según el origen del JDK: independiente con cacerts propio, paquete de distribución con almacén del sistema, o Homebrew y FreeBSD; con las medidas temporales de blocked.certs y comprobación de revocación. — La corrección depende de quién entrega el JDK y de qué lista de autoridades usa.

Corrección y medidas temporales

OpenJDK recomienda actualizar el JDK independiente lo antes posible. Las fuentes reportan como corregidas las compilaciones con sufijo .0.2 (por ejemplo, la 21.0.13 y la 25.0.5 con ese sufijo); conviene confirmarlo en las notas de cada proveedor. Si no es posible actualizar de inmediato, OpenJDK documenta dos medidas:

Reemplazar blocked.certs: descargar el archivo oficial para el sistema operativo y sustituir $JDK_HOME/lib/security/blocked.certs, conservando las entradas propias que existieran. En JDK 8 el archivo se llama blacklisted.certs.
Activar la comprobación de revocación: añadir -Dcom.sun.net.ssl.checkRevocation=true y -Dcom.sun.security.enableCRLDP=true al arranque. La prueba de lilting.ch confirma que así Java rechaza la cadena con CertificateRevokedException; a cambio, la conexión depende de que las listas de revocación estén accesibles.

Ambas medidas se aplican por instalación: un servidor con varios JDK necesita repetirlas en cada uno. Como dos de los intermedios firmaban código, en JDK 17 o superior conviene verificar los JAR firmados con jarsigner -verify -revcheck -strict.

El parche trimestral del 20 de octubre

El CPU de octubre de 2026 corrige 1209 CVE en 33 familias de productos de Oracle; para Java SE incluye 55 parches, 49 de ellos explotables por red sin autenticación, según el resumen de Tenable. Oracle no identificó explotación activa de esas fallas, pero recuerda en su aviso que ha recibido reportes de ataques exitosos contra vulnerabilidades ya corregidas en clientes que no aplicaron los parches. La próxima publicación de seguridad de Oracle está prevista para el 17 de noviembre de 2026.

Procedimiento de verificación

Inventariar todas las instalaciones de Java, incluidas las incluidas dentro de productos de terceros (servidores de aplicaciones, herramientas de CI, agentes).
Obtener la versión exacta con java -version desde la ruta que usa cada servicio, no la del PATH del usuario.
Determinar si usa cacerts propio o el del sistema: un JDK independiente lo tiene en $JAVA_HOME/lib/security/cacerts como archivo real; en paquetes de distribución suele ser un enlace al almacén del sistema.
Listar las autoridades sospechosas: keytool -list -cacerts | grep -i emsign.
Probar el rechazo contra los servidores de prueba del incidente (emudhra.we-have-a-problem.com) con el mismo JDK y opciones del servicio: la conexión debe fallar.

Preguntas frecuentes

Acabamos de aplicar el CPU de octubre. ¿Ya estamos cubiertos?

No necesariamente. Las versiones publicadas en el CPU del 20 de octubre son justamente las que la alerta del 21 de octubre declara afectadas. Hace falta la compilación posterior o una de las medidas temporales.

¿Puedo simplemente borrar la raíz emSign de cacerts?

Reduce el riesgo para la cadena de eMudhra, pero no para los certificados cruzados firmados por la raíz de Sectigo. OpenJDK recomienda el archivo blocked.certs oficial o la actualización, que cubren ambas rutas.

Fuentes

Oracle, Security Alert CVE-2026-91403.
OpenJDK, Vulnerability Advisory 2026/10/21.
Oracle, Critical Patch Update de octubre de 2026.
Tenable, resumen del CPU.
lilting.ch, prueba en OpenJDK y Temurin.
Contexto del incidente: certificados de eMudhra comprometidos.

Apoyo con Java y productos de Oracle

Xterra Engine aplica parches de Java en servidores de aplicaciones e integraciones, verifica el almacén de confianza de cada instalación y planifica la migración de versiones sin soporte. Para solicitar apoyo o una cotización, escriba a info@xterraengine.com o use el formulario de contacto.