Oracle ha publicado dos alertas de seguridad fuera de su calendario habitual, el 21 y el 24 de octubre de 2026, para retirar la confianza de Java SE y GraalVM en certificados ligados a eMudhra, una autoridad de certificación india cuyas claves privadas intermedias se generaron con aleatoriedad insuficiente. Las dos vulnerabilidades, CVE-2026-91403 y CVE-2026-114820, tienen una puntuación CVSS de 9,1 sobre 10, e INCIBE-CERT actualizó el 26 de octubre su aviso para recogerlas. Se suman a la actualización trimestral de octubre, que corrigió otros 55 fallos en Java SE.
Las claves de las alertas de Java SE y GraalVM en 30 segundos
- Oracle publicó el 21 de octubre la alerta CVE-2026-91403, que bloquea certificados intermedios de eMudhra con claves débiles.
- El 24 de octubre añadió CVE-2026-114820, que elimina del almacén de Java las raíces relacionadas, incluidas tres de emSign.
- Afectan a Java SE 8, 11, 17, 21, 25 y 27, a GraalVM for JDK 17 y 21 y a GraalVM Enterprise 21.3.
- Un atacante en posición intermedia podría hacer pasar un servidor falso por legítimo ante una aplicación Java.
- Oracle no tiene constancia de explotación activa.
El origen no es un error en el código de Java, sino un problema de confianza. Según la información publicada sobre el incidente, un investigador independiente informó el 17 de octubre de que las claves privadas de ocho autoridades de certificación intermedias de eMudhra se habían generado con aleatoriedad insuficiente y podían recuperarse a partir de los certificados públicos. Esas claves procedían de una ceremonia de generación celebrada el 30 de abril de 2025. Con ellas, un tercero podría emitir certificados válidos para cualquier dominio, y las aplicaciones que confían en esa cadena los aceptarían como legítimos.
Qué corrigen las dos alertas de Oracle
La primera alerta, CVE-2026-91403, afecta al componente JSSE (Java Secure Socket Extension), la parte de Java que gestiona las conexiones TLS. INCIBE-CERT la clasifica como uso de un algoritmo criptográfico roto o inseguro (CWE-327) y recoge el vector de Oracle: explotable por red, con baja complejidad, sin privilegios ni interacción del usuario, y con impacto alto en confidencialidad e integridad, aunque no en disponibilidad. La corrección añade los certificados intermedios de eMudhra a la lista de bloqueo de Java.
Tres días después, Oracle fue un paso más allá con CVE-2026-114820, también con un 9,1. Esta segunda alerta elimina como precaución los certificados raíz asociados del almacén de Java. Según los detalles publicados del aviso, son cuatro entradas: emSign Root CA – G1, emSign Root CA – G2, emSign ECC Root CA – G3 y una entrada identificada como comodoaaaca. eMudhra sostiene que sus claves raíz no se vieron comprometidas y ha anunciado que abandona el negocio global de certificados SSL/TLS.
No todas las fuentes valoran igual el riesgo. Red Hat da a CVE-2026-91403 una puntuación preliminar de 6,8, porque considera que el ataque requiere una complejidad alta y cierta interacción del usuario: el atacante necesita situarse entre el cliente y el servidor para interceptar la conexión. La cifra de 9,1 es la que asigna Oracle y la que recoge INCIBE-CERT.
Versiones afectadas y cómo actualizar
Las dos alertas afectan a las mismas versiones:
- Oracle Java SE: 8u511, 8u511-perf, 11.0.33, 17.0.21, 21.0.13, 25.0.5 y 27.0.1.
- Oracle GraalVM for JDK: 17.0.21 y 21.0.13.
- Oracle GraalVM Enterprise Edition: 21.3.20.
Son las versiones más recientes de cada rama, así que haber aplicado la actualización trimestral de octubre no basta: hay que instalar el build corregido de cada línea, con un número de compilación superior. Oracle recuerda además que las versiones sin soporte no se han evaluado y que pueden estar afectadas. La recomendación principal es actualizar desde Java Downloads o My Oracle Support y reiniciar cada proceso Java tras el cambio.
Si no es posible actualizar de inmediato, Oracle ofrece medidas temporales. Para la primera alerta, se puede sustituir el fichero local blocked.certs (en Java 8, blacklisted.certs) por la versión publicada por Oracle, conservando las entradas propias, y activar la comprobación de revocación en las conexiones TLS:
-Dcom.sun.net.ssl.checkRevocation=true
-Dcom.sun.security.enableCRLDP=truePara la segunda, hay que hacer copia del almacén de claves y eliminar las cuatro raíces citadas. Oracle publica una utilidad, CheckCerts.java, para comprobar si un entorno sigue confiando en esos certificados. En JDK 17 y posteriores también conviene verificar los JAR firmados con jarsigner -verify -revcheck -strict. Java no comprueba la revocación de certificados por defecto, de ahí que actualizar o retirar las raíces sea la protección efectiva.
Contenedores, OpenJDK y la actualización trimestral
El trabajo no termina en el servidor principal. Muchas aplicaciones, contenedores, dispositivos y herramientas de terceros llevan su propio entorno de ejecución Java con su almacén de certificados, y cada uno debe actualizarse por separado. Red Hat explica que los paquetes OpenJDK de RHEL que usan el almacén del sistema reciben la corrección a través del paquete ca-certificates, mientras que las compilaciones portables de OpenJDK incluyen su propio almacén y se actualizan aparte. Navegadores y otros proyectos ya han actuado: según las fuentes consultadas, Mozilla, Google y Apple bloquearon los mismos certificados entre el 17 y el 19 de octubre, y Node.js actualizó su almacén de confianza.
Estas alertas llegan justo después de la actualización crítica trimestral de Oracle del 20 de octubre, que incluyó 1.295 parches para toda su gama de productos. De ellos, 55 corresponden a Java SE, 49 explotables en remoto sin autenticación según Oracle, aunque ninguno de nivel crítico: los más graves llegan a 7,5 y afectan al plugin de Java 8 y a JavaFX. Es otro capítulo de un otoño con un volumen récord de vulnerabilidades, como muestra el análisis de Opensecurity sobre el «octubre negro» de las CVE. Oracle ha programado actualizaciones de seguridad intermedias para el 17 de noviembre y el 15 de diciembre, y su próxima actualización trimestral para el 19 de enero de 2027.
Preguntas frecuentes
¿Qué es CVE-2026-91403?
Una vulnerabilidad de puntuación 9,1 en el componente JSSE de Java SE y GraalVM, por la que Java confiaba en certificados intermedios de eMudhra con claves privadas débiles. Oracle la corrigió en una alerta del 21 de octubre de 2026.
¿Qué añade CVE-2026-114820?
Es una segunda alerta del 24 de octubre que elimina del almacén de Java las raíces relacionadas con eMudhra, como precaución adicional. Afecta a las mismas versiones.
¿Basta con la actualización de octubre de Oracle?
No. Las alertas afectan a las versiones más recientes de cada rama, así que hay que instalar el build corregido posterior y reiniciar los procesos Java.
¿Se está explotando?
Oracle no tiene constancia de explotación activa y la vulnerabilidad no figura en el catálogo de fallos explotados de la CISA, según las fuentes consultadas.
Fuentes:
