#DeFi4月安全事件损失超6亿美元 #Gate广场五月交易分享 El puente entre cadenas no es un "puente de seguridad"｜Análisis de los recientes incidentes de ataque y las vulnerabilidades de seguridad en DeFi

En abril de 2026, dos ataques a puentes entre cadenas ocurrieron consecutivamente, sacudiendo nuevamente el mundo de DeFi.
Primero, el 18 de abril, KelpDAO fue víctima de un ataque debido a una configuración defectuosa en la verificación entre cadenas, donde un hacker falsificó mensajes y robó aproximadamente 293 millones de dólares; seguido, el 29 de abril, el puente entre cadenas de Syndicate Commons sufrió una caída en el valor de sus tokens de casi un 35% debido a la falta de verificación de mensajes.
Los atacantes no tocaron el código central del contrato inteligente, sino que aprovecharon la "zona ciega de confianza" en el diseño del puente entre cadenas: falsificaron un mensaje, y el sistema lo aceptó sin cuestionar.
Estos dos incidentes vuelven a exponer un problema clave: los puentes entre cadenas están convirtiéndose en uno de los "puntos débiles más grandes en la seguridad de la cadena de bloques".
Para los usuarios comunes y los proyectos, la advertencia que suenan estos incidentes es: el modelo de confianza subyacente en los puentes entre cadenas está siendo desafiado sistemáticamente. Este artículo, partiendo de la naturaleza del riesgo, ofrece recomendaciones prácticas de protección.
一 ¿Por qué los puentes entre cadenas son propensos a "fallar"?
Los frecuentes incidentes en los puentes entre cadenas se deben a varias deficiencias de diseño comunes:
1 Mecanismo de verificación demasiado simple
Solo requiere la confirmación de un nodo, si ese nodo es comprometido, puede falsificar instrucciones. Este modo de "confianza en un solo punto" en un mundo descentralizado equivale a no tener protección.
2 Falta de conciliación bidireccional
Lo que sucede en la cadena fuente no puede ser reconocido en la cadena destino, permitiendo que los mensajes falsificados pasen sin obstáculos. Es como un banco que solo mira tu cheque, pero no verifica el saldo de la cuenta por teléfono.
3 Concentración excesiva de permisos
Los pools de fondos grandes sin límites, retrasos o protección de múltiples firmas, pueden ser transferidos en su totalidad con una sola brecha. Es como tener la llave de la caja fuerte solo en manos de una persona, y si la pierde, todo se acaba.
4 Auditoría insuficiente
Muchas vulnerabilidades solo se descubren meses después de su operación, dejando ventanas de ataque abiertas por mucho tiempo. La auditoría previa al lanzamiento no garantiza seguridad eterna; nuevas técnicas siempre aparecen después de la auditoría.
Estos dos incidentes, en esencia, se deben a "confiar en un solo eslabón en el que no se debería confiar".
二 Tipos comunes de riesgos en los puentes entre cadenas
Cada etapa del puente entre cadenas puede convertirse en un punto de entrada, por lo que se debe mantener la vigilancia.
1 Vulnerabilidades en el mecanismo de verificación
La verificación de un solo punto es fácil de vulnerar, permitiendo que los mensajes falsificados pasen. Si un hacker controla el nodo de verificación, tiene en sus manos el "botón de aprobación" de todos los activos en la cadena cruzada.
2 Defectos en la lógica del contrato
Como omisiones en la verificación de permisos, vulnerabilidades de reentrada, etc. Estos pequeños descuidos en el código suelen convertirse en "puertas traseras" explotables repetidamente.
3 Riesgo de nodos centralizados
Si los servidores, API o claves son comprometidos, el sistema se descontrola. Los componentes centralizados en los puentes entre cadenas son precisamente los puntos favoritos de los hackers de nivel estatal.
4 Problemas de confiabilidad de los datos
Los datos externos pueden ser secuestrados o manipulados, causando ejecuciones incorrectas. La contaminación de oráculos o fuentes de datos fuera de la cadena puede hacer que el puente funcione en la dirección equivocada.
5 Concentración de fondos en pools
Sin controles, los grandes activos pueden perderse rápidamente tras una brecha. Acumular todos los fondos de los usuarios en un solo pool equivale a preparar una "red de captura total" para los hackers.
Los usuarios no necesitan memorizar todos los detalles técnicos, solo deben saber: cada paso en el puente entre cadenas puede tener problemas.
三 ¿Cómo pueden protegerse los usuarios comunes?
La parte más importante — muchas pérdidas son en realidad problemas de hábitos operativos.
✅ Reducir al máximo la frecuencia de operaciones entre cadenas
Cada operación entre cadenas implica entregar activos a un tercero, y cualquier fallo en ese proceso puede causar pérdidas.
💡 Recomendaciones:
En escenarios no necesarios, evitar transferencias frecuentes o múltiples entre cadenas.
Priorizar puentes entre cadenas establecidos y confiables, evitar herramientas poco conocidas o de nicho.
Principio clave: Cuantas más veces se use el puente, mayor será el riesgo de exposición.
✅ No usar puentes entre cadenas "recién lanzados"
Muchos puentes en su lanzamiento:
Código sin suficiente validación práctica
Auditorías potencialmente incompletas, mecanismos de control aún por perfeccionar, justo en ese período los hackers aprovechan para atacar.
💡 Recomendaciones:
Evitar proyectos nuevos que acaben de lanzarse o que tengan mucha publicidad.
Observar durante un tiempo para detectar anomalías o incidentes de seguridad.
👉 Recuerda: más nuevo no significa más seguro, en muchas ocasiones implica mayor riesgo.
✅ Realizar pruebas con pequeñas cantidades antes de operaciones grandes
Muchos usuarios transfieren grandes sumas de una sola vez, lo cual es muy arriesgado. Se recomienda hacer primero una transferencia pequeña para verificar el proceso completo y confirmar que llega correctamente, antes de realizar operaciones mayores. Así, si surge un problema, las pérdidas serán controladas.
👉 La finalidad de esto es: incluso si hay un problema, las pérdidas serán controlables, no una "explosión de una sola vez".
✅ Ser cauteloso con las autorizaciones (Approve) y firmas
El proceso de operación en el puente entre cadenas casi siempre requiere autorización del contrato de la wallet, y esa autorización es la principal vía por la cual se roban activos de los usuarios.
⚠️ Puntos clave de riesgo:
Autorización ilimitada en contratos: permite transferir sin restricciones todos los activos correspondientes en tu wallet.
Autorizar sin cuidado a contratos desconocidos, lo que facilita ataques de phishing y robo de fondos.
💡 Recomendaciones de protección:
Revocar autorizaciones inmediatamente después de completar la operación.
No confirmar firmas desconocidas sin verificar la dirección y permisos antes.
✅ Gestionar los activos en diferentes wallets para evitar pérdidas totales en una sola operación
Muchos usuarios concentran todos sus activos en una sola wallet, y si esa wallet sufre un riesgo (uso indebido de autorizaciones, filtración de claves privadas, etc.), perderán todo.
👉 Prácticas más seguras:
Wallet principal: solo para almacenar grandes cantidades de activos (sin interactuar).
Wallet de operaciones: para DeFi, operaciones entre cadenas, etc.
Wallet separado para operaciones de alto riesgo.
📌 Efecto protector: incluso si la wallet de operaciones sufre un ataque o robo, los activos principales no se verán afectados, evitando una pérdida total.
四 Problemas de seguridad que los proyectos deben priorizar
Si los usuarios pueden reducir riesgos, los proyectos deben evitar accidentes.
1 Verificación descentralizada  Consenso de múltiples nodos, evitar fallos en un solo punto. Al menos 3 nodos independientes, sin compartir infraestructura.
2 Mínimo de permisos + bloqueo temporal Dividir permisos administrativos, implementar retrasos en operaciones críticas (como 24 horas). Así, incluso si los permisos son robados, el equipo y los usuarios tienen tiempo para reaccionar.
3 Auditoría y monitoreo continuos La auditoría previa al lanzamiento es solo el comienzo, se requiere monitoreo 24/7 para detectar transacciones anómalas. La mayoría de los ataques ocurren después de la auditoría, la protección dinámica es más importante que una revisión única.
4 Aislamiento de fondos No mantener todos los activos en un solo pool, gestionar en capas. Separar fondos propios del protocolo, colaterales de usuarios y tarifas de la plataforma, para que un problema en un pool no afecte a todos.
Conclusión
Las incidencias de KelpDAO y Syndicate Commons demuestran una vez más: los puentes entre cadenas no son "componentes funcionales", sino "infraestructura de alto riesgo".
Desde vulnerabilidades en la verificación hasta pérdida de permisos, cada etapa puede ser un punto de ataque. Aunque los métodos difieren, la esencia es la misma: confiar en un solo supuesto de confianza demasiado simplificado.
Para los usuarios: reducir el uso de puentes, ser cauteloso con las autorizaciones y diversificar los activos son las medidas de protección más efectivas.
Para la industria: la verificación descentralizada, el control de permisos y la transparencia son las claves para la seguridad en los puentes entre cadenas.