Oracle alerta de CVE-2026-114820 en Java y GraalVM por las CA eMudhra
Oracle marca como afectadas versiones concretas de Java SE y GraalVM por un fallo en JSSE ligado a certificados eMudhra comprometidos. El aviso asigna CVSS 9.1 y describe explotación remota sin autenticación.
Oracle publicó el 24 de octubre una alerta de seguridad para Java SE y GraalVM por CVE-2026-114820. La vulnerabilidad afecta a JSSE, el conjunto de APIs de Java que implementa conexiones TLS, y el aviso de Oracle le asigna CVSS v3.1 9,1. El cambio llega después de que se comprometieran claves de certificados intermedios de eMudhra; Oracle indica que sus actualizaciones de Java eliminan del almacén de confianza las raíces relacionadas.
La matriz de Oracle describe un vector de red sin autenticación y con complejidad baja. En el escenario explicado por la compañía, una aplicación que use las APIs afectadas y reciba datos a través de un servicio web puede quedar expuesta; no es un aviso que diga que cualquier aplicación Java permita ejecutar código remoto. La puntuación refleja impactos altos en confidencialidad e integridad, pero no disponibilidad, según la propia matriz.
Google informó que las claves privadas de ocho autoridades certificadoras intermedias de eMudhra se generaron con entropía insuficiente. Seis de esas intermedias podían emitir certificados TLS; Chrome bloqueó sus huellas de clave y retiró además una raíz de su almacén. Google no encontró certificados encadenados a esas seis intermedias en los registros de transparencia antes del bloqueo. Eso limita lo que puede afirmarse sobre certificados fraudulentos observados, pero no convierte automáticamente en seguro cada runtime que aún confía en las raíces afectadas.
-InfraCrew dice: Una CA raíz no firma el certificado del servicio directamente en cada conexión; la confianza se propaga por la cadena, y ahí es donde un eslabón comprometido deja de ser una abstracción.-
Qué versiones deben revisar los equipos
Oracle publica como afectadas versiones concretas de Java SE y GraalVM: Java SE 8u511-b32 y 8u511-perf-b32; 11.0.33.0.2; 17.0.21.0.2; 21.0.13.0.2; 25.0.5.0.2 y 27.0.1.0.2. La tabla incluye también GraalVM for JDK 17.0.21.0.2 y 21.0.13.0.2, además de GraalVM Enterprise Edition 21.3.20.0.2. Son builds que Oracle identifica en la matriz de versiones afectadas; no basta con ver “Java 21” en el inventario y asumir que ya está corregido.
La mitigación de Oracle modifica cacerts, el almacén de certificados que acompaña al JDK. Al retirar raíces de confianza, algunas conexiones TLS que dependan de cadenas legítimas bajo esas raíces pueden dejar de validarse; es una consecuencia operativa posible, no un fallo de disponibilidad que Oracle haya reportado en todos los despliegues. La compañía recomienda instalar la actualización más reciente o seguir sus mitigaciones, y limita los parches de Security Alert a versiones dentro de Premier Support o Extended Support.
-InfraCrew dice: “Tenemos Java instalado” no es un inventario; contenedores, servicios empaquetados y herramientas de automatización suelen traer su propio runtime.-
Un parche por runtime, no por etiqueta
Para priorizar el despliegue, los equipos deberían localizar cada JVM que abre conexiones TLS, incluidas imágenes de contenedor, servidores de aplicaciones, agentes y herramientas de integración. Después, hay que comparar la versión completa con la tabla de Oracle, seleccionar la actualización correspondiente a esa rama soportada y validar en pruebas las conexiones a servicios que puedan presentar certificados encadenados a las CA afectadas.
La diferencia entre producto importa: el arreglo de Oracle no sustituye las actualizaciones de otros runtimes. El aviso identifica JSSE y versiones Oracle, mientras que otros runtimes gestionan sus almacenes de certificados y validadores por separado; actualizar un JDK no reconstruye automáticamente un binario Go ni corrige el almacén de confianza de otra distribución. Tras instalar la actualización, hay que sustituir los procesos Java que sigan cargando el almacén antiguo y revisar errores al negociar TLS en las aplicaciones dependientes. Relajar la validación TLS para recuperar una conexión podría devolver justo la confianza que el parche intenta retirar.
-InfraCrew dice: La rotación se considera terminada cuando corre el proceso nuevo, no cuando el paquete ya aparece como instalado en el nodo.-
Diccionario de la Crew
JSSE — Java Secure Socket Extension, APIs de Java para comunicaciones TLS y otras funciones criptográficas de red.
CA — Autoridad certificadora que emite o encadena certificados usados para acreditar identidades.
cacerts — Almacén de certificados de confianza distribuido con el JDK.
