Puntos clave de la noticia:
- Teku 26.10.3 y Besu 26.10.2 eliminan la confianza en raíces vinculadas a eMudhra tras descubrirse claves intermedias comprometidas que exponían algunas configuraciones HTTPS.
- Los nodos mainnet predeterminados de Teku no estuvieron afectados y no se reportaron exploits, mientras el riesgo dependía de servicios externos y posición de red.
- Los usuarios de Docker deben actualizar imágenes, mientras operadores standalone necesitan parchear Java; quienes usan Java 26 deben migrar a Java 25.
Teku y Besu publicaron actualizaciones tras descubrir que claves comprometidas de autoridades de certificación de eMudhra exponían algunas configuraciones de nodos de Ethereum a conexiones HTTPS falsificadas. Las notas de Teku recomiendan la versión 26.10.3, que elimina cuatro raíces afectadas de Docker, mientras Besu lanzó la 26.10.2. Las actualizaciones corrigen un riesgo en la capa de confianza del software, no un fallo en el consenso de Ethereum. Los nodos mainnet predeterminados de Teku no resultaron afectados, diferenciando el incidente del protocolo de Ethereum.
Las claves comprometidas crearon un riesgo de suplantación
Investigadores descubrieron que podían recuperarse claves privadas de ocho autoridades intermedias de eMudhra porque fueron generadas con aleatoriedad insuficiente. Aunque los certificados se revocaron, Java no comprueba revocaciones por defecto, permitiendo que algunos runtimes aceptaran certificados falsificados. Un atacante situado entre un nodo y un servicio HTTPS podía hacerse pasar por ese endpoint bajo configuraciones vulnerables. El caso refuerza por qué la diversidad de clientes y seguridad operativa exceden el código de consenso.
Los escenarios de mayor riesgo involucraban validadores conectados a servicios externos mediante HTTPS. Un endpoint falsificado podía manipular bloques, redirigir fees u obtener firmas mediante un firmante suplantado. Teku indicó que un atacante podía hacer que un cliente validador con un beacon node remoto propusiera un bloque pagando fees a su dirección. El riesgo dependía de la posición del atacante y de configuraciones remotas, no simplemente de ejecutar Teku o Besu. No se reportaron exploits.
Teku 26.10.3 elimina de Docker la confianza en emSign ECC Root CA G3, emSign Root CA G1, emSign Root CA G2 y AAA Certificate Services. Besu aplica el mismo enfoque. Quienes ejecutan binarios deben actualizar Java aparte, porque actualizar el cliente no reemplaza el almacén de certificados. Los despliegues Docker y standalone requieren rutas de mitigación diferentes. La distinción importa tras incidentes de infraestructura de validadores que mostraron cómo dependencias externas pueden afectar el staking.
Java 26 está fuera de soporte y no recibirá el parche, por lo que los afectados deben migrar a Java 25. La red peer-to-peer no estuvo expuesta porque no depende de esas autoridades. Las correcciones reducen un riesgo de terceros en el trust store sin reparar un exploit en mainnet ni modificar Ethereum. El episodio sigue a la corrección de Glamsterdam y demuestra que la seguridad de validadores depende del protocolo y su infraestructura.
