Los protocolos de finanzas descentralizadas que contaban con auditorías públicas registraron pérdidas atribuidas de 721,24 millones de dólares en 68 incidentes analizados durante el primer semestre de 2026. En 46 de esos casos, los investigadores concluyeron que la ruta utilizada por el atacante quedaba fuera de todos los alcances de auditoría identificados. Esos ataques concentraron el 94,4% de las pérdidas del grupo.
El análisis procede de un preprint elaborado por investigadores vinculados a la firma de seguridad ack3 y a la Universidad Técnica Checa de Praga. El estudio revisó 135 incidentes comunicados entre el 1 de enero y el 29 de junio, con pérdidas atribuidas por un total de 939,86 millones de dólares. De ellos, 122 fueron clasificados como confirmados y 13 como probables.
Una auditoría no cubre necesariamente todo el sistema
Los autores localizaron auditorías públicas anteriores al incidente en 68 casos. En 20, la vía de ataque estaba dentro de al menos uno de los alcances revisados; en otros dos no pudieron determinarlo. Los 46 incidentes considerados externos al alcance representaron el 67,6% de los casos auditados y pérdidas de 680,97 millones de dólares sobre los 721,24 millones del conjunto.
La cifra está muy condicionada por dos episodios de gran tamaño: Kelp DAO, con 292 millones de dólares, y Drift Protocol, con 285 millones. Al excluirlos, la proporción de pérdidas asociadas a rutas fuera del alcance baja al 72,1%: 103,97 millones de dólares sobre 144,24 millones.
El resultado no mide la eficacia de las auditorías ni demuestra que sus límites provocaran las pérdidas. Tampoco permite concluir que los protocolos auditados sean, en términos generales, más o menos seguros. El estudio no cuenta con un grupo de comparación de sistemas que no sufrieran ataques ni mide cuánto tiempo estuvo expuesto cada proyecto. Además, puede haber auditorías privadas o incidentes no comunicados, y las cifras de pérdidas no son perfectamente comparables.
La conclusión más acotada es que historial de auditoría y alcance de auditoría son variables distintas. La revisión de un contrato inteligente no implica automáticamente que también se hayan examinado sus actualizaciones, claves privilegiadas, interfaz, relés, oráculos, servicios en la nube o procedimientos de respuesta.
El caso de ICON muestra dónde puede romperse la cobertura
El incidente de ICON Network del 27 de agosto ilustra esa diferencia. Según el informe posterior de la fundación, dos partes del proceso de retirada interpretaban de forma distinta el mismo mensaje. Un contrato de migración utilizaba los bits altos del número de serie para decidir si la operación era única, mientras que la firma criptográfica solo cubría los 256 bits inferiores.
El atacante modificó los bits no firmados y volvió a enviar 1.492 veces dos mensajes de retirada legítimamente firmados durante unos 20 minutos. ICON indicó que 1.490 llamadas tuvieron éxito y que se liberaron 119,866 millones de ICX y 531.600 bnUSD. La pérdida neta confirmada se situaba en unos 150,2 ETH más 31.204 USDC en el momento del informe. La fundación afirmó que los depósitos, saldos y posiciones de los usuarios no se vieron afectados.
ICON también señaló que el contrato había sido auditado externamente y que se habían aplicado recomendaciones. Sin embargo, el desajuste concreto entre la comprobación de unicidad y el valor firmado no quedó cubierto por esas revisiones, según el informe posterior. La respuesta operativa añadió otro punto débil: la primera alerta automática llegó unos siete minutos después del inicio del ataque, pero la respuesta completa se retrasó por un sistema de avisos que había generado falsos positivos.
La vigencia de la revisión también importa
El incidente de aelf plantea una cuestión distinta. La empresa describió una intrusión en tiempo de ejecución y una recuperación controlada, pero la información pública disponible no permite vincular el recorrido explotado con una auditoría concreta anterior al ataque.
aelf explicó que un contrato no autorizado podía utilizar parámetros de transacción para introducir ensamblados y órdenes codificadas en la ejecución de los nodos. Identificó 155 transacciones relacionadas y cinco ensamblados, aunque advirtió de que esas capacidades no demostraban que todos hubieran sido ejecutados ni que se hubieran extraído credenciales o datos sensibles.
El caso muestra por qué una certificación genérica puede quedarse atrás respecto al sistema que realmente opera. Para que una auditoría sea útil, el registro debería identificar el repositorio, la versión, las direcciones desplegadas, los componentes excluidos, los privilegios, las dependencias y los cambios posteriores. También debería aclarar cómo funcionan la custodia de claves, la monitorización, los mecanismos de parada y la recuperación de fondos.
