LayerZero Publica Informe del Incidente rsETH: Reconstrucción de Infraestructura Afectada y Elevación del Nivel de Seguridad Cross-Chain
LayerZero Publica Informe del Incidente rsETH: Reconstrucción de Infraestructura Afectada y Elevación del Nivel de Seguridad Cross-Chain
La interoperabilidad entre blockchains se ha convertido en un componente fundamental de DeFi en 2025-2026: los tokens de restaking líquido, los mercados de préstamos multichain y los estándares de emisión omnichain asumen que los activos pueden moverse de forma segura entre redes. Pero el incidente rsETH es un recordatorio de que la seguridad de los puentes no se trata solo de contratos inteligentes, sino también de verificación off-chain, integridad de la infraestructura y elecciones de configuración.
Tras el exploit de KelpDAO rsETH (18 de abril de 2026), LayerZero publicó un detallado informe del incidente y una actualización posterior explicando cómo se aceptó finalmente un mensaje cross-chain forjado bajo una configuración de verificador único, y qué cambios operativos y de política está implementando. Puede leer los informes originales aquí: Declaración del Incidente de KelpDAO y Actualización de LayerZero.
Qué sucedió (y qué no sucedió)
El impacto: puente rsETH drenado mediante un mensaje forjado
El 18 de abril de 2026, un atacante provocó que la ruta del puente rsETH de KelpDAO basada en LayerZero liberara aproximadamente 116.500 rsETH (alrededor de 292 millones de dólares en ese momento), logrando que un mensaje cross-chain forjado fuera verificado y ejecutado en Ethereum. LayerZero enfatizó que esto fue aislado a la configuración rsETH de KelpDAO y que el protocolo LayerZero en sí mismo no fue explotado. Consulte el resumen de LayerZero en la declaración del incidente.
Atribución: "TraderTraitor" vinculado a la RPDC
LayerZero declaró tener una confianza preliminar en que el atacante era un actor estatal altamente sofisticado, atribuyendo el incidente al Grupo Lazarus de la RPDC, específicamente al clúster TraderTraitor referenciado por las autoridades estadounidenses. Para obtener información de fondo sobre las tácticas de "TraderTraitor" (ingeniería social, entrega de malware y ataques a organizaciones de criptomonedas), consulte el aviso conjunto de EE. UU.: Aviso de TraderTraitor de CISA (AA22-108A).
Qué no se vio comprometido (según LayerZero)
La declaración del incidente de LayerZero señala explícitamente que el ataque no fue el resultado de un error en el protocolo LayerZero, y afirma que las claves de firma DVN no fueron robadas directamente. En cambio, el atacante se dirigió a las dependencias de datos del DVN (RPC) y a las suposiciones de disponibilidad circundantes. Los detalles se encuentran en la declaración del incidente.
El modo de fallo principal: "verificador único" se encuentra con envenenamiento de RPC + failover forzado
La explicación de LayerZero se centra en una creciente clase de ataques: envenenamiento de RPC (alimentar a un verificador con estado de cadena manipulado) combinado con DoS / DDoS (forzar al sistema a depender de las fuentes envenenadas).
1) Los nodos RPC descendentes fueron comprometidos y mintieron selectivamente
Según LayerZero, el atacante obtuvo acceso a la lista de nodos RPC utilizada por el DVN de LayerZero Labs, comprometió un subconjunto y modificó el comportamiento de los nodos para que el DVN recibiera un estado de cadena falsificado, mientras que muchos sistemas de monitoreo continuaron viendo respuestas "normales". LayerZero describe este engaño selectivo en su declaración del incidente.
Si desea una introducción práctica sobre por qué los puntos finales de RPC son una superficie de ataque de alto apalancamiento para los sistemas de criptomonedas, la descripción general de Chainstack es una referencia útil: Ataques de envenenamiento de RPC en criptomonedas. Para una definición general de RPC en sistemas distribuidos, consulte la descripción general de IBM: Llamada a Procedimiento Remoto (RPC).
2) Se atacó la disponibilidad de RPC externos para activar la dependencia de nodos comprometidos
LayerZero informa que la actividad DDoS contra puntos finales de RPC externos saludables empujó el comportamiento de respaldo del DVN hacia los puntos finales envenenados, permitiendo la verificación de un mensaje vinculado a transacciones que nunca ocurrieron como se afirmaba. Esta "presión de disponibilidad" es una lección crucial para cualquiera que construya sistemas de verificación off-chain: la redundancia no se trata solo de tener más puntos finales; se trata de sobrevivir a interrupciones dirigidas sin confiar en los equivocados.
3) La configuración DVN 1 de 1 de KelpDAO convirtió el compromiso en pérdida
El detalle de configuración más importante: la ruta rsETH de KelpDAO utilizó una configuración DVN de 1 de 1, con LayerZero Labs actuando como el único verificador. LayerZero argumenta que esto creó un único punto de fallo: no existía ningún verificador independiente que pudiera rechazar el mensaje forjado. Esto se discute directamente en la declaración del incidente.
Un análisis en profundidad de terceros que capta el ángulo de "por qué esto importó para el riesgo de DeFi" es el informe de investigación de Galaxy: Análisis del exploit de KelpDAO / LayerZero.
Por qué este incidente importa más allá de un solo puente
La realidad 2025-2026: los "exploits de infraestructura" están escalando más rápido que los exploits de contratos
Las conversaciones sobre seguridad en DeFi todavía se centran demasiado en auditorías y errores on-chain. Sin embargo, muchos de los incidentes más grandes ahora se parecen a intrusiones empresariales: compromiso de puntos finales, manipulación de la cadena de suministro, secuestro de sesiones y ataques de disponibilidad, seguidos de extracción on-chain.
En el caso rsETH, los contratos on-chain se comportaron según lo diseñado; las entradas al proceso de verificación fueron envenenadas.
La composabilidad de DeFi convirtió un drenaje de puente en un shock de liquidez
Una preocupación importante y posterior fue cómo el colateral sin respaldo o comprometido se propaga a los mercados de préstamos. El análisis posterior al incidente destacó la rapidez con la que los shocks de confianza pueden agotar la liquidez, incluso cuando el código central del protocolo de préstamos funciona según lo previsto. El informe de Glassnode ofrece una perspectiva de la estructura del mercado: Anatomía de una Congelación de Liquidez.
Respuesta de LayerZero: cambios de política, endurecimiento de la configuración y cambios en DVN
Las publicaciones de LayerZero describen tres direcciones prácticas:
1) "No más 1 de 1" para el DVN de LayerZero Labs
LayerZero declara que no firmará/certificará mensajes para aplicaciones que utilicen una configuración DVN de 1 de 1, y que se está poniendo en contacto con proyectos que todavía operan con configuraciones de verificador único. Esto se detalla en la declaración del incidente y se refuerza en la Actualización de LayerZero.
2) Elevar el nivel de referencia predeterminado, pero presionar a los equipos para que fijen las configuraciones
En su actualización del 8 de mayo, LayerZero recomienda a los desarrolladores:
- Fijar configuraciones (no depender de valores predeterminados mutables)
- Utilizar mayores confirmaciones de bloques apropiadas para la cadena
- Adoptar redundancia multi-DVN (al menos 2, idealmente 3-5)
Estas recomendaciones se enumeran en la Actualización de LayerZero. Para los implementadores, LayerZero también hace referencia a una lista de verificación de integración en su documentación: Lista de verificación de integraciones de LayerZero.
3) Reconstruir y reemplazar componentes RPC afectados
LayerZero declara que los nodos RPC afectados fueron descontinuados y reemplazados, y las operaciones de DVN se reanudaron con cambios en el quórum de RPC y las suposiciones de redundancia (detalles en la declaración del incidente y la actualización).
Si bien la arquitectura de seguridad interna de cada equipo difiere, la dirección se alinea con un pensamiento más amplio al estilo "confianza cero": minimizar los privilegios permanentes, segmentar los sistemas de producción y tratar las redes internas como hostiles por defecto, especialmente cuando su sistema actúa como verificador de valor externo.
Conclusiones prácticas para desarrolladores: una lista de verificación de 2026 para la seguridad de puentes cross-chain
Si lanza o integra un activo omnichain (envoltorios tipo OFT, puentes canónicos, derivados de restaking), el incidente rsETH sugiere un orden de prioridad claro:
-
Eliminar la verificación unilateral
- Requerir N de M verificadores independientes (no "dos marcas en la misma pila").
- La independencia debe incluir: organización operadora, alojamiento, fuentes RPC, monitoreo y respuesta a incidentes.
-
Fortalecer la confianza en RPC y la lógica de failover
- Tratar los puntos finales RPC como entradas no confiables.
- Asegurar que el failover no reduzca silenciosamente la seguridad (por ejemplo, "si los puntos finales fallan, confiar en menos puntos finales" es peligroso).
- Construir comportamiento de "modo degradado": detener la verificación en lugar de aceptar pruebas más débiles bajo presión.
-
Diseñar para la disponibilidad adversarial
- Asumir que el DDoS dirigido es parte de la cadena de ataque.
- Modelar qué sucede cuando solo el subconjunto controlado por el atacante permanece accesible.
-
Hacer observable la postura de seguridad
- Publicar sus suposiciones de verificación en un panel o documentación:
- Conjunto DVN, umbrales, confirmaciones, claves de pausa, procedimientos de emergencia
- Los usuarios y los equipos de riesgo necesitan ver el riesgo de configuración antes de un incidente.
- Publicar sus suposiciones de verificación en un panel o documentación:
Conclusiones prácticas para usuarios: cómo reducir la exposición al riesgo cross-chain
Incluso si nunca escribe una línea de código, puede reducir materialmente el riesgo:
- Tratar los activos puenteados como una clase de riesgo separada de los activos "nativos".
- Cuando el rendimiento parezca similar entre cadenas, prefiera lugares donde el colateral dependa de menos suposiciones off-chain.
- Mantener solo saldos operativos en representaciones L2 / puenteadas; almacenar tenencias a largo plazo en almacenamiento en frío.
La autocustodia importa: por qué una billetera de hardware sigue siendo un control central
Incidentes como el de rsETH tratan sobre verificación e infraestructura, pero muchas grandes pérdidas aún comienzan con dispositivos comprometidos, robo de credenciales y ingeniería social. Una billetera de hardware reduce el radio de explosión al mantener las claves privadas aisladas de la navegación diaria y del malware de la estación de trabajo.
Si se toma en serio la autocustodia a largo plazo, usar una billetera de hardware como OneKey ayuda a garantizar que la firma de transacciones permanezca fuera de su entorno conectado a Internet, una capa importante cuando el ecosistema en general se enfrenta a modelos de amenaza cada vez más profesionales y vinculados a estados.
Pensamiento final: "las configuraciones son seguridad"
Es probable que el exploit de rsETH se recuerde menos como "un hackeo de puente" y más como una lección sistémica: la seguridad del protocolo es modular ahora, y el módulo más débil (a menudo la configuración + la infraestructura) define el riesgo real.
A medida que la mensajería cross-chain se convierte en la tubería predeterminada para DeFi y los activos tokenizados, el nivel de referencia de la industria debe pasar de "código auditado" a suposiciones auditadas, incluyendo la diversidad de DVN, la integridad de RPC y la seguridad del failover.
