Informe de seguridad de Web3 de agosto: 29 incidentes importantes, más de $68,29 millones perdidos

Según los datos monitoreados por la plataforma Beosin Alert, en agosto de 2026, el monto total perdido por diversos incidentes de seguridad fue de aproximadamente 76,15 millones de dólares, con un total de 『29』 incidentes de seguridad importantes, principalmente debido a vulnerabilidades en contratos. De estos, 18 incidentes fueron causados por vulnerabilidades en contratos o redes, y 2 incidentes se debieron a filtraciones de claves privadas; la seguridad de los contratos inteligentes y la gestión de claves privadas siguen siendo puntos débiles en la seguridad de Web3.

El 13 de agosto, la dirección de usuario individual 0x13e3....179e fue comprometida debido ala filtración de la clave privada y se le robaron activos criptográficos como WBTC, cbBTC, LDO, USDS, CRV, con una pérdida total de aproximadamente 25.6 millones de dólares, el evento de seguridad con la mayor pérdida real. El 30 de agosto,Cronos el protocolo de préstamos Tectonic en la red sufrió un ataque de hacker debido a una vulnerabilidad en el contrato, con una pérdida estimada de aproximadamente 74 millones. Este ataque provocó que la red Cronos implementara medidas de emergencia, suspendiendo la red y revertiendo transacciones; finalmente, el hacker transfirió con éxito aproximadamente 6 millones de dólares a través de transacciones cruzadas a la redEthereum.

Además, la cadena de bloques Harmony sufrió una vulnerabilidad que permitió la acuñación adicional de aproximadamente 4 mil millones de tokens ONE, con una pérdida nominal superior a 4 millones de dólares, pero finalmente se eliminó el estado de los tokens falsificados mediante el rollback de las transacciones, por lo que no se contabilizó como pérdida.

Los objetivos atacados este mes incluyeron cadenas públicas, protocolos de préstamos, aplicaciones de billeteras, contratos de tokens, puentes cruzados y usuarios individuales, entre otros. Los proyectos DeFi sufrieron la mayor pérdida económica, alcanzando los 33,09 millones de dólares; mientras que las direcciones personales perdieron aproximadamente 28,4 millones de dólares debido a fugas de claves privadas o phishing. Los contratos de tokens fueron atacados con mayor frecuencia, con un total de 10 incidentes; los contratos DeFi ocuparon el segundo lugar, con 9 ataques.

La cadena con la mayor cantidad perdida en mayo fue Ethereum, con pérdidas superiores a 48,58 millones de dólares y un total de 15 incidentes de seguridad; actualmente, la mayoría de los protocolos DeFi y los ataques de phishing dirigidos a grandes tenedores siguen centrados en Ethereum. La segunda cadena con más incidentes de seguridad fue BNB Chain, aunque los objetivos principales fueron contratos de tokens, con pérdidas menores. Además, otras cadenas públicas como Cronos, Base, Harmony, Bitcoin y Solana también experimentaron incidentes de seguridad, lo que demuestra una tendencia multiplex de ataques en cadena.

1. Tectonic y Moonwell: manipulación de precios

Tectonic y Moonwell son protocolos de préstamo en cadena, cuyas vulnerabilidades se debieron a la manipulación de los precios de activos con liquidez limitada utilizados como garantía, lo que permitió obtener préstamos excesivos basados en valores de activos inflados. En el ataque a Tectonic, el atacante elevó el precio del token de gobernanza de Tectonic, $TONIC, cien veces, obteniendo un límite de préstamo de aproximadamente 74 millones de dólares, y luego retiró activos como USDT. Tras el incidente, la red Cronos suspendió temporalmente la producción de bloques; antes de la suspensión, el atacante transfirió aproximadamente 6 millones de dólares a Ethereum mediante una puente cruzada. Posteriormente, la red Cronos realizó un rollback para recuperar las pérdidas.

Dirección de beneficio de Ethereum del hacker: 0xc404160B79BD8905061a1cAecBeCa2EEab3f72DD y flujo de fondos robados:

Actualmente, aproximadamente 2659 ETH aún se encuentran almacenados en 0xc4041, tras transferir 140.1 ETH a 0x6df89c42f0abdfaa2b5b77edcdafbc945ed6ee6c, se continuaron enviando a múltiples direcciones recién creadas.

Moonwell sufrió una pérdida de aproximadamente 8.7 millones de dólares debido a que el atacante manipuló el precio del token MAMO con baja liquidez para tomar prestado cbBTC:

Estos dos ataques no se debieron a vulnerabilidades en contratos inteligentes, sino a que el protocolo valuaba los activos garantizadores basándose en liquidez spot débil, calculando incorrectamente el valor de la garantía. Para evitar este tipo de ataques, el protocolo puede obtener datos de múltiples oráculos y realizar evaluaciones adicionales ante fluctuaciones bruscas de precios.

2. Harmony: Ataque de replay

Harmony es una Layer 1 que admite sharding, ejecuta cuatro sharding y transfiere activos entre ellos mediante un mecanismo asíncrono basado en recibos. El sharding de origen genera recibos cifrados para las transacciones salientes, y el sharding de destino es responsable de verificar que el recibo y su prueba Merkle coincidan con el encabezado del bloque de origen firmado antes de registrar la transacción, y cada recibo solo puede usarse una vez.

La vulnerabilidad en este ataque se encuentra en la parte heredada del sistema de sharding de Harmony. Anteriormente, Harmony verificaba si los recibos de sharding ya habían sido utilizados consultando dos campos: CXMerkleProof.ShardID y BlockNum.

Dado que estos dos campos se encuentran fuera del encabezado de bloque firmado, un atacante puede modificarlos sin afectar ninguna función existente. En este ataque, el atacante obtuvo un recibo entre sharding y modificó el ShardID y el BlockNum para que el programa de validación lo reconociera como un recibo completamente nuevo. El shard objetivo aceptó el recibo modificado y lo registró nuevamente, mientras que el shard original no dedujo los activos correspondientes.

Este es un ataque de replay muy típico. Para cualquier campo utilizado como "marca de uso único", debe formar parte del encabezado firmado. Al validar el recibo, se debe leer directamente el ID de fragmento y el número de bloque desde el encabezado de bloque verificado, en lugar de confiar en los campos no verificados de la estructura de prueba.

3. Term Finance: Ataque de gobernanza

Term Finance es un protocolo DeFi de préstamos con tasa fija, cuyo cada tesorería (Vault) es una Vault ERC-4626 basada en el código de Yearn V3. La gobernanza de las tesorerías de Term Finance no es por votación de aprobación, sino por votación de veto. Cuando un curador presenta una propuesta de cambio de parámetros, los gestores abren una ventana para que los titulares de tokens LP presenten objeciones. Sin embargo, existe una vulnerabilidad grave en el umbral establecido para la votación de gobernanza:

● Falta de umbral absoluto de votos o capital: las condiciones para la aprobación de la propuesta, isSupportThresholdReached() e isMinParticipationReached(), solo verifican proporciones relativas, no votos absolutos. Esto significa que, siempre que se cumpla la mayoría relativa, la propuesta se aprueba, independientemente del número total de personas que emitieron esos votos o la cantidad total de capital.

● Baja participación: casi ningún depositante ha convertido sus cuotas de tesorería (tmvETH) en tokens de gobernanza (gtmvETH) para participar en votaciones. Esto ha llevado a una oferta total de tokens de gobernanza de la tesorería relacionada extremadamente baja.

Los atacantes aprovecharon el defecto de diseño mencionado anteriormente para llevar a cabo un ataque de gobernanza sobre la caja fuerte a un costo extremadamente bajo:

(1) Obtener derechos de voto: el atacante intercambió aproximadamente 0.5 ETH por aproximadamente 0.485 participaciones en el tesoro tmvETH y las empaquetó 1:1 como 0.485 tokens de gobernanza gtmvETH para obtener derechos de voto.

(2) Presentar una propuesta maliciosa: al crear la propuesta, el contrato registró que el suministro total de tokens de gobernanza era de solo 0.535 gtmvETH. Esto significa que los 0.485 gtmvETH poseídos por el atacante representaban el 90.66% del total.

(3) Votación y ejecución: El atacante, como único votante, emitió un voto a favor. Al no haber votos en contra, su porcentaje de apoyo superó ampliamente el umbral del 50%; además, su derecho de voto personal superó el umbral mínimo de participación (minVotingPower) calculado sobre la oferta total extremadamente baja.

(4) Retirar activos: tras la aprobación de la propuesta, se llevó a cabo una operación maliciosa para extraer los activos del tesoro (WETH)

Los atacantes utilizaron el mismo método para comprometer 6 bóvedas de Term Finance, causando pérdidas de aproximadamente 8,5 millones de dólares.

Este ataque también es un ataque muy típico a la gobernanza de protocolo en cadena. Para la gobernanza en cadena, los equipos de proyectos deben establecer los siguientes puntos de control para prevenirlo:

● Establecer un número absoluto de votos o un límite de capital: las propuestas de gobernanza no pueden aprobarse únicamente en función de proporciones relativas. Debe establecerse un umbral fijo basado en cantidades absolutas, por ejemplo, requiriendo que los votos a favor alcancen una cantidad específica (como 1 millón de dólares) o un número determinado de direcciones independientes.

● Configure a guardian or veto path for the time lock: Although governance execution typically has a delay, this merely provides a window for response. Project teams must implement an effective guardian mechanism or proposal veto path during the execution delay period. If a malicious proposal is detected within the delay period, the guardian can immediately intervene and cancel it.

● Monitorear la participación en la gobernanza: el protocolo debe establecer un monitoreo en tiempo real de la participación en la gobernanza de cada tesorería. Cuando se detecte un nivel anormalmente bajo en el suministro total de tokens de gobernanza o en la tasa de participación en votaciones de una tesorería, emitir una alerta o activar automáticamente medidas de protección.

Tendencias de amenazas a la seguridad de Web3

La tendencia más profunda presentada por la seguridad de Web3 en 2026 es la expansión sistemática de la superficie de ataque. Las vulnerabilidades están surgiendo simultáneamente en el nivel del código, las operaciones diarias y las interacciones; solo contar con varias auditorías de seguridad o herramientas no cubre la seguridad operativa, la gobernanza en cadena ni las vulnerabilidades en la lógica comercial. Esto plantea nuevos desafíos para que los proyectos de Web3 construyan sistemas de defensa seguros.

Además, los ataques contra contratos DeFi y usuarios individuales son frecuentes. Las vulnerabilidades en los contratos o los permisos otorgados pueden ser fácilmente explotados por atacantes; los desarrolladores u operadores de contratos deben revisar la seguridad de estos, y para aquellos que manejan negocios críticos, se recomienda realizar múltiples auditorías de seguridad por partes distintas. Para los usuarios individuales, es recomendable revisar periódicamente y revocar los permisos otorgados a contratos que ya no se utilizan, mediante exploradores de blockchain o herramientas de revocación de permisos, y familiarizarse con las técnicas de phishing comunes y nuevas para aumentar la conciencia de seguridad.

Este artículo fue elaborado por el equipo de seguridad de Beosin, combinando el sistema de alertas de seguridad Beosin Alert, datos en la cadena y análisis posteriores publicados por el equipo del proyecto. Si tiene alguna pregunta, no dude en comunicarse con nosotros.