Una revisión de 135 incidentes de seguridad registrados en protocolos de finanzas descentralizadas durante el primer semestre de 2026 concluye que la mayoría de las pérdidas asociadas a proyectos auditados se produjeron mediante rutas que no estaban incluidas en el alcance de las auditorías identificadas. El estudio, elaborado por investigadores vinculados a la firma de seguridad ack3 y a la Universidad Técnica Checa de Praga, advierte de que la etiqueta «auditado» no describe necesariamente todo el sistema que utilizan los usuarios.
La mayor parte de las pérdidas quedó fuera del alcance revisado
Los investigadores analizaron 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 ese conjunto, 122 casos fueron clasificados como confirmados y 13 como probables.
El equipo encontró referencias públicas a auditorías anteriores al incidente en 68 casos. Dentro de ese grupo, 46 rutas de ataque quedaron fuera de todos los alcances de auditoría que pudieron identificar, 20 se encontraban dentro de al menos una revisión y dos no pudieron clasificarse.
Los 46 incidentes fuera de alcance representaron el 67,6% de los casos auditados, pero concentraron 680,97 millones de dólares de pérdidas sobre un total de 721,24 millones. Es decir, el 94,4% de las pérdidas de ese subconjunto. La cifra está muy condicionada por dos incidentes de gran tamaño: los de Kelp DAO, con 292 millones de dólares, y Drift Protocol, con 285 millones. Si se excluyen ambos, la proporción baja al 72,1%, con 103,97 millones de dólares sobre 144,24 millones.
El propio estudio limita el alcance de sus conclusiones. No compara protocolos auditados con otros que no hayan sufrido ataques, no mide cuánto tiempo estuvo expuesto cada sistema y no permite calcular la probabilidad de incidente ni demostrar que el hecho de quedar fuera del alcance provocara por sí mismo una pérdida. También pueden faltar auditorías privadas, incidentes no comunicados y datos de pérdidas plenamente comparables.
Una auditoría no cubre necesariamente el sistema en producción
El problema que plantea el trabajo es más concreto que cuestionar el valor de las auditorías. Estas suelen revisar código, componentes y versiones determinados en una fecha concreta. Sin embargo, un protocolo puede incorporar después nuevas implementaciones, contratos de actualización, claves privilegiadas, oráculos, servicios en la nube, interfaces o sistemas de retransmisión que no formaban parte de la revisión original.
El caso de ICON Network ilustra esa frontera. En el ataque de repetición del 27 de agosto, dos partes del proceso de retirada interpretaron de forma distinta el mismo mensaje. Según la autopsia publicada por ICON Foundation, un contrato de migración utilizaba los bits altos del número de serie para comprobar si una retirada era única, mientras que la firma criptográfica solo cubría los 256 bits inferiores.
El atacante modificó los bits no firmados y reutilizó 1.492 veces dos mensajes de retirada legítimamente firmados en unos 20 minutos. ICON indicó que 1.490 llamadas tuvieron éxito. El proceso liberó 119,866 millones de ICX y 531.600 bnUSD. En el momento de la autopsia, la fundación situó la pérdida neta confirmada en unos 150,2 ETH más 31.204 USDC, y señaló que había recuperado 531.600 bnUSD y 1,366 millones de SODA.
ICON afirmó que el contrato había sido auditado externamente y que las recomendaciones se habían aplicado. También señaló que la lógica de retransmisión recibió una revisión específica. Aun así, la discrepancia exacta entre el valor utilizado para comprobar la unicidad y el valor cubierto por la firma no quedó recogida en esas conclusiones.
El alcance debe incluir también la respuesta al incidente
El episodio muestra otra diferencia relevante: auditar la prevención no equivale a revisar la capacidad de detección y contención. La primera alerta automática de ICON llegó siete minutos después del inicio del ataque, pero el contrato afectado no se pausó hasta las 03:53 UTC. La fundación atribuyó el retraso a una configuración de alertas que había generado falsos positivos y no elevaba el aviso con la prioridad necesaria.
El incidente de aelf refleja una incertidumbre distinta. La empresa describió una intrusión en el entorno de ejecución de los nodos mediante contratos capaces de entregar ensamblados y órdenes codificadas, pero la información pública disponible no permite vincular esa ruta a una auditoría concreta anterior al ataque. Por ello, no es posible afirmar que se tratara de un fallo dentro o fuera de un alcance específico.
La conclusión del trabajo es más limitada, pero también más útil: historial de auditoría y alcance de auditoría son variables diferentes. Para que una afirmación de seguridad sea verificable, debería identificar el repositorio, la versión, la dirección desplegada, los componentes excluidos, los permisos privilegiados y las dependencias revisadas. También debería actualizarse con los cambios posteriores, los sistemas de custodia de claves, las alertas, los mecanismos de interrupción y el estado confirmado de los fondos afectados.
