Los clientes de Ethereum corrigen una falla que podría redirigir las recompensas de ETH
Actualizaciones de Teku y Besu destacan la importancia de la seguridad de la infraestructura externa
El cliente de consenso de Ethereum Teku y el cliente de ejecución Besu lanzaron actualizaciones de seguridad a finales de octubre de 2026 para cerrar una vulnerabilidad relacionada con claves de autoridad de certificados comprometidas de la empresa india eMudhra. La falla podría haber permitido a atacantes que interceptaran ciertas conexiones HTTPS suplantar servicios externos utilizados por validadores y redirigir recompensas de bloque u obtener firmas sensibles. Los investigadores descubrieron que ocho autoridades de certificados intermedias de eMudhra tenían claves privadas generadas con aleatoriedad insuficiente, lo que hacía que esas claves fueran recuperables a partir de los certificados públicos mismos. Debido a que las ejecuciones de Java utilizadas por ambos clientes no verifican la revocación de certificados por defecto, algunas imágenes de Docker e instalaciones continuaron confiando en las cadenas afectadas incluso después de que los navegadores y los principales sistemas operativos las bloquearan. Las configuraciones predeterminadas de mainnet de Teku que evitaban puntos finales HTTPS no se vieron afectadas, y los desarrolladores informaron que no se ha confirmado ninguna explotación.
Los parches eliminan la confianza en las raíces implicadas de las imágenes de Docker actualizadas, mientras que los operadores que ejecutan binarios independientes deben abordar sus almacenes de confianza Java locales por separado. Este episodio subraya cómo las dependencias de infraestructura externa pueden generar riesgos estrechos pero de alto impacto para las operaciones de staking, incluso cuando el protocolo principal permanece seguro. La rápida respuesta de Teku y Besu demuestra que la diversidad de clientes de Ethereum y las prácticas proactivas de seguridad pueden contener amenazas relacionadas con certificados antes de que afecten las recompensas de los validadores a gran escala, siempre que los operadores apliquen las actualizaciones disponibles y revisen sus configuraciones de conexión externa.
Aleatoriedad débil en las claves intermedias de eMudhra generó material privado recuperable
Los investigadores identificaron el problema el 17 de octubre de 2026, cuando determinaron que las claves privadas detrás de ocho de las autoridades de certificación intermedias de eMudhra habían sido generadas con demasiada poca entropía. Las claves eran efectivamente recuperables a partir de los certificados públicos, una condición que había existido desde su creación en una ceremonia de generación de claves de abril de 2025. Seis de las intermedias respaldaban conexiones TLS, mientras que dos estaban relacionadas con la firma de código. Una vez que el material privado se hizo conocido, un atacante podría emitir certificados fraudulentos que el software que aún confiaba en las autoridades afectadas aceptaría como válidos. eMudhra revocó las intermedias el 18 de octubre. Las principales plataformas respondieron rápidamente: los navegadores y sistemas operativos comenzaron a bloquear los certificados entre el 17 y el 20 de octubre, y Microsoft emitió actualizaciones adicionales para Windows y Edge el 26 y 27 de octubre que eliminaron las raíces asociadas de sus listas de confianza. El fallo criptográfico en sí no fue un problema del protocolo Ethereum, pero importó porque Teku y Besu dependen de la validación de certificados Java para cualquier conexión HTTPS que sus nodos realicen. El comportamiento predeterminado de Java de omitir las verificaciones de revocación dejó ciertas instalaciones expuestas más tiempo que los entornos de navegador. Por lo tanto, el incidente ilustra cómo un error operativo de una única autoridad de certificación puede propagarse hacia infraestructura especializada que depende de almacenes de confianza TLS estándar.
La recuperación de las claves no requirió criptoanálisis sofisticado; la aleatoriedad insuficiente hizo que la derivación fuera sencilla una vez examinados los certificados públicos. El aviso de Microsoft del 26 de octubre confirmó que las claves podían utilizarse para crear certificados que parecieran provenir de una autoridad confiable, posiblemente permitiendo la suplantación de sitios web o servicios. Para los operadores de Ethereum, la consecuencia práctica fue que cualquier configuración de validador que dependiera de puntos finales HTTPS, nodos baliza remotos, firmadores externos, constructores de bloques o relés podría aceptar un certificado falsificado si la ejecución de Java subyacente aún confiaba en la cadena comprometida. La red peer-to-peer utilizada por los clientes de Ethereum permaneció sin afectar, ya que no depende de estas autoridades de certificación. La combinación de claves recuperables y validación de Java sin revocación creó una ventana en la que un atacante de tipo hombre-en-el-medio posicionado en la ruta de la red podría presentar una identidad plausible al software cliente. Los equipos de clientes respondieron eliminando las raíces relevantes de sus imágenes Docker en lugar de esperar únicamente actualizaciones base de Java, asegurando que los operadores que obtengan imágenes frescas reciban un almacén de confianza reforzado. Esta respuesta en capas —revocación en la CA, bloques en la plataforma y actualizaciones específicas de imágenes de clientes— limitó la superficie de ataque práctica para la mayoría de las configuraciones de staking.
Cómo los certificados falsificados podrían alterar el comportamiento de la propuesta de bloque y el receptor de tarifas
El aviso de seguridad de Teku describió rutas de ataque concretas que se vuelven posibles una vez que un atacante puede presentar un certificado falsificado aceptado por el cliente. Un escenario implica suplantar un nodo de baliza remoto que un validador utiliza para la coordinación. Si la conexión es interceptada y se acepta el certificado falsificado, el validador podría recibir información manipulada sobre el bloque que está preparando para proponer. En ese caso, el cliente podría construir y firmar un bloque cuya dirección del receptor de tarifas apunta a una cuenta controlada por el atacante en lugar de la dirección designada por el operador. Las tarifas de transacción y cualquier propina de prioridad incluida en el bloque fluirían entonces hacia el atacante. El aviso también mostró servicios de firma externa, que mantienen las claves del validador por separado y devuelven firmas bajo solicitud. Un atacante capaz de suplantar a dicho firmante podría obtener firmas utilizadas para operaciones sensibles, incluyendo variaciones que afectan a dónde se dirigen las recompensas. Teku clasificó el caso del firmante externo entre las configuraciones más serias, aunque la autenticación TLS mutua en algunas configuraciones limitaría el impacto a denegación de servicio en lugar de compromiso de firma.
Los tipos de conexión expuestos adicionales incluyen clientes de ejecución, constructores de bloques, relés y servicios que suministran datos de configuración de validadores. En cada caso, el riesgo principal es el mismo: el software cliente trata el certificado falsificado como legítimo y, por lo tanto, acepta datos o instrucciones que alteran el contenido de un bloque propuesto o el manejo de claves. La vulnerabilidad no otorga acceso directo a la clave de firma del validador durante el funcionamiento normal; en cambio, socava la integridad de los servicios externos que consulta el validador. Dado que las recompensas y comisiones de Ethereum se pagan según las direcciones incrustadas en el bloque propuesto, una manipulación exitosa en el momento de la propuesta puede desviar valor sin necesidad de mover fondos ya ganados. No se ha informado ninguna explotación de estas vías, y las instalaciones predeterminadas de Teku en mainnet que no contienen URLs HTTPS en su configuración permanecen fuera del conjunto afectado. Los escenarios detallados, sin embargo, aclaran por qué los equipos de clientes consideraron que el problema requería actualizaciones inmediatas de la imagen de Docker, aunque las capas subyacentes del protocolo y punto a punto permanecieran inalteradas.
Teku 26.10.3 elimina raíces comprometidas de los almacenes de confianza de Docker
Teku lanzó la versión 26.10.3 el 27 de octubre de 2026, específicamente para abordar la exposición relacionada con eMudhra. Las notas de la versión indican que las imágenes de Docker ya no confían en las raíces emSign ECC Root CA – G3, emSign Root CA – G1, emSign Root CA – G2 ni AAA Certificate Services. Estas raíces fueron eliminadas por OpenJDK después de que se comprometieran las autoridades intermedias; las imágenes base de Eclipse Temurin utilizadas por Teku aún no habían incorporado la corrección correspondiente en el momento del lanzamiento del cliente. Al enviar imágenes actualizadas, el equipo de Teku garantizó que los operadores que obtengan las nuevas etiquetas reciban un entorno de ejecución de Java cuyo almacén de confianza excluye el material comprometido. El aviso que acompaña al lanzamiento enfatiza que un nodo mainnet por defecto sin URLs HTTPS configuradas no requiere ninguna acción. La exposición está limitada a configuraciones que se conectan deliberadamente a puntos finales HTTPS remotos para coordinación de balizas, firma externa, constructores o servicios similares.
Los operadores que ejecutan imágenes de Docker más antiguas, incluidas las etiquetadas hasta la 26.10.2, continúan utilizando un entorno que confía en las raíces afectadas. Actualizar la instalación de Java del host no actualiza automáticamente el entorno dentro de un contenedor existente, por lo que se requiere una nueva extracción de la imagen. Teku también señaló que Java 26 ha alcanzado el fin de su vida útil y no recibirá una compilación corregida; se recomienda a los operadores que aún usan esa versión migrar a la versión actual de soporte a largo plazo, Java 25, y utilizar las etiquetas de imagen correspondientes -jdk25. Por lo tanto, el lanzamiento combina la eliminación de las raíces de certificados con orientación sobre la gestión de versiones del entorno. Debido a que el cambio se limita a los almacenes de confianza de las imágenes de Docker, el comportamiento de consenso y el manejo de las claves de validador permanecen sin cambios. La actualización se presenta como una medida de seguridad recomendada en lugar de una actualización de consenso de emergencia, reflejando el alcance limitado de las configuraciones afectadas.
Besu 26.10.2 aplica ajustes paralelos de confianza de certificados
Besu, el cliente de la capa de ejecución mantenido por el mismo ecosistema más amplio, lanzó la versión 26.10.2 el 26 de octubre de 2026, implementando las mismas eliminaciones de raíz en sus imágenes de Docker. La sincronización paralela y los objetivos de certificado idénticos indican una conciencia coordinada del incidente de eMudhra en la pila de clientes Ethereum basados en Java. Los clientes de ejecución interactúan con clientes de consenso y servicios externos para la construcción de cargas útiles y la inclusión de transacciones; cualquier ruta de comunicación HTTPS que mantengan está sujeta a las mismas reglas de validación de certificados que afectan a Teku. Al eliminar la confianza en las autoridades comprometidas de sus imágenes, Besu cierra la superficie de ataque correspondiente para los operadores que confían en sus distribuciones de Docker.
Al igual que con Teku, la actualización de Besu no corrige automáticamente las instalaciones binarias independientes que utilizan un entorno de ejecución de Java gestionado por separado. Los operadores en esta categoría deben inspeccionar y actualizar sus almacenes de confianza locales o versiones de Java de forma independiente. Los lanzamientos simultáneos de ambos clientes demuestran que tanto el lado de consenso como el de ejecución de la pila de software del nodo de ethereum reconocieron la dependencia compartida en el manejo de certificados de Java. Dado que muchos validadores en producción ejecutan tanto un cliente de consenso como Teku como un cliente de ejecución como Besu, las actualizaciones simultáneas reducen la posibilidad de que persista una confianza residual en las raíces comprometidas en alguno de los lados del par de nodos. La ausencia de explotaciones reportadas antes de los lanzamientos sugiere que la ventana práctica fue limitada, sin embargo, los parches coordinados aún representan un endurecimiento prudente contra un fallo criptográfico conocido fuera del propio protocolo de ethereum.
La falta predeterminada de verificación de revocación en Java prolonga la exposición
Un detalle técnico central es que la validación de certificados de Java no verifica el estado de revocación por defecto. Incluso después de que eMudhra revocara los certificados intermedios y después de que las principales plataformas los bloquearan, cualquier entorno de ejecución de Java que aún contuviera las raíces o intermedios correspondientes en su almacén de confianza continuaría aceptando certificados que encadenaran a esas autoridades. OpenJDK lanzó correcciones que primero bloquearon los intermedios comprometidos y posteriormente eliminaron cuatro raíces asociadas. Sin embargo, las imágenes de Docker que incluían versiones antiguas de Temurin o OpenJDK no recibieron automáticamente esas correcciones. Esta brecha entre la revocación a nivel de plataforma y el comportamiento de los entornos de ejecución de Java incrustados es lo que requirió actualizaciones específicas de imagen para los clientes.
Para los operadores de Ethereum, la implicación es operativa más que teórica. Un validador cuya configuración incluye puntos finales HTTPS para servicios remotos hereda las decisiones de confianza del entorno de ejecución de Java que utiliza. Si ese entorno de ejecución no ha sido actualizado ni reemplazado con una imagen corregida, el cliente seguirá aceptando un certificado falsificado. El TLS mutuo o los certificados fijados pueden mitigar el riesgo en configuraciones cuidadosamente diseñadas, pero muchas configuraciones de producción dependen de la validación estándar del almacén de confianza. Por lo tanto, los lanzamientos de Teku y Besu sirven como un recordatorio práctico de que el software de nodo contenerizado tiene su propio almacén de certificados independiente del sistema anfitrión. Los operadores que tratan las imágenes de Docker como cajas negras opacas pueden pasar por alto este detalle hasta que un incidente externo obligue a una actualización. El episodio también destaca el valor de monitorear los avisos de seguridad de Java de origen al ejecutar clientes de Ethereum basados en Java.
Las configuraciones predeterminadas del mainnet evitaban la superficie de ataque principal
El aviso de Teku es explícito en que un nodo mainnet por defecto que no contiene URLs HTTPS en su configuración no se ve afectado y no requiere ninguna acción. La mayoría de los validadores que ejecutan clientes de consenso y ejecución localmente colocados, sin firma remota ni endpoints de baliza remotos, caen en esta categoría. Los protocolos de descubrimiento punto a punto y de gossip utilizados por Ethereum no dependen de las autoridades de certificado eMudhra, lo que aísla aún más las configuraciones estándar. El riesgo se concentra entre los operadores que introdujeron deliberadamente dependencias HTTPS externas por conveniencia operativa, distribución geográfica de claves de firma o integración con servicios de construcción de bloques de terceros. Esta distinción es importante para evaluar el impacto general en la red. Debido a que la mayoría de los validadores mainnet operan bajo configuraciones que nunca contactaron las cadenas de certificados vulnerables, la superficie de ataque teórica permaneció limitada incluso antes de los parches.
La decisión de los equipos de clientes de implementar imágenes actualizadas de todos modos protege al subconjunto de operadores que sí utilizan servicios remotos y garantiza que las futuras extracciones de imágenes partan de una base sólida. Las configuraciones de testnet que descargan el estado inicial mediante HTTPS fueron marcadas como potencialmente expuestas, lo que demuestra que la misma lógica de certificados se aplica fuera del mainnet. Los operadores de cualquier red que dependan de HTTPS para el arranque o puntos finales remotos deben considerar las versiones de octubre de 2026 como obligatorias para sus entornos. La clara separación entre configuraciones predeterminadas y no predeterminadas permitió que el aviso fuera al mismo tiempo preciso y tranquilizador para la mayoría del conjunto de validadores.
Los firmantes externos y los nodos de baliza remotos representaron las rutas de mayor riesgo
Entre los escenarios enumerados por Teku, los servicios de firma externa presentaban una gravedad elevada. Estos servicios mantienen las claves privadas del validador fuera de línea o en hardware especializado y responden a solicitudes de firma a través de una conexión de red. Si un atacante puede suplantar al firmante presentando un certificado falsificado, el cliente del validador puede aceptar firmas que autorizan operaciones que el operador nunca intentó, incluyendo aquellas que modifican la configuración del receptor de tarifas o inician salidas. Las configuraciones que imponen autenticación TLS mutua reducen el impacto a denegación de servicio, porque el atacante no puede completar el handshake autenticado. Donde no existe autenticación mutua, el riesgo de obtener firmas utilizables es mayor. Los nodos baliza remotos presentan una preocupación relacionada pero distinta.
Un validador que delega ciertas funciones de coordinación a un punto final de baliza remoto confía en ese punto final para obtener información sobre deberes, contenido de bloques y estado de la red. Una suplantación exitosa puede influir, por lo tanto, en el bloque que el validador propone finalmente, incluyendo la dirección del receptor de tarifas incrustada en ese bloque. Los constructores de bloques y los relés introducen aún otras superficies HTTPS a través de las cuales se podrían inyectar cargas manipuladas. En cada caso, el atacante debe primero lograr una posición de red que permita la interceptación y luego presentar un certificado que el entorno de ejecución Java sin parchear acepte. La combinación de requisitos reduce el conjunto de adversarios realistas, sin embargo, el posible beneficio, tarifas redirigidas de una propuesta exitosa, justifica los parches defensivos. Los operadores que mantienen firmadores externos o infraestructura remota deben priorizar tanto las actualizaciones del cliente como una revisión de los mecanismos de autenticación en esos enlaces.
Los operadores que ejecutan binarios independientes enfrentan obligaciones de actualización de Java separadas
Los usuarios de Docker pueden solucionar el problema descargando las nuevas imágenes de Teku 26.10.3 o Besu 26.10.2. Los operadores que instalan los clientes como binarios o paquetes independientes dependen del entorno de ejecución de Java presente en el sistema anfitrión. Para estas instalaciones, las versiones de los clientes no modifican el almacén de confianza del sistema anfitrión. Por lo tanto, los operadores deben verificar que la versión de Java instalada incluya las correcciones de OpenJDK que eliminan las raíces comprometidas, o bien deben ajustar manualmente el almacén de certificados. Teku advirtió específicamente que Java 26 ha alcanzado su fin de vida y no recibirá una compilación corregida; se requiere la migración a Java 25 para continuar recibiendo soporte y actualizaciones de seguridad. Esta división entre despliegues contenerizados y bare-metal es común en la infraestructura de ethereum y crea un elemento práctico en la lista de verificación para los operadores de nodos.
Inventario de versiones de Java, confirmación del contenido del trust-store y validación de que ningún punto final HTTPS siga apuntando a servicios no confiables forman la higiene mínima posterior a la actualización. Debido a que el fallo criptográfico subyacente ocurrió fuera de Ethereum, las mismas obligaciones de actualización de Java aplican a cualquier otra herramienta basada en Java que un operador pueda ejecutar. Por lo tanto, los avisos del cliente sirven como una corrección específica para Teku y Besu, así como una invitación general a auditar el manejo de certificados en toda la pila del operador. No abordar el entorno Java del host deja abiertas las rutas de ataque teóricas incluso después de haber actualizado el software del cliente.
No se produjo explotación confirmada antes de la aplicación de los parches
Tanto el aviso de Teku como los informes contemporáneos indican que no se ha observado ninguna explotación de la vulnerabilidad. La ausencia de incidentes conocidos es coherente con el conjunto limitado de condiciones necesarias para un ataque exitoso: una ejecución de Java sin parchear, una conexión HTTPS a un servicio externo y un atacante capaz de interceptar esa conexión específica mientras presenta un certificado falsificado. La mayoría de los validadores nunca cumplieron simultáneamente las dos primeras condiciones. El breve intervalo entre la divulgación pública de las claves recuperables el 17 de octubre y el lanzamiento de las imágenes del cliente comprimió aún más la ventana práctica.
La falta de ataques observados no disminuye el valor de los parches. Las vulnerabilidades relacionadas con certificados pueden permanecer dormidas hasta que aparezca un adversario oportunista. Al eliminar las raíces comprometidas de los almacenes de confianza de Docker, los equipos de cliente eliminaron la aceptación de certificados falsificados para los operadores que actualizan. El episodio también proporcionó una demostración en vivo de cómo los fallos criptográficos externos pueden intersectar con la infraestructura de staking de Ethereum, impulsando a los operadores a examinar sus propios gráficos de dependencias. Es probable que futuros incidentes que involucren autoridades de certificados o entornos de ejecución de lenguajes sean atendidos con respuestas similares a nivel de cliente, reforzando el patrón de mitigación rápida y dirigida.
Cómo los riesgos de seguridad de los certificados se extienden a través de las cadenas de bloques
El incidente de eMudhra no es exclusivo de Ethereum; cualquier software que dependa de almacenes de confianza TLS estándar hereda la postura de seguridad de las autoridades de certificación en las que confía. Los clientes de cadena de bloques que incrustan entornos de ejecución de lenguajes como Java, Go u otros deben rastrear las actualizaciones de certificados ascendentes con la misma diligencia que aplican a los cambios en el consenso. El hecho de que la configuración predeterminada de Java omita la verificación de revocación amplificó el impacto y obligó a los equipos de clientes a implementar sus propias modificaciones del almacén de confianza. Otros ecosistemas que empaquetan entornos de ejecución de larga duración dentro de contenedores enfrentan riesgos análogos.
Para la comunidad de Ethereum staking, la lección práctica es que la seguridad operativa va más allá de la gestión de claves y la versión del cliente, e incluye el comportamiento de validación de certificados de cada componente conectado a la red. Los operadores que adoptan firma remota, nodos beacon distribuidos o relés de terceros introducen límites de confianza adicionales que deben monitorearse. La contención exitosa de esta falla específica, mediante la revocación de la CA, bloques en la plataforma y actualizaciones de imágenes del cliente, muestra que las defensas en capas pueden funcionar cuando cada capa responde de manera oportuna. La diversidad continua de clientes sigue siendo valiosa, ya que diferentes implementaciones pueden detectar o mitigar dependencias externas a velocidades distintas, reduciendo la posibilidad de que un único fallo de certificado afecte simultáneamente a todo el conjunto de validadores.
Las preocupaciones recientes sobre la infraestructura de validadores destacan la necesidad de vigilancia continua
Los certificados de octubre de 2026 llegaron en un contexto de otra atención relacionada con la seguridad de los validadores. Divulgaciones anteriores que involucraban la infraestructura de servicios de staking y el manejo de destinatarios de comisiones ya habían provocado salidas voluntarias a gran escala y un mayor monitoreo de los flujos de recompensas. Por separado, los desarrolladores abordaron un problema de enrutamiento de depósitos en las reglas preliminares para la próxima actualización Glamsterdam, que podría haber asignado incorrectamente depósitos de staking bajo ciertas colisiones de claves públicas; esa corrección se integró en las especificaciones de consenso tras una revisión adicional. Estos eventos simultáneos ilustran que la economía de los validadores y la seguridad operacional siguen siendo áreas activas de escrutinio, incluso mientras el protocolo principal continúa evolucionando.
La falla en el certificado difería en su origen; provenía de una CA externa, no de un error en la especificación de Ethereum o en el consenso del cliente, pero afectó la misma superficie económica: el destino de las tarifas y recompensas ganadas por los propuestos. La rápida respuesta del cliente encaja, por lo tanto, en un patrón más amplio de tratar cualquier ruta realista para desviar recompensas como una prioridad alta. Los operadores que mantienen configuraciones de clientes diversificadas, monitorean las direcciones de destinatarios de tarifas en la cadena y mantienen actualizados tanto el software de consenso como el de ejecución están mejor posicionados para absorber tales impactos externos. La ausencia de pérdidas en el caso de eMudhra refuerza que la aplicación oportuna de parches y la disciplina en la configuración siguen siendo defensas efectivas.
Qué necesitan hacer los operadores de nodos de ethereum después de los lanzamientos de octubre
Los validadores y operadores de nodos deben confirmar que están ejecutando Teku 26.10.3 o posterior y Besu 26.10.2 o posterior al usar Docker, o el entorno de ejecución de Java correspondiente con parches al usar archivos binarios. Las configuraciones deben revisarse para identificar cualquier punto final HTTPS; cuando tales puntos finales sean necesarios, el TLS mutuo o el pinning de certificados proporcionan protección adicional. Los operadores que aún usan Java 26 deben migrar a una versión compatible. La supervisión de bloques propuestos en busca de direcciones de destinatarios de tarifas inesperadas sigue siendo un método de detección de bajo costo incluso después de las actualizaciones del almacén de confianza. Debido a que las claves subyacentes fueron recuperables durante un período prolongado antes del descubrimiento, una auditoría única de conexiones históricas y registros de aceptación de certificados puede proporcionar una garantía adicional, aunque no se ha informado ningún aprovechamiento.
Estos pasos son incrementales más que transformacionales para la mayoría de los operadores. La mayoría de los validadores del mainnet nunca contactaron las cadenas de certificados vulnerables y, por lo tanto, experimentan el incidente solo como un recordatorio para mantener actualizadas las imágenes de contenedores y los entornos de ejecución de Java. Para aquellos que sí dependen de servicios externos, los parches cierran una ruta específica y previamente subestimada. Mantener la conciencia sobre los avisos de certificados y entornos de ejecución de fuentes externas reducirá la probabilidad de que fallos externos similares creen ventanas comparables en el futuro. La acción coordinada de los equipos de Teku y Besu proporciona tanto la solución inmediata como un modelo para manejar el próximo incidente criptográfico externo que intersecte con el software de clientes de ethereum.
Preguntas frecuentes
¿Qué estaba exactamente mal con los certificados de eMudhra?
Ocho autoridades de certificación intermedias operadas por eMudhra tuvieron claves privadas generadas con aleatoriedad insuficiente durante una ceremonia de claves en 2025. Las claves eran recuperables a partir de los certificados públicos, lo que permitía a cualquier persona que las obtuviera emitir certificados fraudulentos que los software seguirían confiando como válidos de parte de esas autoridades. Seis de las intermedias se utilizaron para TLS y dos para firma de código. eMudhra las revocó tras el descubrimiento el 17 de octubre de 2026, y las principales plataformas bloquearon posteriormente el material asociado.
¿Algunos validadores perdieron recompensas de ETH debido a este defecto?
No se ha informado de explotación confirmada ni pérdida de recompensas. Los avisos a los clientes y los informes contemporáneos indican que no se observaron ataques. La combinación de condiciones requeridas, una ejecución de Java sin parchear más una conexión HTTPS activa a un servicio externo vulnerable, limitó la superficie de ataque realista, y la emisión rápida de imágenes de Docker parcheadas redujo aún más la exposición.
¿Se ven afectados los nodos predeterminados de ethereum mainnet?
Las configuraciones predeterminadas de mainnet de Teku que no contienen URLs HTTPS no se ven afectadas y no requieren ninguna acción. El mismo principio se aplica a configuraciones comparables de Besu. La exposición se limita a operadores que configuran deliberadamente puntos finales HTTPS remotos para nodos baliza, firmadores externos, constructores o servicios similares.
¿Por qué los entornos de ejecución de Java siguieron siendo vulnerables después de que se revocaran los certificados?
Java no verifica el estado de revocación del certificado por defecto. Incluso después de que los certificados intermedios fueran revocados y bloqueados por navegadores y sistemas operativos, cualquier instalación de Java que aún contuviera las raíces correspondientes en su almacén de confianza continuó aceptando certificados que encadenaban a ellos. Por lo tanto, las imágenes de Docker con entornos de ejecución más antiguos necesitaban eliminaciones explícitas de las raíces.
¿Qué deben hacer los operadores que utilizan imágenes de Docker?
Obtenga y ejecute la versión 26.10.3 o posterior de Teku y la versión 26.10.2 o posterior de Besu. Estas imágenes ya no confían en las raíces comprometidas. Actualizar solo el sistema host no actualiza el entorno de ejecución dentro de un contenedor existente; se requiere una imagen nueva.
¿Qué pasa con los operadores que ejecutan los clientes como binarios independientes?
Esos operadores deben actualizar o volver a configurar la instalación de Java del host para que incorpore las correcciones de OpenJDK, eliminando las raíces afectadas. Java 26 ha alcanzado el fin de su vida útil y no recibirá una compilación corregida; se recomienda la migración a Java 25. Las actualizaciones del software cliente en sí mismas no modifican el almacén de confianza del host.
Descargo de responsabilidad: Esta información general del mercado, posiblemente proveniente de fuentes de terceros, comerciales o patrocinadas, se proporciona únicamente con fines de referencia y educativos y no constituye asesoramiento financiero ni de inversión, una oferta, solicitud o garantía. Renunciamos a toda responsabilidad por su precisión, integridad, confiabilidad y cualquier pérdida resultante. Las inversiones/opciones de trading son arriesgadas; el rendimiento pasado no garantiza resultados futuros. Los usuarios deben investigar, juzgar con prudencia y asumir toda la responsabilidad. Para más detalles, consulte las Condiciones de uso y Divulgación de riesgos de KuCoin.
Aviso: Esta página fue traducida utilizando tecnología de IA para tu conveniencia. Para obtener la información más precisa, consulta la versión original en inglés.