Teku y Besu actualizaron sus imágenes Docker para retirar cuatro raíces de certificados vinculadas al incidente de eMudhra. Los operadores de instalaciones binarias, en cambio, deben comprobar por separado si su runtime de Java aún confía en ellas.
***

• Teku 26.10.3 y Besu 26.10.2 retiraron cuatro raíces de certificados de sus imágenes Docker.
• Las distribuciones binarias dependen de un Java instalado y gestionado por cada operador, que requiere una revisión aparte.
• Teku informó que no hubo explotación y que los nodos de mainnet con la configuración predeterminada, sin URLs HTTPS, no están afectados por este problema.

🚨 Teku y Besu retiran certificados de sus imágenes Docker

Teku 26.10.3 y Besu 26.10.2 eliminan cuatro raíces vinculadas al incidente de eMudhra.

Las instalaciones binarias requieren revisar el Java por separado.

Teku informó que no hubo explotación. Los nodos mainnet sin URLs… pic.twitter.com/vSlvtyhrja

— Diario฿itcoin (@DiarioBitcoin) October 28, 2026

Teku y Besu corrigen sus imágenes Docker, pero Java aún exige una revisión aparte

Los equipos detrás de Teku y Besu publicaron actualizaciones de seguridad para retirar cuatro raíces de certificados de las imágenes Docker de ambos clientes de Ethereum, tras un incidente relacionado con la autoridad certificadora eMudhra. La corrección modifica las tiendas de confianza incluidas en esos contenedores, pero no actualiza automáticamente el Java que usan las instalaciones binarias, cuyo estado depende de cada operador.

Teku 26.10.3, publicado el 27 de octubre, y Besu 26.10.2, lanzado el 26 de octubre, incorporan el cambio en sus respectivas imágenes de contenedor. El aviso de seguridad de Teku señala que no hubo explotación y acota la exposición: los nodos de mainnet que mantienen la configuración predeterminada y no usan URLs HTTPS no están afectados por este problema de certificados.

Qué cambiaron las actualizaciones

Las versiones nuevas dejan de confiar en emSign ECC Root CA – G3, emSign Root CA – G1, emSign Root CA – G2 y AAA Certificate Services. Estas raíces son certificados de confianza que el software puede usar para validar conexiones seguras; al quitarlas de las imágenes, Teku y Besu limitan la posibilidad de aceptar certificados vinculados a la incidencia.

El retiro se aplica a las tiendas de confianza que los proyectos incluyen en sus imágenes Docker, no a todos los entornos donde se ejecutan sus clientes. En las distribuciones en paquetes tar o zip, el JDK puede seguir confiando en las raíces afectadas; por eso, los operadores deben revisar también ese componente.

Teku identificó como afectadas todas sus imágenes Docker hasta la versión 26.10.2, incluidas las variantes etiquetadas como -jdk25 y -jdk26. En esos contenedores, actualizar Java en el sistema anfitrión no basta: el runtime que se ejecuta dentro de la imagen es independiente del Java del host.

La distinción importa porque un operador puede actualizar el cliente y mantener, sin advertirlo, una capa de ejecución que todavía acepta las raíces cuestionadas. En el caso de las distribuciones binarias de Teku, el programa utiliza el runtime de Java que haya instalado el operador; la comprobación y cualquier corrección de ese componente deben realizarse por separado.

El origen del riesgo y sus límites

El incidente que motivó las actualizaciones involucró claves privadas recuperables asociadas con ocho autoridades certificadoras intermedias emSign G3. eMudhra reconoció que un error en un script produjo claves débiles y afirmó que revocó los certificados intermedios después de recibir un reporte el 17 de octubre. La divulgación pública de la filtración de las claves fue el 20 de octubre, según la documentación de Azul sobre la mitigación.

La revocación de los certificados intermedios no elimina por sí misma la necesidad de revisar todos los runtimes Java afectados. El aviso de Teku advierte que Java no comprueba la revocación de certificados de manera predeterminada, por lo que un runtime que conserve las raíces pertinentes todavía requiere su propia remediación.

El escenario descrito no implica que cualquier nodo Ethereum esté expuesto de forma automática. Según Teku, en un runtime sin corregir un atacante necesitaría interceptar una conexión HTTPS afectada para suplantar el endpoint remoto; el riesgo depende, por tanto, de la configuración y de las conexiones que el operador utilice.

Teku indicó que los nodos de mainnet con la configuración predeterminada y sin URLs HTTPS quedan fuera de este problema específico. También aclaró que su red entre pares, incluidos libp2p y discv5, no utiliza autoridades certificadoras y no está comprendida en la incidencia descrita.

Qué deben revisar los operadores

Los equipos que ejecutan Teku o Besu en Docker deben actualizar a las versiones corregidas para incorporar el retiro de raíces en las imágenes: Teku 26.10.3 y Besu 26.10.2. Quienes usan paquetes binarios o tar y zip, en cambio, deben comprobar qué JDK acompaña su instalación y si todavía confía en los certificados señalados.

La revisión cobra importancia para las configuraciones de Teku que establecen conexiones HTTPS, entre ellas las que usan firmantes remotos, nodos beacon, clientes de ejecución y builders o relays. El aviso también incluye configuraciones de proponentes, fuentes de datos de arranque y servicios de métricas, por lo que el inventario de conexiones debe reflejar el uso real de cada operador.

Teku menciona además Sepolia, Hoodi y Ephemery, redes que descargan el estado inicial por HTTPS cuando se inician con una base de datos vacía. Si un runtime sin corregir permite la interceptación de una de esas conexiones, un atacante podría suplantar un nodo beacon remoto, con el riesgo de redirigir comisiones de propuesta o provocar que se incumplan deberes de validador.

El aviso contempla también la suplantación de un firmante externo expuesto, que podría permitir obtener firmas para salidas de validadores. Sin embargo, Teku señala que la autenticación mutua TLS del cliente en el firmante limita el impacto en ese caso a una denegación de servicio; la medida no sustituye la revisión del runtime, pero acota el escenario descrito.

La conclusión operativa es que instalar la versión nueva del cliente no garantiza por sí sola que todas las capas de una instalación estén corregidas. Los operadores deben distinguir entre el contenido de una imagen Docker y el Java que administran fuera de ella, revisar las conexiones HTTPS que efectivamente utilizan y aplicar la remediación que corresponda si su runtime conserva las raíces afectadas.

ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín