Por qué vuelven a hackear los puentes de criptomonedas en 2026: claves de validadores, mensajes falsificados y tokens wrapped sin respaldo
Los puentes entre cadenas resuelven un problema básico de las criptomonedas: los activos y la información creados en una blockchain normalmente no pueden trasladarse directamente a otra. Un puente crea una conexión bloqueando, liberando, acuñando o quemando activos de acuerdo con mensajes recibidos desde otra red. Esa comodidad también genera un riesgo de seguridad concentrado. Un atacante no siempre necesita vulnerar Ethereum, Arbitrum, una cadena del ecosistema Cosmos u otra blockchain subyacente. Puede bastar con comprometer el sistema más pequeño que informa al puente de lo ocurrido en otra red. Los incidentes registrados durante 2026 muestran que el punto más débil puede ser una clave de validador, un servicio off-chain que prepara mensajes, un componente de verificación de pruebas o un contrato que acuña activos wrapped. El resultado suele ser el mismo: el puente acepta un evento que nunca debería haberse autorizado y libera valor real a cambio. Los casos recientes relacionados con AFX Trade, Alephium, Hyperbridge y la conexión de Axelar con Secret Network muestran por qué la seguridad de los puentes sigue dependiendo tanto de los controles operativos y de la validación de mensajes como del propio código de los contratos inteligentes.
Por qué los puentes entre cadenas siguen siendo un objetivo de alto valor en 2026
Un puente actúa, en la práctica, entre sistemas contables separados. Si un usuario envía un activo desde la Cadena A a la Cadena B, el activo original puede quedar bloqueado en un contrato de la Cadena A mientras se emite una representación correspondiente en la Cadena B. Cuando el usuario regresa, la versión wrapped se destruye y el activo original se libera. Otros diseños utilizan fondos de liquidez, emisión nativa o sistemas de mensajería especializados, pero todos deben responder a la misma pregunta: ¿cómo puede una blockchain aceptar de forma segura información sobre un evento ocurrido en otra red? Las blockchains son eficaces verificando su propio estado. No saben automáticamente si un depósito, una quema o una retirada se produjo realmente en otra red.
Esto hace que los puentes resulten especialmente atractivos para los atacantes, porque un único fallo puede dar acceso a reservas comunes en lugar de limitarse al monedero de un solo usuario. Un puente puede custodiar stablecoins, Ether, activos respaldados por Bitcoin y otros tokens en nombre de miles de usuarios. Por eso, el valor concentrado en custodia puede ser muy superior al valor económico que protege a un validador, un servidor o una clave administrativa individual. Incluso cuando los contratos inteligentes han sido auditados, un atacante puede buscar debilidades fuera del propio contrato: infraestructura de validadores, sistemas de despliegue, conexiones RPC, relayers, permisos de actualización, cuentas en la nube o el software utilizado para construir mensajes entre cadenas.
Este patrón siguió siendo visible durante 2026. El 22 de julio, el puente propio de AFX Trade perdió aproximadamente 24,15 millones de dólares en USDC después de que se comprometieran suficientes claves de firma de validadores como para alcanzar el umbral necesario para aprobar una retirada. El 27 de agosto, SKALE informó de que proveedores de infraestructura que operaban nodos validadores habían sido comprometidos antes de un ataque contra su IMA Bridge en Ethereum. Estos incidentes no exigieron derrotar el mecanismo de consenso de las blockchains subyacentes. Los atacantes se dirigieron contra los sistemas de confianza más pequeños situados entre cadenas, donde el control de un número limitado de máquinas o credenciales podía convertirse en autoridad sobre reservas mucho mayores.
El problema de confianza detrás de las transferencias entre cadenas
La palabra “puente” puede hacer que las transferencias entre cadenas parezcan un simple movimiento de una red a otra, pero los activos normalmente no viajan entre blockchains en sentido literal. En su lugar, un sistema demuestra o certifica que algo ocurrió en la cadena de origen y otro sistema modifica los saldos en la cadena de destino en respuesta. Dependiendo del diseño, esa prueba puede proceder de un grupo de validadores, un conjunto de guardians, un mecanismo de cliente ligero, una prueba criptográfica u otro proceso de verificación. Por tanto, los usuarios dependen no solo de la seguridad de ambas blockchains, sino también de la integridad del mecanismo que las conecta.
Esta diferencia es importante porque una transacción puede ser criptográficamente válida y, aun así, ser económicamente fraudulenta. Supongamos que un puente requiere cinco firmas autorizadas antes de liberar USDC. Si un atacante obtiene cinco claves de firma legítimas, la retirada final puede contener firmas perfectamente válidas. El contrato no tiene una forma independiente de comprender que esas firmas fueron generadas por un atacante. Desde su punto de vista, los validadores exigidos aprobaron la solicitud. La criptografía funciona exactamente como estaba previsto, pero la suposición de seguridad que sustentaba esas firmas ya ha fallado.
Un problema similar aparece cuando firmantes legítimos reciben información incorrecta. Los validadores pueden firmar honestamente un mensaje porque la infraestructura que les proporciona los datos informa de un depósito o una quema que nunca ocurrieron. Esta es una de las razones por las que la seguridad de un puente no puede reducirse a una pregunta sencilla sobre si se robaron claves privadas. Los desarrolladores también deben considerar de dónde obtienen los datos los validadores, si varias fuentes independientes confirman el mismo evento, cómo se detectan los mensajes anómalos y qué sucede cuando aparece de repente una retirada de gran tamaño. El puente solo es tan fiable como toda la ruta que lleva desde el evento original en la blockchain hasta la liberación final de los fondos.
Claves de validadores y mensajes falsificados: cómo los ataques eluden las comprobaciones habituales
Las claves de validadores son especialmente peligrosas cuando varias de ellas se almacenan en entornos similares o están controladas por una misma organización. Un diseño de firma por umbral puede parecer descentralizado porque exige cinco, siete o diez firmas, pero la protección real depende de si esas credenciales pueden fallar de forma verdaderamente independiente. Si varias claves están alojadas en servidores activos similares, comparten las mismas herramientas de administración o pueden alcanzarse a través de una única red interna, comprometer un solo entorno operativo puede proporcionar al atacante suficientes firmas para alcanzar el quórum exigido. El número de claves importa mucho menos cuando todas están expuestas a la misma vía de ataque.
El incidente de AFX Trade en julio de 2026 muestra este problema con claridad. Los análisis de seguridad sobre el caso determinaron que cinco firmas de validadores activos eran suficientes para aprobar una retirada de aproximadamente 24,15 millones de USDC. El contrato del puente reconoció el quórum requerido y procesó la solicitud después de su periodo de disputa. El puente nativo de Arbitrum no fue el componente que falló; el afectado era un puente operado por AFX. Esta distinción es importante porque los usuarios suelen ver activos moviéndose entre dos cadenas conocidas y suponer que la seguridad de la transferencia procede directamente de esas cadenas. En realidad, un puente independiente puede introducir su propio conjunto de validadores, sus propias reglas de custodia y sus propias debilidades administrativas.
El robo de claves es solo una de las vías para obtener un mensaje que parezca válido. También es posible engañar a un puente para que acepte información falsa sin robar ninguna clave privada de los firmantes. Un atacante puede manipular los datos enviados a los validadores, aprovechar un error de verificación, crear una prueba que un contrato acepte de forma incorrecta o aprovechar una diferencia entre la forma en que dos componentes de software interpretan una misma transacción. Estos ataques son especialmente difíciles de diagnosticar con rapidez porque el mensaje final puede contener firmas auténticas o superar las funciones de verificación previstas. Los investigadores deben entonces reconstruir el proceso a través de relayers, datos RPC, generación de pruebas y construcción de mensajes para determinar dónde entró por primera vez el estado falso.
Qué muestran los incidentes de 2026
El incidente del puente de Alephium del 30 de mayo de 2026 es un ejemplo útil porque la primera impresión del ataque podría haber llevado a los investigadores a pensar en el robo de credenciales de los guardians. Posteriormente, Alephium declaró que las claves de los guardians no habían sido comprometidas. Según su informe posterior al incidente, el atacante combinó una validación ausente en una ruta off-chain de nueva observación con un ataque de tipo eclipse contra nodos completos del puente. Esto provocó que guardians legítimos firmaran mensajes que eran criptográficamente auténticos pero que nunca deberían haberse autorizado. Se retiraron alrededor de 305.000 dólares en colateral de los contratos TokenBridge en Ethereum y BNB Chain, mientras que se acuñaron aproximadamente 13,76 millones de wALPH sin respaldo en Ethereum.
Hyperbridge sufrió un fallo de verificación distinto el 13 de abril de 2026. Su informe posterior al incidente indica que un atacante aprovechó una vulnerabilidad crítica en el verificador Merkle Mountain Range y falsificó una prueba que el sistema aceptó. Después, el atacante pudo drenar el contrato Token Gateway. Este caso no dependió de reunir suficientes claves de validadores robadas. En su lugar, el componente encargado de decidir si una prueba entre cadenas era válida llegó a una conclusión incorrecta. Hyperbridge suspendió el gateway afectado y posteriormente encargó una auditoría independiente del sistema de verificación y liquidación, lo que demuestra por qué las revisiones de seguridad de un puente deben ir más allá de los contratos de tokens más visibles.
Estos casos muestran por qué la expresión “mensaje falsificado” puede abarcar fallos muy diferentes. Un ataque puede implicar claves robadas que firman realmente una retirada maliciosa. Otro puede proporcionar datos falsos a firmantes honestos. Un tercero puede aprovechar un verificador para que se acepte una prueba fabricada sin comprometer a los validadores. Desde la perspectiva del usuario, los tres escenarios pueden terminar con activos desapareciendo de un contrato de reservas. Desde el punto de vista de la seguridad, sin embargo, requieren defensas diferentes. El almacenamiento de claves protegido por hardware no puede corregir un verificador de pruebas defectuoso, mientras que un verificador perfecto no puede proteger un sistema cuyas credenciales administrativas o de validación hayan sido robadas. Por eso, la seguridad efectiva de un puente exige varias capas de control independientes en lugar de un único punto de confianza.
Tokens wrapped sin respaldo y el problema de la liquidez
Los tokens wrapped añaden otra capa de riesgo porque su valor de mercado depende de la suposición de que, en última instancia, pueden canjearse por algo real. Si un wrapped ETH representa un derecho sobre un ETH custodiado en otra red, el sistema solo permanece equilibrado mientras la cantidad emitida coincida con los activos que la respaldan. Cuando una vulnerabilidad en un puente permite a un atacante acuñar tokens wrapped adicionales sin depositar el colateral correspondiente, esos nuevos tokens pueden parecer inicialmente idénticos a las unidades legítimamente respaldadas. Pueden transferirse, intercambiarse o depositarse en otros servicios DeFi antes de que el mercado descubra que el total de derechos emitidos supera las reservas disponibles.
El incidente de junio de 2026 relacionado con la conexión de Axelar con Secret Network ofrece un ejemplo concreto. Los análisis de seguridad concluyeron que un contrato de puente modificado aceptaba depósitos IBC sin validar correctamente el canal de origen esperado. Un atacante podía crear una cadena independiente basada en Cosmos, enviar paquetes de depósito manipulados y provocar la emisión de activos wrapped en Secret Network sin los depósitos legítimos correspondientes. Después, esos activos sin respaldo se enviaban a través de la conexión válida de Axelar y se canjeaban por tokens reales mantenidos en custodia. Se sustrajeron aproximadamente 4,67 millones de dólares y el déficit no se detectó de inmediato; los informes sobre el incidente indican que el problema se hizo evidente días después, cuando una transferencia normal entre cadenas ya no pudo completarse porque las reservas se habían agotado.
Este tipo de ataque resulta especialmente dañino porque puede extenderse más allá del propio puente. Una vez que un activo wrapped sin respaldo entra en un exchange descentralizado, un mercado de préstamos o un fondo de liquidez, otros usuarios pueden intercambiar sin saberlo activos reales por derechos que ya no están totalmente respaldados. Los contratos automatizados normalmente no saben por qué se acuñaron tokens adicionales. Simplemente leen saldos y aplican las reglas programadas. Por eso, un fallo de seguridad en un solo puente puede transferir pérdidas a proveedores de liquidez, traders o servicios DeFi conectados. Para cuando se suspende el puente afectado, el atacante puede haber convertido ya esos derechos falsos en stablecoins u otros activos ampliamente negociados.
Cómo un diseño de puente más seguro reduce el impacto
La primera línea de defensa consiste en reducir la cantidad de autoridad que puede ejercer una sola credencial o un único sistema. Las claves de validadores deben separarse en entornos verdaderamente independientes, y no simplemente representarse mediante direcciones diferentes. Las actualizaciones administrativas pueden protegerse mediante aprobación multifirma, timelocks y permisos estrictamente limitados. Las retiradas grandes o inusuales pueden estar sujetas a periodos de revisión más largos, mientras que los límites de velocidad pueden restringir cuánto valor puede salir de un puente durante un periodo breve. Ninguno de estos controles garantiza que un ataque vaya a evitarse, pero sí puede impedir que una sola cuenta comprometida o un mensaje inesperado vacíen inmediatamente todas las reservas.
La verificación de mensajes también necesita comprobaciones independientes en varias etapas. Un puente debe confirmar la cadena de origen, el contrato, el activo, la cantidad, el destino y la secuencia del mensaje en lugar de tratar una firma válida como prueba de que todos los campos son correctos. Los sistemas que dependen de observadores off-chain deben considerar qué ocurre cuando esos observadores reciben respuestas RPC manipuladas o pierden una visión fiable de la cadena de origen. La oferta de tokens wrapped debería compararse de forma continua con las reservas de respaldo para que un aumento inexplicable active una alerta o una suspensión automática. La supervisión resulta más útil cuando comprueba relaciones económicas fundamentales, como si los derechos emitidos siguen coincidiendo con el colateral disponible, en lugar de limitarse a buscar transacciones fallidas.
La principal lección de 2026 es que los ataques contra puentes ya no pueden explicarse adecuadamente diciendo simplemente que “se hackeó el contrato inteligente”. En varios incidentes importantes, la debilidad decisiva se encontraba en otro lugar: credenciales de validadores, infraestructura que proporcionaba datos a los guardians, validación del canal de origen o verificación de pruebas. Por tanto, un diseño seguro debe asumir que los componentes individuales pueden fallar y evitar que un solo fallo se convierta en un derecho ilimitado sobre las reservas del puente. Los usuarios que evalúan un puente deberían mirar más allá de la velocidad de las transacciones y de las cadenas compatibles y considerar quién controla los firmantes, cómo se verifican los mensajes, si los activos wrapped pueden compararse de forma independiente con las reservas, con qué rapidez puede detenerse una actividad anómala y qué proceso de recuperación existe si esos controles fallan.
