Actualización de Java de octubre y CVE-2026-91403: cómo parchear cada JVM

Java ha recibido dos versiones de seguridad en dos días. El 20 de octubre de 2026, la Critical Patch Update trimestral de Oracle corrigió 55 vulnerabilidades en Java SE, 49 de ellas explotables a través de la red sin iniciar sesión. El 21 de octubre, Oracle publicó además una Security Alert fuera de ciclo para CVE-2026-91403, un fallo en la implementación de TLS de Java (JSSE) con una puntuación CVSS de 9.1, y entre las versiones afectadas están las publicadas el día anterior. El IPA de Japón advirtió el 21 de octubre de que su explotación puede bloquear aplicaciones o permitir a un atacante tomar el control del equipo. Esta guía muestra a qué versiones debe pasar, cómo localizar cada entorno de ejecución de Java que utiliza y cómo comprobar que la actualización está realmente en uso.

Qué se corrigió el 20 de octubre

La Critical Patch Update de octubre afecta a Oracle Java SE 27, 26.0.2, 25.0.4.1, 21.0.12.1, 17.0.20.1, 11.0.32.1 y 8u503 y, por tanto, a todas las actualizaciones anteriores de esas versiones. Ninguna de las 55 correcciones de Java está calificada como crítica, pero 49 pueden explotarse de forma remota sin autenticación.

Java 26 no ha recibido corrección: sus actualizaciones terminaron en septiembre de 2026. Si todavía utiliza la 26, pase a la 27 o a la versión de soporte a largo plazo 25.

CVE-2026-91403: las nuevas versiones también están afectadas

CVE-2026-91403 está en JSSE, la parte de Java que gestiona las conexiones TLS. Según Oracle, es fácil de explotar, no requiere cuenta ni interacción del usuario y puede alcanzarse a través de la red mediante varios protocolos, por ejemplo a través de un servicio web que pase datos a las API afectadas. Un ataque con éxito puede leer y modificar datos críticos (CVSS 9.1, AV:N/AC:L/PR:N/UI:N, impacto alto en confidencialidad e integridad).

Las versiones afectadas son exactamente las del 20 de octubre: Java SE 8u511, 11.0.33, 17.0.21, 21.0.13, 25.0.5 y 27.0.1, así como GraalVM for JDK 17.0.21 y 21.0.13 y GraalVM Enterprise 21.3.20. Por lo tanto, la actualización de octubre por sí sola no le protege de este fallo.

Oracle distribuye la corrección para Oracle JDK mediante el documento de parche indicado en la Security Alert, para los clientes con acceso a My Oracle Support. En el momento de escribir este artículo, las páginas públicas de Oracle aún no indican nuevos números de versión para ella, y Oracle no ha dicho si el fallo ya se está explotando. El proyecto OpenJDK publicó su propio aviso el 21 de octubre, de modo que las compilaciones basadas en OpenJDK (Eclipse Temurin, Amazon Corretto, Azul Zulu, Red Hat y los paquetes de las distribuciones Linux) reciben sus correcciones de esos proveedores. Consulte la página de seguridad de su proveedor e instale la primera versión que mencione CVE-2026-91403. Actualizaremos este artículo cuando haya números de versión públicos.

Paso 1: localice cada entorno de ejecución de Java

java -version solo muestra el Java que está en su PATH. Los servidores suelen ejecutar varios: uno incluido con una aplicación, otro en un contenedor, otro instalado hace años en /opt.

En Linux, liste cada binario de Java con su versión:

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

Muestre qué Java utilizan realmente los procesos en ejecución:

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

En Docker, compruebe la versión de Java de cada contenedor en ejecución:

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

En Windows, en 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))" }

No olvide el software que trae su propio Java, como Jenkins, Elasticsearch, Keycloak, los productos de Atlassian, los paquetes de Tomcat, los agentes de compilación y los servidores de juegos.

Paso 2: actualice

Ubuntu y Debian (paquetes de OpenJDK):

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

Red Hat, Rocky, AlmaLinux y Fedora:

sudo dnf upgrade 'java-*-openjdk*'

Oracle JDK: instale la versión de octubre de su rama desde la página de descargas de Oracle y, en cuanto pueda, el parche de CVE-2026-91403 desde My Oracle Support. Revise antes la licencia: a partir de 21.0.13, las actualizaciones de Oracle JDK 21 ya no se rigen por los No-Fee Terms and Conditions gratuitos, y el uso comercial puede requerir una suscripción de pago. Para otras compilaciones de OpenJDK, como Temurin o Corretto, instale la versión más reciente del proveedor.

Contenedores: una actualización en el host no cambia un contenedor. Descargue la imagen base actualizada, reconstruya sus imágenes y vuelva a desplegarlas.

Paso 3: reinicie y verifique

Java carga su código al arrancar, así que un servicio en ejecución mantiene la versión antigua hasta que se reinicia. Tras una actualización de paquetes en Linux, este comando lista los procesos de Java que siguen ejecutando los archivos sustituidos:

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

Reinicie esos servicios, vuelva a ejecutar los comandos del paso 1 y compare las versiones con la tabla anterior.

Hasta que esté instalada la corrección de CVE-2026-91403

• Permita que solo los sistemas que lo necesiten accedan a los servicios Java a través de la red, sobre todo a los servicios que aceptan conexiones TLS desde internet.
• Siempre que sea posible, termine las conexiones TLS delante del servicio Java, por ejemplo en un proxy inverso, para que lleguen menos conexiones TLS no fiables a JSSE. Esto reduce la exposición, pero no sustituye a la corrección.
• Vigile los registros de los servicios Java expuestos a internet en busca de errores TLS inusuales y caídas, y tenga preparadas las copias de seguridad.

Qué viene después

Oracle ha pasado Java a versiones de seguridad más frecuentes. La próxima, una Critical Security Patch Update, está prevista para el 17 de noviembre de 2026, y la siguiente Critical Patch Update trimestral para el 19 de enero de 2027. Anote ambas fechas en su calendario y repita cada vez los tres pasos anteriores.

Si no está seguro de cuáles de sus sistemas ejecutan Java, o si un servicio Java puede haber sido ya atacado, nuestros equipos de seguridad gestionada y de respuesta a incidentes pueden ayudarle.