Durante la semana pasada (2026/07/13 - 2026/07/19), se destacan los siguientes 2 incidentes de seguridad notables, con pérdidas totales aproximadas de $1.35M en Ethereum y Solana.
| Fecha | Incidente | Tipo | Pérdida estimada |
|---|---|---|---|
| 2026/07/15 | BarnBridge | Gobernanza incorrecta | ~$776K |
| 2026/07/16 | DeFiTuna | Verificación de salud fallida | ~$570K |
- DeFiTuna: La verificación de salud de la posición aceptaba un valor de activo cero como saludable con una deuda distinta de cero; el atacante utilizó enrutamiento de intercambio controlado y un grupo de baja liquidez separado para desencadenar este defecto y crear una posición de deuda incobrable.
- BarnBridge: Se explotó un sistema de gobernanza obsoleto para modificar la configuración crítica del protocolo y drenar los fondos aprobados por los usuarios.
Best Security Auditor for Web3
Validate design, code, and business logic before launch
Destacado de la semana: DeFiTuna
La causa raíz fue una rama de valor cero defectuosa en la verificación de salud de la posición: una posición con valor de activo cero y aproximadamente $570K de deuda pendiente fue aceptada como saludable. El atacante desencadenó este defecto enrutando el intercambio a través de un grupo de baja liquidez separado, pero la verificación de salud era el control que debería haber detectado la deuda incobrable resultante.
El 16 de julio de 2026, DeFiTuna, un protocolo de préstamos en Solana que admite posiciones al contado apalancadas, fue explotado por aproximadamente $570K en USDC [1]. La causa raíz fue una rama de valor cero defectuosa en la verificación de salud de la posición que aceptaba una posición como saludable incluso cuando su valor de activo era cero y su deuda era distinta de cero. El atacante abrió una posición apalancada con cero colateral, tomó prestado USDC de la bóveda del protocolo y enrutó el intercambio a través de un grupo de baja liquidez controlado por el atacante, lo que provocó que la posición recibiera una cantidad insignificante del token objetivo. El truncamiento de precisión redondeó el valor de la posición a cero, y la verificación de salud aceptó la posición como saludable, creando aproximadamente $570K de deuda incobrable.
Antecedentes
DeFiTuna es un protocolo de préstamos en Solana que admite operaciones de margen. Un usuario puede abrir una posición al contado proporcionando un token como colateral, tomando prestado de una bóveda del protocolo e intercambiando los fondos prestados por un token objetivo. La posición resultante se verifica contra la deuda para determinar si es saludable.
En un mercado al contado de DeFiTuna, los dos tokens del grupo se denominan token A y token B. En el mercado atacado, el token A era TUNA y el token B era USDC.
USDCera el token de colateral (collateral_token). El usuario depositaUSDCcomo margen, toma prestadoUSDCadicional de la bóveda de DeFiTuna, y elUSDCprestado se intercambia porTUNA.TUNAera el token de posición (position_token), el activo que la posición mantiene después del intercambio. El efecto neto es una posición larga apalancada enTUNAfinanciada por deuda enUSDC.- Las cuentas de bóveda mantienen la liquidez de los prestamistas y son la fuente de los fondos prestados.
- El grupo AMM proporciona liquidez de mercado y contexto de precios para el par
TUNA/USDC.
DeFiTuna enruta los intercambios de posiciones a través de Jupiter, un agregador de intercambios de Solana. La ruta de intercambio se proporciona a la instrucción de DeFiTuna como datos de ruta de Jupiter y cuentas de ruta. Dado que el llamador proporciona estas cuentas, el llamador controla qué grupo utiliza el intercambio. Antes de ejecutar el intercambio, DeFiTuna realiza una verificación de precio previa al intercambio comparando el precio del grupo de mercado normal con un oráculo.
Análisis de vulnerabilidad
El programa con errores es DeFiTuna (tuna4u...nogD).
La causa raíz fue una rama de valor cero defectuosa en la verificación de salud de la posición. Después de un intercambio, DeFiTuna valoró la posición convirtiendo el TUNA mantenido en términos de USDC. Si el saldo de TUNA era suficientemente pequeño para redondearse a cero, el campo total se convertía en 0. La lógica de verificación de salud trataba total == 0 como un estado saludable sin requerir que debt == 0.
Análisis del ataque
Dos propiedades de diseño le dieron al atacante control sobre hacia dónde se enrutaban los fondos prestados. Primero, DeFiTuna aceptó datos RouteV2 de Jupiter proporcionados por el llamador sin derivar su propio resultado mínimo aceptable de TUNA a partir del precio del oráculo y el monto prestado. Segundo, la verificación de oráculo previa al intercambio solo validaba el grupo de mercado normal de DeFiTuna, no el grupo que la ruta de Jupiter realmente utilizaría.
Nota: El análisis post-incidente respaldado por el equipo del proyecto [1] describe el grupo creado por el atacante como inicializado cerca del precio legítimo del oráculo. La evidencia en cadena muestra que el grupo fue inicializado a un precio extremo; la verificación previa al intercambio pasó porque validó el grupo de mercado normal separado, no el grupo controlado por el atacante.
El siguiente análisis se basa en la transacción 4x33Dq...EXj1. Se ejecutaron múltiples transacciones de ataque; esta ilustra la técnica principal.
- Paso 1: El atacante creó un nuevo grupo Fusion
TUNA/USDC. Este grupo utilizaba los tokens realesTUNAyUSDC, pero era independiente del grupo de mercado normal de DeFiTuna. El grupo fue inicializado a un precio extremo cerca del tick208636, con un precio deTUNAde aproximadamente 1.149 mil millones deUSDCporTUNA. A este precio, incluso una cantidad mínima deTUNApodía absorber cientos de miles deUSDCen un intercambio.
- Paso 2: El atacante colocó dos pequeñas órdenes límite de venta en el nuevo grupo. Cada orden depositó
0.000526 TUNA, totalizando0.001052 TUNA. Debido a que el precio del grupo era extremadamente alto, este pequeño suministro deTUNApodía absorber todo el monto deUSDCprestado cuando se ejecutara el intercambio.
- Paso 3: Con el grupo preparado, el atacante abrió una posición al contado en DeFiTuna con
TUNAcomo token de posición yUSDCcomo token de colateral. El atacante proporcionó0 USDCcomo colateral y tomó prestado570,000 USDCde la bóveda deUSDCde DeFiTuna.
- Paso 4: Antes del intercambio, DeFiTuna comparó el precio del grupo de mercado normal con el precio del oráculo. El precio al contado del grupo normal estaba cerca del oráculo, por lo que la verificación pasó. Esta verificación solo validó el grupo de mercado normal de DeFiTuna; no validó el grupo Fusion que la ruta de Jupiter utilizaría.
- Paso 5: El intercambio siguió la ruta de Jupiter proporcionada por el atacante, que dirigió los fondos a través del grupo Fusion controlado por el atacante con el resultado mínimo establecido efectivamente en cero. Después de la comisión del protocolo,
569,601 USDCfue enrutado hacia el grupo de ataque, mientras que la posición de DeFiTuna recibió solo494unidades brutas deTUNA(0.000494 TUNA).
- Paso 6: Después del intercambio, la posición tenía aproximadamente
570,000 USDCde deuda y solo una cantidad residual deTUNA. Cuando DeFiTuna convirtió ese saldo deTUNAen valor deUSDC, el resultado se redondeó a0. La verificación de salud tratótotal == 0como saludable, por lo que la posición de deuda incobrable fue aceptada.
- Paso 7: El atacante retiró el
USDCacumulado en el grupo Fusion controlado por el atacante. Los dos retiros fueron casi iguales, coincidiendo con las dos posiciones de órdenes límite creadas en el Paso 2.
Conclusión
La causa raíz fue la rama total == 0 de la verificación de salud que aceptaba una posición como saludable independientemente de la deuda pendiente. El enrutamiento y la liquidez controlados por el atacante crearon las condiciones para desencadenar este defecto, pero la verificación de salud era el control final que debería haber prevenido la deuda incobrable.
La corrección más directa es rechazar cualquier posición donde total == 0 y debt > 0. Una posición de valor cero con deuda pendiente nunca es saludable. Además, el protocolo debería derivar un resultado mínimo aceptable del intercambio a partir del precio del oráculo y el monto prestado, independientemente de los parámetros de ruta proporcionados por el llamador. Vincular la verificación de oráculo/precio al grupo de intercambio real, o verificar el resultado del intercambio contra un límite calculado por el protocolo, evitaría que la verificación previa al intercambio sea eludida enrutando a través de un grupo no validado.
Referencias
Más incidentes de esta semana
BarnBridge
El 15 de julio de 2026, BarnBridge, un protocolo de asignación de rendimiento en Ethereum, fue explotado por aproximadamente $776K en USDC [1]. La causa raíz fue que el contrato de gobernanza abandonado retenía autoridad para modificar la configuración crítica del protocolo. El atacante adquirió suficiente poder de voto para aprobar una propuesta maliciosa que reemplazó el controlador de un componente del protocolo, y luego usó el nuevo controlador para transferir el USDC aprobado por los usuarios.
Antecedentes
BarnBridge es un protocolo gobernado por DAO que asigna los fondos de los usuarios en diferentes mercados de préstamos para generar rendimiento. El poder de voto se determina por la cantidad de BOND en staking y la duración del bloqueo. Crear una propuesta requiere un poder de voto igual al menos al 1% del poder de voto total. Una propuesta debe alcanzar un quórum mínimo del 40% y recibir al menos el 60% de los votos totales participantes a favor para ser aprobada. Una vez presentada, una propuesta pasa por un período de calentamiento de dos días, un período de votación de tres días y un período de espera de dos días antes de poder ejecutarse.
Análisis de vulnerabilidad
La causa raíz fue que el contrato de gobernanza abandonado retenía la autoridad para modificar la configuración crítica del protocolo después de que el protocolo había sido obsoleto. El sistema de gobernanza controlaba la asignación de Controller para CompoundProvider, un contrato que los usuarios habían aprobado previamente para gastar su USDC. Debido a que BarnBridge había sido obsoleto, el total de BOND en staking y la participación activa habían disminuido significativamente, haciendo que la aprobación de propuestas hostiles fuera trivialmente alcanzable.
Análisis del ataque
El siguiente análisis se basa en la transacción 0xd191fe...895afb.
El atacante gastó aproximadamente 0.335 ETH para adquirir alrededor de 32,795 BOND, luego depositó y bloqueó 32,000 BOND, obteniendo aproximadamente el 43% del poder de voto total.
- Paso 1: El atacante desplegó un contrato proxy y presentó una propuesta maliciosa. Después del período de calentamiento de dos días, el atacante emitió todo su poder de voto a favor, satisfaciendo tanto los requisitos de quórum como de aprobación.
- Paso 2: El atacante puso en cola la propuesta. Después de que transcurrió el período de espera de dos días, el atacante la ejecutó, estableciendo el
ControllerdeCompoundProvideren el contrato proxy del atacante.
- Paso 3: El atacante actualizó la lógica del contrato proxy y llamó a
_takeUnderlying(), que usó las asignaciones pendientes deUSDCde aproximadamente 50 usuarios para transferir suUSDCaCompoundProvider. El atacante luego llamó atransferFees()para reenviar los fondos a la dirección del atacante, obteniendo una ganancia de aproximadamente $776K enUSDC.
Conclusión
Si un DAO o protocolo está siendo obsoleto, su contrato de gobernanza debería renunciar o deshabilitar permanentemente la capacidad de modificar configuraciones críticas de seguridad, especialmente los permisos de administrador, controlador y retiro de fondos. Las medidas concretas incluyen revocar el rol de administrador del contrato de gobernanza sobre los contratos posteriores, transferir la propiedad a una dirección de quema, o ejecutar una propuesta final que deshabilite las funciones de actualización y establezca las referencias de controlador en valores seguros inmutables. Dejar la autoridad de gobernanza intacta en un protocolo obsoleto crea una superficie de ataque de bajo costo: a medida que disminuye la participación, el capital necesario para alcanzar el quórum disminuye proporcionalmente.
