Los 3 principales incidentes de seguridad de mayo
Las pérdidas más significativas de mayo no surgieron de vulnerabilidades en contratos inteligentes, sino de fallos en los límites de confianza, incluyendo compromisos de claves privadas, fallos en la validación entre cadenas y descuidos en la seguridad operativa relacionados con la autoridad de acuñación y la semántica de los puentes.
Este patrón es un recordatorio de que la seguridad en Web3 va mucho más allá del código de los contratos inteligentes. Todo sistema incorpora suposiciones de confianza a lo largo de su ciclo de vida completo. Cuando cualquiera de esas suposiciones se rompe, se convierte en el eslabón más débil, y a menudo en el único que un atacante necesita.
Echo Protocol: ~$76.7M
El 19 de mayo de 2026, el despliegue de eBTC de Echo Protocol en Monad sufrió un importante incidente de seguridad. Basándose en el valor vinculado del eBTC acuñado en el momento del exploit, la pérdida se estimó en aproximadamente $76.7 millones.
La causa raíz fue un compromiso de clave de administrador, en lugar de una vulnerabilidad convencional en la lógica de un contrato inteligente. Tras obtener control privilegiado, el atacante acuñó aproximadamente 1,000 eBTC sin respaldo sin depositar el colateral correspondiente. Dado que eBTC estaba destinado a seguir el valor de BTC, la acuñación no autorizada creó de inmediato una exposición nocional masiva. El atacante luego trasladó parte del suministro falsificado a protocolos posteriores, convirtiendo el incidente en un evento de riesgo entre protocolos.
Este caso pone de relieve que, para los sistemas de activos sintéticos o envueltos, el límite de seguridad clave no es solo la corrección del contrato, sino también si la autoridad de acuñación está excesivamente concentrada en una única clave privilegiada. Una vez que ese ancla de confianza se ve comprometida, el atacante puede eludir por completo el modelo de colateralización previsto.
StablR: ~$12.8M
El 24 de mayo de 2026, el sistema de stablecoin de StablR sufrió una brecha de seguridad que involucró aproximadamente $12.8 millones en emisión no autorizada de tokens.
Según los informes públicos, esto pareció ser principalmente un compromiso de infraestructura o de gestión de claves, en lugar de un exploit convencional de contrato inteligente. El atacante obtuvo control sobre la autoridad de acuñación basada en multisig y luego pudo reemplazar o apropiarse de los roles de propiedad, lo que permitió la acuñación no autorizada de USDR y EURR. Aunque los ingresos realizados por el atacante en la cadena fueron inferiores al valor nocional total de los tokens acuñados ilegítimamente, el incidente igualmente provocó una desvinculación del precio y expuso debilidades en el aislamiento de la autoridad de acuñación, la seguridad de los firmantes y el diseño de la gobernanza multisig.
Para los protocolos de stablecoin, esta clase de incidente es especialmente grave porque el atacante no necesita drenar directamente las reservas del tesoro. Si la acuñación no autorizada es posible, la confianza del mercado en la redimibilidad puede colapsar de inmediato, provocando que la vinculación falle y que la liquidez se deteriore rápidamente.
Verus: ~$11.7M
El 18 de mayo de 2026, el Puente Verus-Ethereum fue explotado por aproximadamente $11.7 millones, afectando a ETH, tBTC y USDC. Al 23 de mayo de 2026, alrededor del 75% de los fondos robados habían sido devueltos.
La causa raíz fue un fallo de validación de tipo en la ruta de importación del lado de Ethereum. El Puente Verus-Ethereum está diseñado para liberar activos en Ethereum tras demostrar que existe un objeto de exportación válido en Verus bajo un estado notarizado. Sin embargo, la lógica vulnerable solo verificaba que existía algún objeto del lado de Verus, y no lograba asegurar que el objeto demostrado fuera realmente una exportación primaria válida destinada al procesamiento de pagos. Como resultado, el atacante pudo fabricar una exportación en blanco en Verus que contenía una salida de exportación suplementaria artesanal, luego demostrar ese objeto en Ethereum y hacer que el puente lo clasificara erróneamente como una exportación normal con valor.
El atacante luego proporcionó serializedTransfers que coincidían con el compromiso de hash de transferencia incorporado, lo que permitió que la importación fraudulenta superara las verificaciones del lado de Ethereum y desencadenara la liberación de activos desde el puente. Este incidente demuestra que la seguridad de los puentes no depende únicamente de la verificación de pruebas criptográficas, sino también de la validación estricta del tipo de objeto, el estado, los indicadores, los límites de codificación y la semántica de ejecución. Si un protocolo solo demuestra que un objeto existe, pero no que es el objeto correcto para la acción prevista, incluso una prueba válida puede ser abusada para autorizar pagos inválidos.
La información anterior se basa en datos al 00:00 UTC del 1 de junio de 2026.
Con esto concluye el resumen de incidentes de seguridad de abril. Para un análisis más profundo de los incidentes de seguridad en blockchain y las tendencias de seguridad en Web3, puede explorar nuestros recursos.
Puede obtener más información en nuestra Biblioteca de Incidentes de Seguridad.
¡Manténgase informado y manténgase seguro!
