Teku y Besu actualizaron sus imágenes Docker para dejar de confiar en certificados vinculados a las claves débiles de eMudhra. Las correcciones llegaron en Teku 26.10.3 y Besu 26.10.2. Los equipos de ambos clientes de Ethereum aclaran que un nodo de mainnet con la configuración predeterminada no está afectado. El riesgo depende de las conexiones y los controles de autenticación que haya añadido cada operador; quienes ejecutan los clientes fuera de Docker también deben revisar el entorno Java que utilizan.
La corrección va dentro de las imágenes Docker
Teku publicó la versión 26.10.3 el 27 de octubre de 2026 y Besu lanzó la 26.10.2 el día anterior. En ambos casos, las notas de versión indican que las imágenes Docker ya no confían en cuatro certificados raíz, entre ellos emSign ECC Root CA - G3, bajo el cual se encontraban las autoridades intermedias comprometidas.
El problema se originó en ocho claves de autoridades certificadoras intermedias de eMudhra que podían recuperarse a partir de información pública. La empresa afirma que recibió el aviso el 17 de octubre y revocó las ocho al día siguiente. Sin embargo, Java no comprueba por defecto la revocación de certificados, según los avisos de Teku y Besu. Una instalación que todavía confía en esas rutas puede aceptar una identidad falsificada.
FomoEra cubrió previamente el bloqueo de los certificados por Google y Mozilla y la decisión de eMudhra de salir del negocio global de SSL/TLS. Las nuevas versiones trasladan la corrección a los contenedores de estos dos clientes de Ethereum.
La exposición cambia según el cliente y su configuración
El aviso de Teku sitúa el riesgo en conexiones HTTPS a servicios externos, como un firmante remoto, un nodo de consenso o un constructor de bloques. Si alguien pudiera interceptar una de esas conexiones y hacerse pasar por el servicio, podría alterar información usada por un validador. En determinadas configuraciones, el equipo contempla el desvío de las comisiones de un bloque o la obtención de firmas sensibles. Teku dice que no se ha reportado explotación.
Besu también identifica conexiones salientes que requerirían interceptación. Su informe añade un caso diferente: una configuración especial que acepta certificados de cliente avalados por autoridades del almacén predeterminado de Java para autenticar el acceso a JSON-RPC. Allí, alguien con acceso de red al servicio podría presentar un certificado falsificado sin interceptar una conexión. La gravedad dependería de qué interfaces estuvieran accesibles y de si existen otras barreras de autenticación. Besu tampoco reporta explotación.
Ambos equipos excluyen sus protocolos de comunicación entre pares de este incidente: no usan esas autoridades certificadoras. La amenaza descrita se concentra en servicios auxiliares y opciones de autenticación, no en un cambio de las reglas de consenso de Ethereum.
Una versión nueva del cliente no actualiza todo Java
Las notas de versión limitan expresamente el retiro de confianza a las imágenes Docker. Teku señala que su imagen aplicó la corrección aunque la imagen base de Eclipse Temurin aún no la incorporaba. Besu advierte que una instalación desde un archivo comprimido puede seguir confiando en las raíces afectadas si usa una distribución de Java suministrada por el operador.
Por eso, para una configuración con las conexiones o la autenticación señaladas en los avisos, la comprobación pertinente es la del Java y el almacén de certificados que usa el proceso en marcha. Actualizar Java en el equipo anfitrión tampoco sustituye la imagen que lleva su propio entorno. Las versiones de Docker resuelven esa parte del despliegue; las instalaciones independientes dependen de la corrección de su runtime.
