Teku y Besu, los clientes de Ethereum de Consensys y Hyperledger, se han movido en cuestión de horas. Teku 26.10.3 y Besu 26.10.2 han retirado cuatro raíces de certificados de sus imágenes Docker para cortar por lo sano con el incidente de la autoridad certificadora eMudhra. La letra pequeña deja un flanco abierto: quien ejecuta esos clientes desde binarios en tar o zip debe auditar por su cuenta el Java de su máquina. Nadie ha explotado nada, según Teku. Eso no significa que no quede trabajo.
Conviene ordenar los nombres. Besu es el cliente de ejecución de Hyperledger, el programa que procesa transacciones y mantiene el estado de la red; Teku es el cliente de consenso de Consensys, el que gestiona validadores y produce bloques. Ambos se distribuyen en contenedores Docker y ambos han publicado parches con un día de diferencia: Besu 26.10.2 el 26 de octubre y Teku 26.10.3 el 27 de octubre.
Qué retiran exactamente Teku 26.10.3 y Besu 26.10.2
Las versiones nuevas dejan de confiar en cuatro raíces: emSign ECC Root CA – G3, emSign Root CA – G1, emSign Root CA – G2 y AAA Certificate Services. Una raíz de certificados funciona como un notario digital: el software la acepta por defecto para dar por buena cualquier conexión cifrada firmada por ella o por sus descendientes. Si esa raíz queda comprometida, todo lo que cuelga de ella deja de ser fiable aunque el candado siga pareciendo verde.
El alcance es la parte que importa. El retiro solo afecta a las tiendas de confianza incluidas dentro de las imágenes Docker, y Teku señala como afectadas todas las suyas hasta la versión 26.10.2, incluidas las variantes etiquetadas -jdk25 y -jdk26. En una instalación binaria, en cambio, el cliente usa el runtime de Java que haya puesto el operador. Ahí no hay parche que valga: la revisión es manual y distinta en cada máquina, y las versiones publicadas están recogidas en el repositorio oficial de Teku.
Por qué Java es el punto ciego de esta corrección
Actualizar Java en el sistema anfitrión no arregla nada dentro de un contenedor. El runtime que corre en la imagen es independiente del Java del host, y esa distinción produce un escenario incómodo: un operador puede creer que está al día porque actualizó el cliente y, sin saberlo, mantener una capa que sigue aceptando las raíces cuestionadas.
El origen está en eMudhra. La autoridad certificadora reconoció que un error en un script generó claves débiles y recuperables asociadas a ocho autoridades intermedias emSign G3. Revocó los certificados intermedios tras recibir el reporte el 17 de octubre, y la divulgación pública de la filtración llegó el 20 de octubre. Revocar un intermedio no borra el problema de raíz: si el sistema que valida la cadena conserva la raíz que lo emitió, la confianza sigue ahí.
Actualizar el cliente es la mitad del trabajo. La otra mitad vive en un Java que nadie administra y que muy pocos van a revisar esta semana.
El aviso de Teku insiste en un matiz que muchos administradores pasan por alto: Java no comprueba la revocación de certificados de forma predeterminada. Un runtime que conserve las raíces afectadas sigue siendo un problema aunque la autoridad haya revocado lo revocado. El ataque tampoco es automático: haría falta interceptar una conexión HTTPS concreta para suplantar el endpoint remoto al que se conecta el nodo.
La lista de configuraciones afectadas es larga: firmantes remotos, nodos beacon, clientes de ejecución, builders o relays, ajustes de proponentes, fuentes de datos de arranque, y servicios de métricas. Teku añade Sepolia, Hoodi y Ephemery, las redes de prueba que descargan el estado inicial por HTTPS al arrancar con la base de datos vacía. Y acota qué queda fuera: los nodos de mainnet con configuración predeterminada, sin URLs HTTPS, no están afectados, y la red entre pares —libp2p y discv5— no usa autoridades certificadoras. En el firmante externo, la autenticación mutua TLS reduce el daño a una denegación de servicio.
El eslabón débil no es Ethereum, es la cadena de suministro
Merece la pena separar el susto de la estructura. Ethereum lleva años apoyándose en dos ideas: que ningún cliente concentre el poder y que las capas críticas dependan lo menos posible de terceros. Ese diseño se ha probado otras veces y ha resistido. La seguridad de un nodo, sin embargo, no termina donde acaba el código de Teku o de Besu, sino donde termina el inventario de dependencias de quien lo opera.
Un certificado raíz preinstalado en un JDK es exactamente la pieza que nadie audita porque nadie la ha elegido. Viene de fábrica. Y cuando una autoridad certificadora falla, ese descuido se convierte en superficie de ataque, por pequeña que sea.
Para que el riesgo se materialice hace falta una conjunción poco habitual: una conexión HTTPS abierta hacia un tercero, un runtime sin tocar y un atacante en posición de interceptar el tráfico. La mayoría de los nodos domésticos que solo siguen la cadena no reúnen esas condiciones. Los que sí las reúnen son, precisamente, los que mueven dinero: operadores de staking profesional, proveedores de RPC y equipos que gestionan firmantes.
La otra lectura tiene que ver con la confianza del ecosistema. La descentralización no se mide en número de nodos, sino en cuántos equipos independientes pueden sustituir a otro sin que nadie lo note. Un fallo en una autoridad certificadora externa no pone en duda la red, pero recuerda que el software libre también hereda la fragilidad de sus proveedores. Teku lo ha dicho sin rodeos: no hay explotación conocida. Lo que queda abierto no es si hubo ataque, sino cuántos operadores revisarán su Java antes del próximo parche.
