Volver

2026/10/30

Los navegadores quedaron protegidos en horas. ¿Y el Java empresarial? Cómo respondió LOGIQ al incidente de certificados de eMudhra

Los navegadores bloquearon en horas los intermedios de eMudhra, pero cada JDK tiene su almacén de confianza. Qué hicieron Azul, BellSoft y LOGIQ, y qué revisar.

Puntos clave

  • El 17 de octubre de 2026, Mozilla recibió un informe según el cual las claves privadas de ocho certificados de CA intermedia de eMudhra habían sido comprometidas. Los navegadores los bloquearon en cuestión de horas o días. eMudhra afirma que no tiene constancia de ninguna prueba de que las claves se hayan explotado.
  • Java no utiliza las decisiones de confianza del navegador ni del sistema operativo. Cada JDK, y cada imagen de contenedor o aplicación que incluya uno, lleva su propio almacén de confianza. Cada uno de ellos necesita su propia actualización.
  • Azul publicó dos actualizaciones extraordinarias de Zulu, el 21 y el 24 de octubre. La segunda existe porque la primera corrección no bastaba, de modo que la solución provisional del 21 de octubre ya no es suficiente por sí sola.
  • BellSoft indica builds corregidas de Liberica para Java 8, 11, 17, 21, 25 y 27. LOGIQ obtuvo estas builds a través de nuestro canal de soporte de BellSoft y las puso a disposición de nuestros clientes.
  • Qué hacer: localice todos los entornos de ejecución de Java que utiliza, compruebe el proveedor y la build exactos, pase a la build corregida de ese proveedor, pruebe sus conexiones TLS y siga atento a las versiones extraordinarias.

Qué ocurrió

El sábado 17 de octubre de 2026, a las 20:06 UTC, Mozilla recibió un informe según el cual las claves privadas de ocho certificados intermedios de eMudhra habían sido comprometidas. Mozilla bloqueó los ocho certificados en Firefox mediante OneCRL, su lista central de revocación, y la actualización había llegado a los usuarios con la configuración estándar a las 22:59 UTC, menos de tres horas después. Mozilla hizo público el incidente el 20 de octubre. También publicó versiones menores de Firefox para los usuarios cuya configuración bloqueaba la actualización de OneCRL, y retiró del almacén de confianza de NSS el certificado raíz que había firmado los intermedios.

El riesgo es la falsificación de certificados. Cualquiera que tuviera una de estas claves podría emitir un certificado HTTPS para un sitio que no controla. Si además lograra situarse entre un cliente y ese sitio, podría suplantarlo y leer o modificar el tráfico.

Hasta ahora no hay pruebas de que esto haya ocurrido. En su declaración sobre el incidente, eMudhra afirma que los ocho intermedios se revocaron el 18 de octubre, que ninguno de ellos había emitido certificados de entidad final y que «no tiene constancia de ninguna prueba de que las claves débiles hayan sido recuperadas o explotadas por nadie antes de que se divulgara el problema». eMudhra atribuye la causa a claves débiles generadas durante una ceremonia de claves de 2025. Afirma que aún no ha confirmado la causa raíz exacta y que su investigación sigue en curso. Los programas de certificados raíz de los navegadores retiraron la confianza a la raíz de eMudhra situada por encima de estos intermedios como medida de precaución.

Por tanto, este artículo trata de cerrar una ventana de exposición, no de un ataque confirmado.

Por qué Java necesita su propia corrección

Los navegadores y los sistemas operativos disponen de mecanismos automáticos para dejar de confiar en una autoridad de certificación, y los aplicaron con rapidez. Según el relato del incidente de Azul, Chrome bloqueó los certificados el mismo día, Apple el 19 de octubre y Microsoft el 20 de octubre.

Java no hereda nada de esto. Un JDK decide en qué certificados confiar a partir de sus propios archivos:

  • Su propio almacén de confianza. Cada JDK incluye su propio archivo cacerts. Actualizar el paquete de certificados del sistema operativo o reiniciar un navegador no lo modifica.
  • Sin comprobaciones de revocación por defecto. Como indica la documentación de Azul, Java confía en los certificados raíz de los que dependen estos intermedios y «no comprueba la revocación por defecto». Que eMudhra haya revocado los intermedios no protege, por sí solo, a un cliente Java.
  • Muchas copias. Un servidor puede ejecutar el JDK del sistema, un JDK incluido dentro de una aplicación, un entorno de ejecución creado con jlink y varias imágenes de contenedor, cada uno con su propia copia del almacén de confianza. Cada copia sigue expuesta hasta que se actualiza o se reconstruye.

Así, un servicio Java que realiza llamadas TLS salientes puede seguir aceptando un certificado falsificado cuando todos los navegadores del edificio ya están protegidos. Esa es la brecha de la que trata este artículo.

Dos actualizaciones de emergencia de Azul

Azul publicó dos actualizaciones extraordinarias de Azul Zulu después de su versión trimestral de octubre:

  • 21 de octubre: la primera actualización extraordinaria añade los ocho intermedios comprometidos a la lista de bloqueo del JDK (blocked.certs en JDK 11 y posteriores, blacklisted.certs en versiones anteriores). Abarca Zulu 27, 25, 21, 17, 11, 8, 7 y 6. La lista de CVE de Azul la registra como CVE-2026-91403. Para los entornos de ejecución que no podían actualizarse de inmediato, Azul publicó también una solución provisional manual que sustituye el archivo de la lista de bloqueo.
  • 24 de octubre: Azul determinó que la lista de bloqueo no resolvía el problema por completo. La segunda actualización extraordinaria corrige CVE-2026-114820 (JSSE, puntuación base 9.1) eliminando por completo determinados certificados de CA de cacerts. En el momento de redactar este artículo, estas builds están disponibles para la línea CPU de Azul, que solo incluye correcciones de seguridad, tanto sobre la base CPU de octubre de 2026 (por ejemplo, Zulu 21.53.114, 17.69.114, 11.91.114 y 8.97.0.112) como sobre la base CPU de julio de 2026. Azul afirma que las builds PSU «probablemente» llegarán en una actualización independiente.

La actualización del 24 de octubre cambia la recomendación. La página de la solución provisional de Azul advierte ahora de que esta «ya no resuelve completamente el problema», y Azul pide a todos sus clientes que actualicen a la versión más reciente. Si aplicó la actualización del 21 de octubre o la solución provisional, sigue necesitando la build del 24 de octubre. En su propio análisis, Azul indica que transcurrieron unas 12 horas desde la decisión de regenerar las builds hasta que las builds solo de seguridad estuvieron en manos de los clientes.

Qué publicó BellSoft para Liberica JDK

BellSoft publicó su versión habitual de Liberica JDK de octubre de 2026 el 21 de octubre. Esa versión trimestral enumera 52 CVE corregidas e incluye builds CPU para Java 6 y 7 (6u521 y 7u521). Sus notas de la versión no abordan el problema de eMudhra.

BellSoft trata eMudhra en una guía aparte, «Retirar la confianza a los intermedios comprometidos de eMudhra en Java» (actualizada por última vez el 27 de octubre). En ella se indican como builds corregidas Liberica JDK 8u513+9, 11.0.33.0.3+7, 17.0.21.0.3+5, 21.0.13.0.3+5, 25.0.5.0.3+5 y 27.0.1.0.3+5. Para los sistemas que aún no pueden actualizarse, la guía ofrece una mitigación temporal: eliminar las raíces afectadas del almacén de confianza. Advierte de que esto puede romper cadenas de certificados legítimas y de que debe probarse antes.

Hay dos aspectos importantes al comparar proveedores:

  • Las listas de CVE no son las mismas. Azul y BellSoft publican cada uno su propia lista de CVE para el ciclo de octubre, y los recuentos y las notas difieren. Los dos identificadores CVE de Azul mencionados arriba proceden de los registros de Azul. La guía de BellSoft no los cita. Consulte las notas de la versión de su propio proveedor para conocer las correcciones exactas de su build, y no dé por hecho que la lista de un proveedor se aplica al JDK de otro.
  • Java 6 y 7 no figuran en la lista de eMudhra de BellSoft. Las últimas builds de Java 6 y 7 de BellSoft están disponibles, pero la lista de builds corregidas de su guía sobre eMudhra empieza en Java 8. Si utiliza Liberica 6 o 7, pregunte si su build incluye el cambio en el almacén de confianza antes de confiar en ella, o aplique la mitigación del proveedor. Azul indica builds del 24 de octubre para Zulu 6 y 7.

Cómo respondió LOGIQ

Distribuimos builds de Java de BellSoft y Azul a nuestros clientes y les ayudamos a migrar desde versiones antiguas de Oracle JDK. Esto es lo que hicimos, con el estado de cada punto en el momento de redactar este artículo (29 de octubre).

Completado

  • 21–22 de octubre: revisión de los avisos de los proveedores. Recibimos y revisamos el aviso extraordinario de Azul del 21 de octubre y el aviso de la versión de octubre de 2026 de BellSoft. Ese mismo día abrimos tareas de descarga y de repositorio para ambos proveedores. Tratamos las dos versiones por separado y no dimos por hecho que la versión trimestral de BellSoft contuviera la misma corrección para eMudhra que la de Azul.
  • 23 de octubre: builds trimestrales de Liberica preparadas. Descargamos las builds de Liberica JDK de octubre de 2026 del portal de soporte de BellSoft y las añadimos al repositorio desde el que descargan nuestros clientes.
  • 24–25 de octubre: seguimiento de la segunda actualización de Azul. Recogimos el aviso de Azul del 24 de octubre, incluida su recomendación de actualizar aunque ya estuviera instalada la build del 21 de octubre.
  • 27–28 de octubre: builds corregidas de Liberica obtenidas a través de BellSoft. A través de nuestra relación de soporte comercial, pedimos a BellSoft que pusiera las builds más recientes a disposición en nuestro portal de soporte. BellSoft las subió el 28 de octubre, incluidas las builds corregidas para Java 8, 11, 17, 21, 25 y 27 y las últimas builds de Java 6 y 7. Algunos clientes todavía necesitan Java 8 de 32 bits, así que también pedimos a BellSoft que añadiera a nuestro portal los instaladores de 32 bits de 8u513+9 para Windows y Linux. BellSoft los añadió ese mismo día.
  • 28–29 de octubre: actualización del repositorio y de las correspondencias de migración. Añadimos estas builds a nuestro repositorio de descargas para clientes y actualizamos nuestra guía de migración de Oracle JDK a Liberica para que remita a ellas; un segundo ingeniero revisó la actualización.

Clientes de Azul Zulu

Las builds de Azul del 21 y del 24 de octubre están disponibles para los suscriptores de Azul a través de Azul. La build adecuada depende de su versión de Java, de si utiliza la línea CPU o PSU y de la base (octubre o julio) en la que se encuentre. Consulte las notas de la versión de Azul para su build exacta, o pregúntenos y le ayudaremos a identificarla.

Java 6 y 7 heredados

Algunos clientes todavía ejecutan Java 6 o 7, a menudo en aplicaciones que no pueden migrarse con rapidez. Oracle ya no ofrece actualizaciones públicas para estas versiones, pero eso no significa que no haya opciones. Ayudamos a los clientes a migrar de las antiguas builds de Oracle JDK 6 y 7 a las últimas builds de Liberica JDK 6 y 7, y las builds de octubre de 2026 de BellSoft para ambas versiones están a nuestra disposición a través del portal de soporte de BellSoft. Cuando falta una corrección o un paquete que necesitamos para estas versiones, lo escalamos a BellSoft a través de nuestro canal de soporte comercial. Para este incidente, tenga en cuenta la nota anterior: confirme que su build de Java 6 o 7 incluye el cambio en el almacén de confianza relativo a eMudhra antes de confiar en ella.

Qué debe hacer ahora

1. Localice todos los entornos de ejecución de Java

Enumere todos los lugares donde se ejecuta Java, no solo el JDK del sistema. Eso incluye servidores de aplicaciones, entornos de ejecución incluidos en productos de terceros, imágenes de jlink, agentes de compilación de CI y todas las imágenes de contenedor. En Linux, este comando localiza los binarios de Java en un host:

find / -xdev -type f -path "*/bin/java" 2>/dev/null

Para las imágenes de contenedor, ejecute la comprobación dentro de la imagen, por ejemplo docker run --rm --entrypoint java <image> -version.

2. Compruebe el proveedor y la build exactos

La versión principal no basta. Necesita el proveedor y el número de build completo para cotejarlos con la lista de builds corregidas del proveedor:

java -XshowSettings:properties -version 2>&1 | grep -E "java.vendor =|java.runtime.version|java.home"

Como indicador rápido, también puede enumerar las raíces de eMudhra (emSign) del almacén de confianza de un entorno de ejecución:

keytool -list -keystore "<java.home>/lib/security/cacerts" -storepass changeit | grep -i emsign

En nuestras pruebas con las imágenes de contenedor públicas de BellSoft, una build antigua de Liberica 21.0.10 mostraba cinco raíces emSign, mientras que las builds corregidas 21.0.13.0.3+5 y 8u513 no mostraban ninguna. Un resultado vacío es una buena señal, pero no una prueba. La corrección de Azul del 21 de octubre, por ejemplo, bloqueaba los intermedios sin eliminar raíces. El número de build es la comprobación fiable. Nuestro artículo anterior sobre cómo comprobar los almacenes de confianza de Java describe comprobaciones más detalladas.

3. Aplique el último parche correspondiente

  • Azul Zulu: pase a la build extraordinaria del 24 de octubre para su línea (CPU o PSU, base de octubre o de julio), aunque haya instalado la build del 21 de octubre o aplicado la solución provisional. Si utiliza builds PSU, esté atento a la versión PSU posterior de Azul.
  • Liberica JDK: pase a las builds corregidas que indica BellSoft (8u513+9, 11.0.33.0.3+7, 17.0.21.0.3+5, 21.0.13.0.3+5, 25.0.5.0.3+5, 27.0.1.0.3+5).
  • Otros proveedores y entornos de ejecución incluidos: consulte el aviso de seguridad de ese proveedor. Un JDK incluido en un producto de terceros lo actualiza el proveedor de ese producto, no las actualizaciones de su sistema operativo.
  • Contenedores: reconstruya las imágenes sobre una imagen base corregida y vuelva a desplegarlas. Parchear un contenedor en ejecución no modifica la imagen.

4. Valide TLS antes y durante el despliegue

Eliminar raíces de un almacén de confianza puede romper conexiones legítimas, por ejemplo con sitios que todavía usan certificados que dependen de las raíces de eMudhra eliminadas. eMudhra afirma que está volviendo a emitir los certificados de clientes afectados desde una jerarquía de CA alternativa. Antes de un despliegue amplio, pruebe las conexiones TLS salientes de las que dependen sus aplicaciones, sobre todo con socios o servicios que puedan usar certificados de eMudhra. Despliegue por fases, reinicie los procesos Java para que carguen el nuevo almacén de confianza y confirme después la versión en ejecución.

5. Esté atento a las versiones extraordinarias

Este incidente dio lugar a dos versiones de emergencia de Java en cuatro días, y podrían llegar más, como las builds PSU de Azul. Suscríbase a los avisos de seguridad de sus proveedores, consulte directamente sus páginas de versiones en lugar de depender solo del correo electrónico y prevea actualizaciones de Java fuera del calendario trimestral.

La lección

Los usuarios de Firefox quedaron protegidos en cuestión de horas porque los navegadores tienen sus propios almacenes de confianza y un mecanismo automático para actualizarlos. El Java empresarial tiene muchos almacenes de confianza, no comprueba la revocación por defecto y sus actualizaciones esperan a que alguien las instale. Cerrar esa brecha exige un inventario preciso, números de build exactos, acceso rápido a las builds de los proveedores y un proceso que no espere al siguiente parche trimestral. Si necesita ayuda para localizar o actualizar los entornos de ejecución de Java de su entorno, póngase en contacto con LOGIQ.

Referencias