{"id":290,"date":"2026-07-25T21:04:58","date_gmt":"2026-07-25T21:04:58","guid":{"rendered":"https:\/\/coincrafty.com\/why-bridges-get-hacked-es-tmp\/"},"modified":"2026-07-30T16:39:37","modified_gmt":"2026-07-30T16:39:37","slug":"why-bridges-get-hacked","status":"publish","type":"post","link":"https:\/\/coincrafty.com\/es\/why-bridges-get-hacked\/","title":{"rendered":"Por qu\u00e9 los puentes cripto no dejan de ser hackeados"},"content":{"rendered":"

La versi\u00f3n r\u00e1pida.<\/strong> Un puente no traslada una moneda de una cadena a otra, porque las cadenas no pueden verse entre s\u00ed. Bloquea o quema tu activo en un lado y emite un derecho en el otro, lo que concentra una enorme cantidad de valor detr\u00e1s de un \u00fanico mecanismo. Los puentes no dejan de ser hackeados porque ese mecanismo es un objetivo permanente, p\u00fablico y de alto valor, con un pu\u00f1ado de formas de fallar bien conocidas.<\/p>\n

Qu\u00e9 hace realmente un puente<\/h2>\n

Las cadenas de bloques son sistemas cerrados. Un contrato en una cadena no puede ver lo que ocurri\u00f3 en otra, as\u00ed que nada viaja literalmente entre ellas. Todo lo que hace un puente<\/a> es un arreglo construido en torno a esa limitaci\u00f3n.<\/p>\n

El dise\u00f1o m\u00e1s habitual es bloquear y acu\u00f1ar. Depositas un activo en un contrato de la cadena de origen, donde queda bloqueado. Algo fuera de la cadena observa ese dep\u00f3sito y da fe de \u00e9l. Un contrato en la cadena de destino acepta ese testimonio y acu\u00f1a una representaci\u00f3n envuelta en tu direcci\u00f3n.<\/p>\n

Volver invierte el flujo: quemas el token envuelto, un testimonio de esa quema llega a la cadena de origen y el activo original se libera. Los puentes de red de liquidez funcionan de otra manera de nuevo, manteniendo fondos comunes a ambos lados y pag\u00e1ndote desde el fondo de destino.<\/p>\n

Lo que conviene retener es qu\u00e9 es un token envuelto. Es un derecho, y su valor depende por completo de que el colateral bloqueado siga bloqueado y de que la autoridad que acu\u00f1a siga siendo honesta y correcta. Si la acu\u00f1aci\u00f3n se puede falsificar, el activo envuelto no est\u00e1 respaldado por nada y el contrato de bloqueo lo vac\u00eda quien redime primero.<\/p>\n

Por qu\u00e9 el valor se concentra tanto<\/h2>\n

Cada usuario que cruza en la misma direcci\u00f3n se suma a la misma pila. Los dep\u00f3sitos se acumulan en un solo contrato, as\u00ed que el saldo simplemente crece con la adopci\u00f3n.<\/p>\n

Eso cambia la econom\u00eda de atacarlo. Contra una cartera individual, un atacante gana una cartera. Contra un puente, una sola llamada con \u00e9xito puede alcanzar todo lo que retiene el mecanismo, lo que financia una enorme cantidad de esfuerzo paciente contra un objetivo que nunca se mueve.<\/p>\n

Los puentes son tambi\u00e9n sistemas inusualmente amplios. Tienen contratos en al menos dos cadenas, una capa de retransmisi\u00f3n o de testimonio fuera de la cadena, material de claves en manos de alguien y, a menudo, una v\u00eda de actualizaci\u00f3n. El atacante solo tiene que acertar en una de esas partes. Los defensores tienen que acertar en todas, de forma permanente.<\/p>\n

Las clases de fallo que se repiten<\/h2>\n

Conjuntos de validadores o firmantes comprometidos<\/h3>\n

Muchos puentes verifican los dep\u00f3sitos de forma externa: un grupo de partes elegidas observa la cadena de origen y firma lo que vio, y el contrato de destino acu\u00f1a cuando ve suficientes firmas. Eso hace que esas claves de firma equivalgan al dinero. Los puentes se han vaciado repetidamente despu\u00e9s de que suficiente material de esas claves cayera en manos de un atacante, ya sea por phishing a un operador, malware en un servidor o alguien desde dentro.<\/p>\n

Los umbrales adornan la realidad cuando las claves no son genuinamente independientes. Un conjunto nominalmente distribuido gestionado por una sola organizaci\u00f3n, en una sola cuenta en la nube, con una sola cadena de despliegue, est\u00e1 m\u00e1s cerca de una \u00fanica clave de lo que sugiere la notaci\u00f3n. La misma l\u00f3gica se aplica a escala personal, como explica nuestra gu\u00eda sobre multifirma para particulares<\/a>.<\/p>\n

Verificaci\u00f3n de mensajes defectuosa<\/h3>\n

El contrato de destino debe decidir si un dep\u00f3sito ocurri\u00f3 de verdad. Esa comprobaci\u00f3n es donde reside la confianza, y es c\u00f3digo sutil. Los fallos de esta clase permiten a un atacante acu\u00f1ar sin haber depositado jam\u00e1s nada, que es la forma m\u00e1s pura de exploit de un puente.<\/p>\n

Las formas recurrentes resultan familiares. Una rutina de verificaci\u00f3n de pruebas que devuelve \u00e9xito en silencio ante una entrada vac\u00eda o malformada. Un analizador que acepta un mensaje de un remitente no autorizado porque la comprobaci\u00f3n del emisor se aplic\u00f3 al campo equivocado.<\/p>\n

Claves de administraci\u00f3n potentes y contratos actualizables<\/h3>\n

La mayor\u00eda de los puentes son actualizables, porque un sistema tan complejo va a necesitar arreglos. El patr\u00f3n de proxy que lo permite tambi\u00e9n significa que una sola direcci\u00f3n con privilegios puede reemplazar la l\u00f3gica que protege cada dep\u00f3sito, al instante y sin el consentimiento de nadie.<\/p>\n

El c\u00f3digo perfecto no protege nada si esa clave est\u00e1 comprometida, y lo mismo vale para los poderes de pausa, acu\u00f1aci\u00f3n y retirada de emergencia. Esta es la brecha que un informe de auditor\u00eda documenta en lugar de eliminar<\/a>, as\u00ed que la secci\u00f3n de roles con privilegios merece m\u00e1s atenci\u00f3n que el recuento de errores.<\/p>\n

Fallos en la verificaci\u00f3n de firmas<\/h3>\n

Incluso con un conjunto de firmantes honesto, el c\u00f3digo que comprueba las firmas puede estar equivocado. Las firmas no ligadas a una cadena o un contrato concretos pueden reproducirse all\u00ed donde nunca se pretendi\u00f3 que se aplicaran. Las funciones de recuperaci\u00f3n que devuelven una direcci\u00f3n vac\u00eda ante una entrada malformada pueden ser enga\u00f1adas para tratar a un firmante inexistente como v\u00e1lido. Un manejo de nonces que permite la reutilizaci\u00f3n convierte una \u00fanica aprobaci\u00f3n leg\u00edtima en muchas.<\/p>\n

Estos fallos son peque\u00f1os, f\u00e1ciles de pasar por alto y catastr\u00f3ficos en su efecto, porque permiten a un atacante fabricar lo \u00fanico de lo que depende todo el sistema.<\/p>\n

Por qu\u00e9 esto sigue siendo dif\u00edcil de arreglar<\/h2>\n

Un puente tiene que ser correcto a trav\u00e9s de dos entornos de ejecuci\u00f3n m\u00e1s la fontaner\u00eda que hay entre medias, y seguir siendo correcto mientras ambas cadenas se actualizan por debajo. La complejidad no es aqu\u00ed accidental; es el trabajo mismo.<\/p>\n

La componibilidad multiplica las consecuencias. Los activos envueltos se usan como colateral y se emparejan en mercados por toda la cadena de destino, as\u00ed que cuando uno pierde su respaldo el da\u00f1o se extiende a fondos que nunca tocaron el puente. Nuestra lecci\u00f3n sobre conceptos b\u00e1sicos y riesgos de DeFi<\/a> aborda ese tipo de efecto en cadena.<\/p>\n

Las herramientas defensivas cortan por los dos lados tambi\u00e9n. Los l\u00edmites de tasa y los interruptores de pausa reducen cu\u00e1nto puede extraer un solo fallo, y le entregan a alguien el poder de congelar tus fondos. Ning\u00fan dise\u00f1o elimina la confianza por completo; los buenos la trasladan a un lugar que puedes inspeccionar.<\/p>\n

Qu\u00e9 significa esto para ti en la pr\u00e1ctica<\/h2>\n

No puedes auditar un puente por ti mismo, pero s\u00ed puedes cambiar cu\u00e1nto expones a \u00e9l y durante cu\u00e1nto tiempo.<\/p>\n