Durante la semana pasada (2026/05/11 - 2026/05/17), BlockSec identificó múltiples incidentes de ataques en varios ecosistemas blockchain. La tabla a continuación lista 3 incidentes notables con pérdidas totales estimadas de aproximadamente $4.72M.
| Fecha | Incidente | Tipo | Pérdida Estimada |
|---|---|---|---|
| 2026/05/12 | Incidente de Transit Finance | Llamada Arbitraria | ~$1.88M |
| 2026/05/12 | Incidente de TAC | Validación Incorrecta | ~$2.8M |
| 2026/05/13 | Incidente de Boost Hook | Lógica de Negocio Defectuosa | ~$46.75K |
Se seleccionaron tres incidentes para un análisis en profundidad:
- Transit Finance: un contrato legado de intercambio puente, supuestamente obsoleto desde 2022, fue explotado mediante el reenvío arbitrario de calldata para drenar a usuarios que nunca revocaron sus aprobaciones de
USDT. - TAC: la mayor pérdida de esta semana (~$2.8M), donde la falta de verificación de billetera canónica en el flujo de depósito de jetton del lado TON permitió que notificaciones de depósito falsas desencadenaran la acuñación entre cadenas en TAC EVM.
- Boost Hook: un protocolo perpetuo basado en hook de Uniswap V4 explotado mediante manipulación del precio spot, demostrando los riesgos de usar precios de
slot0como precios de entrada para posiciones apalancadas.
El Mejor Auditor de Seguridad para Web3
Valida el diseño, el código y la lógica de negocio antes del lanzamiento
Destacado de la Semana: Transit Finance
Este incidente se destaca porque demuestra un patrón de riesgo persistente: contratos inteligentes obsoletos con aprobaciones de tokens que permanecen activas. Incluso cuando un protocolo considera un contrato obsoleto, los usuarios que nunca revocaron sus aprobaciones quedan expuestos indefinidamente, convirtiendo la infraestructura legada en una superficie de ataque latente.
El 12 de mayo de 2026, Transit Finance, un protocolo de agregación de intercambio y puente entre cadenas, fue explotado en TRON por aproximadamente $1.88M [1]. El atacante abusó de una ruta de ejecución arbitraria de calldata en un contrato legado TransitMixSwapBridge para invocar USDT.transferFrom() contra usuarios que previamente habían otorgado aprobaciones ilimitadas de USDT al contrato de aprobación de Transit. Aunque el contrato afectado supuestamente había sido obsoleto desde 2022, las relaciones de aprobación permanecían activas y explotables.
Antecedentes
Transit Finance es un protocolo de agregación de intercambio y puente entre cadenas que permite a los usuarios intercambiar y transferir activos a través de múltiples blockchains, incluido TRON. El despliegue en TRON del protocolo históricamente incluía un contrato TransitMixSwapBridge que enrutaba las ejecuciones de intercambio y puente a través de un proxy interno y una canalización de aprobación.
Análisis de Vulnerabilidad
El contrato TransitMixSwapBridge con errores (TUfPjK...Ukbc4) exponía funcionalidad de reenvío arbitrario de calldata: el calldata controlado por el atacante podía propagarse a través de la cadena de ejecución interna de Transit sin validación suficiente. Esto permitió al atacante crear cargas útiles que en última instancia desencadenaron llamadas USDT.transferFrom() a través del contrato de aprobación de Transit (TransitApproveGovernanceTron), que aún mantenía asignaciones ilimitadas otorgadas por los usuarios.
El defecto central es que la ruta de ejecución no realizaba ninguna restricción sobre el destino o el calldata de la llamada reenviada, lo que permitía que llamadas externas arbitrarias se ejecutaran bajo la autoridad del contrato de aprobación.
Análisis del Ataque
El siguiente análisis se basa en la transacción 3a981b83...ce918ac2.
-
Paso 1: El atacante invocó el contrato
TransitMixSwapBridgecon calldata manipulado. El calldata fue reenviado a través del proxy de Transit y la canalización de ejecución del puente hasta el contrato de aprobación. -
Paso 2: El contrato de aprobación de Transit (
TransitApproveGovernanceTron) ejecutó llamadasUSDT.transferFrom()controladas por el atacante. Debido a que los usuarios habían otorgado previamente asignaciones ilimitadas deUSDTa este contrato de aprobación, las llamadas tuvieron éxito. -
Paso 3: El
USDTfue transferido directamente desde las billeteras de las víctimas a la dirección controlada por el atacante, totalizando aproximadamente $1.88M.
Conclusión
El incidente fue causado por una vulnerabilidad de ejecución arbitraria de calldata en un contrato legado TransitMixSwapBridge combinada con aprobaciones de tokens ilimitadas persistentes. Aunque el contrato supuestamente había sido obsoleto desde 2022, las relaciones de aprobación permanecían activas y explotables. Las lecciones clave son: (1) los contratos obsoletos deben ser completamente desactivados, incluyendo la revocación de cualquier autoridad de aprobación que posean, (2) las rutas de reenvío arbitrario de calldata deben validar tanto la dirección de destino como el selector de función, y (3) los usuarios deben auditar y revocar regularmente las aprobaciones de tokens innecesarias, especialmente para protocolos obsoletos.
Referencias
Más Incidentes de Esta Semana
TAC
El 12 de mayo de 2026, TAC, un protocolo puente que extiende TON con ejecución compatible con EVM, fue explotado por aproximadamente $2.8M [1]. La causa raíz fue la falta de verificación de billetera canónica en el flujo de depósito de jetton del lado TON: el TAC JettonProxy aceptó un JettonNotify de una billetera jetton no canónica sin verificar que el remitente coincidiera con la billetera canónica derivada por el maestro jetton oficial. Esto permitió al atacante enviar notificaciones de depósito falsas que desencadenaron mensajes válidos entre cadenas y acuñaron activos mapeados en TAC EVM.
Antecedentes
TON no es nativamente compatible con EVM, lo que limita el acceso directo a aplicaciones DeFi al estilo Ethereum. TAC extiende TON proporcionando un puente que permite que los activos y mensajes originados en TON sean procesados en un entorno compatible con EVM. En este diseño, los depósitos de tokens del lado TON se convierten en mensajes entre cadenas y se acuñan como activos mapeados en TAC EVM.
Análisis de Vulnerabilidad
El contrato TAC JettonProxy con errores está desplegado en EQAChA...xMdw.
La vulnerabilidad es la falta de verificación de billetera canónica en la ruta de entrada de tokens del lado TON. TAC JettonProxy aceptaba mensajes JettonNotify sin verificar que msg.sender fuera la billetera jetton canónica derivada por el maestro jetton oficial para el propietario reclamado. Debido a esto, una billetera no canónica podía enviar un JettonNotify falso, hacer que fuera tratado como un depósito legítimo y desencadenar un mensaje entre cadenas válido de TVM a EVM.
Análisis del Ataque
El siguiente análisis se basa en las transacciones 549807fd...3757e1 y 0x0942a5...0dad224d.
- Paso 1: El atacante desplegó un contrato similar a una billetera y lo usó para enviar un
JettonNotifyalTAC JettonProxy. La carga útil reclamaba una transferencia de tokens e incluía unforward_payloadque contenía datos de ejecución entre cadenas.
- Paso 2:
TAC JettonProxyaceptó la notificación y emitió un mensaje entre cadenas descendente a TAC CCL. La billetera remitente no era la billetera canónica derivada por el maestro oficial deUSD₮(USDT en TON) para el propietario relevante, sin embargo la notificación fue procesada como un flujo de depósito válido.
- Paso 3: TAC EVM procesó el mensaje del puente y acuñó activos mapeados, incluyendo aproximadamente 2.17M de
USD₮mapeado, completando la ruta de explotación.
Conclusión
El incidente fue causado por la falta de verificación de billetera canónica en el flujo de depósito de jetton del lado TON de TAC. Una billetera no derivada del maestro jetton oficial envió exitosamente un JettonNotify falso, que el puente trató como un depósito legítimo y convirtió en una acuñación entre cadenas válida en TAC EVM. Una corrección robusta debe garantizar que el puente del lado TON verifique la dirección del remitente contra la billetera canónica derivada del maestro jetton oficial para el propietario y activo reclamados.
Referencias
Boost Hook
El 13 de mayo de 2026, Boost, un protocolo perpetuo construido sobre un pool y hook de Uniswap V4, fue explotado en Ethereum por aproximadamente $46.75K. La causa raíz fue la manipulación del precio spot: BoostHook usó el sqrtPriceX96 de slot0 del pool V4 directamente como precio de entrada al abrir posiciones apalancadas, lo que permitió al atacante inflar el precio dentro de una sola transacción y obligar al protocolo a comprar tokens PERP al precio manipulado usando sus propias reservas de ETH.
Antecedentes
Boost es un protocolo perpetuo construido sobre un único pool ETH/PERP de Uniswap V4 con un hook personalizado (BoostHook). PERP es un token ERC-20 de suministro fijo (1M de suministro total), y Boost actúa como el único proveedor de liquidez del pool, sembrando todos los PERP como bandas de liquidez concentrada por encima del precio inicial.
El apalancamiento se implementa como un intercambio de mercado contra este mismo pool. Cuando un usuario llama a openLong(), BoostHook complementa el colateral del usuario retirando ETH adicional de sus propias bandas superiores como monto prestado, luego intercambia el tamaño completo de la posición en PERP. El PERP permanece en el balance de BoostHook, y el usuario recibe un registro interno de Position. Cerrar o liquidar revierte el intercambio, reembolsa la deuda y devuelve cualquier excedente.
Análisis de Vulnerabilidad
El contrato BoostHook con errores está desplegado en 0x3db1...d7eacc.
La causa raíz es que BoostHook lee el sqrtPriceX96 de slot0 del pool —el precio spot— directamente como precio de entrada al abrir una posición. Dado que slot0 refleja el estado instantáneo del pool, es manipulable dentro de una sola transacción mediante grandes intercambios. No existe ninguna verificación que garantice que el precio de entrada esté dentro de un límite resistente a la manipulación como un TWAP.
Análisis del Ataque
El siguiente análisis se basa en la transacción 0xb45cc4...cebd3811.
-
Paso 1: El atacante tomó un préstamo flash de
WETHde Morpho Blue y lo desempaquetó aETH, proporcionando el capital inicial para el ciclo de manipulación. -
Paso 2: El atacante intercambió una gran cantidad de
ETHporPERPa través de Sat1SwapRouter, elevando el precio spot del pool hacia arriba. El atacante ahora tenía una gran posición enPERPcomprada al precio pre-bombeo.
- Paso 3: El atacante llamó a
openLong()con apalancamiento 5x múltiples veces. Por cada llamada, el atacante aportó un colateral pequeño (por ejemplo, 2ETH), yBoostHooktomó prestado 4x esa cantidad de sus propias bandas, luego compróPERPen el mercado con el tamaño completo de la posición al precio spot manipulado. Cada apertura sucesiva empujó el precio spot aún más alto, y la mayor parte de la presión compradora provenía del propioETHdel protocolo.
- Paso 4: El atacante intercambió el
PERPadquirido en el Paso 2 de vuelta aETH. Dado que el precio spot había sido elevado tanto por el bombeo original como por las aperturas financiadas por el protocolo en el Paso 3, el precio de salida fue significativamente más alto que el precio de entrada. La diferencia entre la compra barata y la venta cara constituyó la ganancia.
-
Paso 5: Dentro de la devolución de llamada
afterSwapdel dump,_scanAndLiquidatese activó y comenzó a liquidar las posiciones del Paso 3 como deuda incobrable contra el protocolo. Esto no tuvo ningún efecto en la ganancia del atacante ya que el pago del Paso 4 ya se había liquidado. -
Paso 6: El atacante envolvió el
ETHacumulado de vuelta aWETH, reembolsó el préstamo flash y conservó elETHrestante como ganancia.
Conclusión
El incidente fue causado por la manipulación del precio spot: BoostHook usó el precio spot del pool V4 directamente como precio de entrada para aperturas apalancadas, lo que permitió al atacante inflar el precio dentro de una sola transacción y obligar al protocolo a comprar PERP en el punto más alto con sus propias reservas de ETH. Una corrección debe restringir _swapEthForToken a un precio de referencia resistente a la manipulación como un TWAP, en lugar de confiar en el valor instantáneo de slot0.
Acerca de BlockSec
BlockSec es un proveedor integral de seguridad blockchain y cumplimiento cripto. Desarrollamos productos y servicios que ayudan a los clientes a realizar auditorías de código (incluyendo contratos inteligentes, blockchain y billeteras), interceptar ataques en tiempo real, analizar incidentes, rastrear fondos ilícitos y cumplir con las obligaciones AML/CFT, a lo largo del ciclo de vida completo de protocolos y plataformas.
BlockSec ha publicado múltiples artículos de seguridad blockchain en conferencias de prestigio, reportado varios ataques de día cero en aplicaciones DeFi, bloqueado múltiples hackeos para rescatar más de 20 millones de dólares, y asegurado miles de millones en criptomonedas.
-
Sitio web oficial: https://blocksec.com/
-
Cuenta oficial de Twitter: https://twitter.com/BlockSecTeam
