Resumen semanal de incidentes de seguridad Web3 | 23 mar – 29 mar, 2026

Durante la semana pasada (2026/03/23 - 2026/03/29), BlockSec detectó y analizó ocho incidentes de ataque, con pérdidas totales estimadas de ~$1.53M. La tabla a continuación resume estos incidentes, y los análisis detallados de cada caso se presentan en las subsecciones siguientes.

1. Incidente Desconocido 1

Resumen Breve

El 23 de marzo de 2026, un contrato no verificado en Ethereum fue explotado por aproximadamente $97K debido a un desbordamiento de entero en su lógica de distribución. La función 0x317de4f6() sumaba cantidades de tokens controladas por el usuario sin protección contra desbordamiento, lo que permitió al atacante provocar un desbordamiento circular y retirar el saldo completo de USDT del contrato mediante la función claim() pagando solo 1 wei de USDT.

Análisis de Vulnerabilidad

La causa raíz fue un desbordamiento de entero en la función 0x317de4f6() del contrato 0xF0a105...568C97. La función acepta un array de registros (cada uno con una cuenta y una cantidad) y suma todas las cantidades en totalAmount iterando el array. Debido a que la acumulación carecía de verificaciones de desbordamiento, un atacante podía suministrar registros manipulados cuyas cantidades dan la vuelta al uint256, haciendo que totalAmount sea arbitrariamente pequeño mientras las asignaciones individuales permanecen grandes.

Análisis del Ataque

El siguiente análisis se basa en la transacción 0x73bd1384...630b053.

• Paso 1: El atacante tomó 1 wei de USDT de Uniswap V4 como capital inicial para el ataque.

  

• Paso 2: El atacante consultó el saldo de USDT del contrato víctima y luego invocó 0x317de4f6() con un array manipulado. Una cantidad se estableció cerca del límite superior de uint256, y la otra se estableció igual al saldo de USDT del contrato víctima. Su suma desbordó a 1, lo que permitió al atacante pagar solo 1 wei de USDT mientras registraba una asignación igual al saldo completo de USDT de la víctima.

  

• Paso 3: El atacante invocó claim() para retirar 97,812e6 USDT del contrato víctima.

  

• Paso 4: El atacante devolvió el 1 wei de USDT prestado de Uniswap V4 e intercambió el USDT restante por WETH, completando el exploit.

Conclusión

Este incidente pone de relieve los riesgos de usar aritmética sin verificación en versiones de Solidity anteriores a la 0.8.0. Todos los cálculos financieros críticos deben usar explícitamente aritmética segura contra desbordamientos (por ejemplo, SafeMath o Solidity >=0.8.x) para prevenir problemas de desbordamiento circular.

2. Incidente Desconocido 2

Resumen Breve

El 23 de marzo de 2026, un contrato no verificado en Ethereum fue explotado por aproximadamente $11K debido a una vulnerabilidad de reentrada. La función 0xbe16634e() actualizaba la contabilidad relacionada con la liquidez antes de la liquidación e invocaba una llamada de retorno externa sin ninguna protección contra reentrada. Al reingresar a la función repetidamente antes de que la llamada anterior se liquidara, el atacante infló su liquidez registrada y posteriormente retiró más USDC y WETH de los que había depositado en realidad.

Análisis de Vulnerabilidad

La causa raíz es un problema de reentrada en la función 0xbe16634e() del contrato 0x39Ed37...9C6b08. Esta función actualiza el estado relacionado con la liquidez, incluyendo la liquidez del usuario y las reservas de ticks, antes de la liquidación e invoca una llamada de retorno externa a través de msg.sender.call() sin ningún mecanismo de protección contra reentrada. Dado que la verificación del saldo se realiza por llamada, el atacante puede reingresar recursivamente a la función e inflar la contabilidad interna de liquidez, mientras que una única transferencia de tokens en la llamada más profunda es suficiente para satisfacer el flujo de ejecución anidado.

Análisis del Ataque

El siguiente análisis se basa en la transacción 0x1382e898...fad993.

• Paso 1: El atacante tomó 100e8 USDC y 10e18 WETH de Uniswap V4 como capital inicial para el ataque.

  

• Paso 2: El atacante invocó 0xbe16634e() para agregar liquidez. Durante la ejecución, el contrato víctima llamó a la función 0x7c65be42() del atacante, que volvió a ingresar a 0xbe16634e() antes de que la llamada anterior se liquidara.

  

• Paso 3: Al repetir este flujo de reentrada varias veces, el atacante aumentó continuamente su liquidez registrada. En la llamada más profunda, el atacante transfirió los tokens requeridos una vez, lo cual fue suficiente para satisfacer las verificaciones de saldo anidadas.

  

• Paso 4: Tras inflar la liquidez registrada, el atacante verificó el estado del pool y transfirió fondos adicionales al pool para que tuviera suficientes USDC y WETH para cubrir el retiro próximo.

  

• Paso 5: El atacante invocó 0xbe16634e() nuevamente para eliminar liquidez y retiró USDC y WETH del pool basándose en la contabilidad inflada.

  

• Paso 6: El atacante devolvió los fondos a Uniswap V4, intercambió el USDC restante por WETH y completó el exploit.

  

Conclusión

Este incidente muestra el peligro de actualizar la contabilidad de liquidez antes de la liquidación mientras se invoca una llamada de retorno externa sin protección. Para prevenir exploits similares, los protocolos deben seguir estrictamente el patrón de verificaciones-efectos-interacciones y proteger las llamadas de retorno externas con mecanismos de protección contra reentrada.

3. Incidente de Cyrus Finance

Resumen Breve

El 23 de marzo de 2026, Cyrus Finance, un protocolo de yield-farming en BNB Chain, fue explotado por aproximadamente $512K debido a una fórmula defectuosa de eliminación de liquidez que depende del precio spot actual del pool. El protocolo usa posiciones NFT CYRP para representar una participación proporcional en su liquidez de PancakeSwap V3, pero la conversión de la participación del usuario a liquidez subyacente lee slot0(), que es manipulable dentro de la misma transacción. Al desplazar el precio mediante un intercambio financiado con flash loan, el atacante infló el valor de liquidez de su posición NFT y retiró más de lo que le correspondía.

Contexto

Cyrus Finance es un protocolo de yield-farming en BNB Chain que gestiona posiciones de liquidez en pools de PancakeSwap V3. Los usuarios depositan USDT para recibir posiciones NFT CYRP, que representan su participación en la liquidez del protocolo a través de múltiples posiciones de PancakeSwap V3. Los usuarios pueden retirar su capital más recompensas a través de la función exit().

Análisis de Vulnerabilidad

La vulnerabilidad reside en la función withdrawUSDTFromAny() en CyrusTreasury (0xb042Ea...0aE10b). Al procesar un retiro, la función obtiene sqrtPriceX96 de slot0() del pool de PancakeSwap V3 (es decir, el precio spot actual) y lo pasa a getAmountsForLiquidity() para estimar cuánto amount0 / amount1 representa actualmente la liquidez de la posición completa del protocolo.

Luego deriva availableUSDT a partir de esa valoración basada en el precio spot y usa la siguiente fórmula para determinar cuánta liquidez debe eliminarse para el retiro solicitado:

$liquidityToUse=liquidity\cdot remaining\mathrm{/}availableUSDTliquidityToUse\; =\; liquidity\; \backslash cdot\; remaining\; /\; availableUSDT$

En otras palabras, el contrato no canjea directamente una participación de propiedad fija. En cambio, primero estima el valor equivalente en USDT de la posición usando el precio en vivo del pool, y luego convierte el monto de USDT solicitado de vuelta en una cantidad de liquidez proporcional.

Esto es inseguro porque slot0() es manipulable dentro de la misma transacción. Al mover temporalmente el precio del pool, un atacante puede distorsionar availableUSDT, lo que afecta directamente el liquidityToUse calculado.

Análisis del Ataque

El siguiente análisis se basa en la transacción 0x85ac5d15...46d452.

• Paso 1: El atacante inició un flash loan desde un pool de PancakeSwap V3, tomando prestado aproximadamente 1,798 ETH.

• Paso 2: El atacante ejecutó un gran intercambio de ETH a USDT en el pool objetivo donde el protocolo mantenía liquidez, desplazando deliberadamente el precio del pool y el tick actual. En paralelo, el atacante transfirió la posición NFT CYRP #15505 desde 0x01737d...6ffa3 al contrato de ataque mediante safeTransferFrom().

• Paso 3: El atacante invocó exit(15505) en CyrusTreasury. Durante la ejecución, withdrawUSDTFromAny() leyó slot0() del pool de PancakeSwap V3 y calculó availableUSDT basándose en el precio spot manipulado. Debido al tick distorsionado, el protocolo sobreestimó el valor de liquidez correspondiente a la participación del NFT. Luego llamó a decreaseLiquidity() y collect(), liberando un exceso de USDT más allá del valor justo de la posición de Cyrus.

  

• Paso 4: El atacante restauró el estado del pool, devolvió el flash loan y transfirió el beneficio restante (~$512K) a la EOA 0xf96EB1...3b63b.

Conclusión

La mitigación debe reemplazar el precio spot de slot0() con precios resistentes a la manipulación (TWAP sobre una ventana de observación suficiente, u un oráculo externo como Chainlink) antes de convertir la liquidez en USDT retirable.

4. Incidente del Token BCE

Resumen Breve

El 23 de marzo de 2026, el pool BCE-USDT de PancakeSwap en BNB Chain fue explotado por aproximadamente $679K debido a un mecanismo de quema defectuoso en el token BCE. El atacante desplegó dos contratos maliciosos para eludir los límites de compra/venta de BCE y activó quemas de tokens contra las reservas del pool de liquidez, manipulando el precio del pool y drenando su USDT.

Análisis de Vulnerabilidad

La vulnerabilidad se origina en el mecanismo de quema defectuoso del token BCE (0xcdb189...999999). El problema central es que una variable de estado influenciada por el usuario, scheduledDestruction, se usa para quemar tokens directamente desde la dirección del par de PancakeSwap en lugar del saldo propio del usuario. Durante las operaciones de venta, el contrato acumula una cantidad de destrucción en scheduledDestruction basada en el volumen negociado y las reservas actuales del pool. Este valor no se deduce del vendedor. En cambio, se ejecuta posteriormente a través de una ruta de código separada que quema tokens del par y llama a sync().

Dado que el atacante controla el volumen de negociación y puede manipular las reservas del pool, puede establecer scheduledDestruction en un valor arbitrario y activar una quema que comprime la reserva de BCE del par, distorsionando el precio del pool a su favor.

Análisis del Ataque

El siguiente análisis se basa en la transacción 0x85ac5d15...46d452.

• Paso 1: El atacante invocó un contrato malicioso (MC1) para tomar prestados 123.5M USDT mediante múltiples flash loans y un pool de préstamos.

• Paso 2: El atacante desplegó un segundo contrato malicioso (MC2) y transfirió todos los USDT prestados a MC2.

• Paso 3: El atacante (a través de MC2) intercambió 2.222M USDT por 5.529M BCE en el pool BCE-USDT.

• Paso 4: El atacante transfirió 5.529M BCE desde MC2 a MC1 (a través de MC1.drain()); debido al mecanismo de quema, MC1 recibió 2.764M BCE.

• Paso 5: El atacante (a través de MC1) intercambió 2.488M BCE por 1.368M USDT, actualizando la variable scheduledDestruction a ~174K basándose en las reservas del pool y el monto del intercambio. La variable se usó posteriormente como cantidad de quema.

• Paso 6: El atacante (a través de MC2) intercambió 34.9M USDT por 3.484M BCE, manipulando aún más la reserva de BCE hacia ~174K.

• Paso 7: El atacante transfirió 3.484M BCE y el USDT restante desde MC2 a MC1. Dado que scheduledDestruction era mayor que 0 (es decir, ~174K), la transferencia de BCE activó quemas que comprimieron la reserva de BCE a ~10,000.

• Paso 8: El atacante intercambió el BCE restante por USDT al precio manipulado.

• Paso 9: El atacante devolvió todos los préstamos y obtuvo aproximadamente $679K de beneficio.

Conclusión

Este incidente fue causado por una falla fundamental en la lógica económica del token, donde una variable de estado influenciada por el usuario se usó para modificar el saldo del pool de liquidez en lugar del saldo propio del usuario. El contrato asumía implícitamente que la destrucción derivada de la actividad de negociación reflejaría el costo del usuario, pero en la práctica permitía a los atacantes construir una quema diferida liquidada contra las reservas de LP. Como resultado, los atacantes podían manipular la profundidad y los precios del pool con una exposición de capital limitada, extrayendo valor de los proveedores de liquidez.

5. Incidente Desconocido 3

Resumen Breve

El 25 de marzo de 2026, un contrato de staking no verificado en BNB Chain fue explotado por aproximadamente $1.2K debido a una contabilidad inconsistente entre múltiples modos de staking. El contrato compartía la misma variable de posición entre stake2()/withdraw2() y stake3()/withdraw3(), aunque estas funciones manejaban diferentes cestas de tokens y ratios. El atacante depositó a través del modo más ligero stake2() y rescató a través del modo más pesado withdraw3(), extrayendo repetidamente tokens en exceso.

Contexto

Este es un contrato de staking con varios modos de depósito y retiro. La ruta estándar stake() y withdraw() es el modo de staking completo, que maneja una cesta de Pangolin, Bzzt y Bzzone junto con la lógica de contabilidad de recompensas. La ruta stake3() y withdraw3() usa la misma cesta de tres tokens y el mismo ratio de depósito/retiro, pero omite el flujo adicional de contabilidad de recompensas. En cambio, la ruta stake2() y withdraw2() es un modo más ligero que maneja solo Pangolin y Bzzt, y por lo tanto usa una combinación de tokens y un ratio diferente al de los otros dos modos.

Análisis de Vulnerabilidad

La causa raíz fue una contabilidad inconsistente en el contrato 0x29d36c...774137. Aunque stake2()/withdraw2() y stake3()/withdraw3() manejaban diferentes cestas de tokens, todos actualizaban las mismas variables _exit[msg.sender] y _totalSupply. Como resultado, una posición creada a través del modo más ligero stake2() podía ser canjeada a través del modo más pesado withdraw3().

En la práctica, stake2(amount) solo tomaba amount de Pangolin y amount de Bzzt, pero withdraw3(amount) devolvía amount de Pangolin, 10 * amount de Bzzt y 10 * amount de Bzzone. Esto significaba que hacer staking de 20e18 Pangolin y 20e18 Bzzt a través de stake2() creaba un saldo _exit que podía usarse posteriormente para retirar 20e18 Pangolin, 200e18 Bzzt y 200e18 Bzzone a través de withdraw3(). Al repetir este desajuste, el atacante extraía continuamente tokens en exceso del contrato.

Análisis del Ataque

El siguiente análisis se basa en la transacción 0x7fcd5882...323f8d.

• Paso 1: El atacante desplegó un contrato en 0x9bce07d8bbe4f19dfe465710ff9612878bfe3302, lo financió con 0.05 BNB, envolvió los fondos en WBNB, intercambió exactamente 20e18 Pangolin, 20e18 Bzzt y 200e18 Bzzone, y aprobó al contrato de staking para gastar los tokens adquiridos.

  

• Paso 2: El atacante llamó a stake2() con la entrada 20e18, lo que transfirió 20e18 Pangolin y 20e18 Bzzt al contrato de staking y aumentó el saldo compartido _exit del atacante en 20e18.

  

• Paso 3: El atacante luego llamó a withdraw3() con la entrada 20e18. Debido a que withdraw3() solo verificaba el saldo compartido _exit, el contrato devolvió 20e18 Pangolin, 200e18 Bzzt y 200e18 Bzzone, aunque la posición había sido creada a través de stake2().

  

• Paso 4: El atacante repitió el ciclo stake2() -> withdraw3() muchas veces dentro de la misma transacción. En cada ronda, el Pangolin devuelto y una pequeña porción del Bzzt devuelto se reutilizaban para la siguiente llamada a stake2(), mientras que Bzzone se enviaba de vuelta al contrato de staking para que las llamadas posteriores a withdraw3() pudieran seguir teniendo éxito. A través de este bucle, el atacante aumentó su saldo de Bzzt de 20e18 a 16,400e18.

• Paso 5: El atacante intercambió los tokens adquiridos de vuelta a WBNB, desenvueltos los fondos a BNB y transfirió aproximadamente 2.007e18 BNB de vuelta a la EOA del atacante, completando el exploit.

  

Conclusión

Para prevenir exploits similares, los contratos de staking deben aislar la contabilidad para cada modo y asegurar que cada ruta de retiro coincida exactamente con la composición de activos y el ratio de su ruta de depósito correspondiente.

6. Incidente MYX

Resumen Breve

El 25 de marzo de 2026, el contrato sMYX de MYX Network en Ethereum fue explotado, resultando en aproximadamente 6.67 millones de tokens MYX drenados del pool (~$3.6K de beneficio). La causa raíz fue una interacción defectuosa entre la contabilidad de suministro de la función de transferencia y la lógica de distribución de dividendos en el contrato sMYX. Al transferir repetidamente sMYX entre cuentas controladas, el atacante infló la variable de beneficio-por-participación, fabricó dividendos sin respaldo y extrajo más MYX del que había depositado originalmente.

Contexto

El contrato sMYX (0x404328...d27F66) sigue un modelo de token de distribución de dividendos. Los usuarios depositan tokens MYX a través de una función de compra y reciben participaciones sMYX que representan su stake. Los dividendos se rastrean usando un acumulador global (beneficio-por-participación) almacenado en stor_11. Los dividendos reclamables de cada usuario se calculan como la diferencia entre su participación proporcional del beneficio acumulado y su línea base de pago registrada. Este modelo es conceptualmente similar a los tokens de reflexión anteriores, donde el valor entrante se redistribuye entre los tenedores existentes.

Análisis de Vulnerabilidad

La vulnerabilidad surge de una interacción defectuosa entre la contabilidad de suministro y la lógica de distribución de dividendos. La función de transferencia introduce incorrectamente nuevos dividendos al aumentar la variable global de beneficio-por-participación basándose en el monto transferido dividido por el suministro total actual. Esta operación no está respaldada por ninguna entrada real de tokens MYX, lo que significa que los dividendos se crean efectivamente a partir de la contabilidad interna en lugar de actividad económica real. Al mismo tiempo, la función reduce el suministro total registrado por el monto transferido debido a la semántica invertida del auxiliar de sustracción, aunque en realidad no se queman tokens.

Como consecuencia, cada transferencia posterior resulta en un incremento mayor a la variable de beneficio-por-participación, ya que el mismo monto de transferencia se divide por un suministro total cada vez más pequeño.

Análisis del Ataque

El siguiente análisis se basa en la transacción 0x843c9ea7...a55b90.

• Paso 1: El atacante obtuvo capital inicial mediante un flash swap y lo convirtió en MYX, luego depositó en el contrato sMYX para adquirir una posición de participación dominante dentro del sistema de dividendos, asegurando el control sobre la mayor parte de la distribución futura de recompensas.

• Paso 2: El atacante dividió su posición entre dos contratos controlados e inició un bucle coordinado que alternaba entre la realización de dividendos y la manipulación de estado, permitiendo un recorrido repetido de la ruta de contabilidad vulnerable.

• Paso 3: Mediante transferencias repetidas entre cuentas controladas, el atacante infló artificialmente la variable de beneficio-por-participación del protocolo mientras reducía simultáneamente el suministro total registrado, creando dividendos sin respaldo y amplificando su tasa de distribución.

• Paso 4: Al retirar continuamente después de cada ciclo de manipulación, el atacante extrajo la mayoría de estas recompensas fabricadas, drenando efectivamente las reservas de MYX del protocolo sin introducir nuevo capital.

• Paso 5: El atacante cerró todas las posiciones, intercambió el MYX extraído de vuelta a WETH, devolvió el flash loan y retuvo el saldo restante como beneficio.

Conclusión

Este incidente no es meramente consecuencia de un diseño económico tipo Ponzi, sino una falla crítica en la implementación de la contabilidad de dividendos. Para mitigar tales vulnerabilidades, las operaciones de transferencia no deben afectar el suministro total ni activar la distribución de dividendos, y las actualizaciones de beneficio-por-participación solo deben ocurrir cuando se introducen activos reales.

7. Incidente Desconocido 4

Resumen Breve

El 26 de marzo de 2026, un contrato de staking de TUR con recompensas de referidos en BNB Chain fue explotado por aproximadamente $133.5K. El contrato Stake calculaba el valor del depósito usando precios spot en vivo de AMM, que son manipulables dentro de una sola transacción. El atacante usó un flash loan para inflar el precio de TUR, hizo staking durante la ventana inflada y drenó recompensas desproporcionadas de TUR a través de cuentas de referidos bajo su control.

Contexto

El contrato Stake (0x03D809...415Abe) es un contrato de staking de TUR con recompensas de referidos. Los usuarios primero vinculan un referente superior mediante bind(), luego llaman a stake(), que quema el TUR en staking (lo envía a 0xdead) y acredita al usuario con power interno, un peso que determina cuánta recompensa de TUR puede reclamar el usuario posteriormente.

power no se asigna a un ratio fijo. En cambio, getPowerAmount() convierte el TUR depositado en un valor denominado en USDT encadenando dos precios AMM en vivo: TUR/NOBEL y NOBEL/USDT, ambos leídos desde las reservas actuales del par. El contrato también otorga poder de bonificación a los referentes de primer y segundo nivel a través de _distributeRefPower().

Análisis de Vulnerabilidad

La causa raíz fue una dependencia insegura del precio spot en el contrato Stake. En cada depósito, stake() calcula uValue = getPowerAmount(amount), lo convierte en _power = _uValue * 100, actualiza la contabilidad del staker y luego llama a _distributeRefPower() para propagar poder adicional a los referentes ascendentes.

Específicamente, uValue se calcula de la siguiente manera:

$uValue=getPowerAmount(amount)uValue\; =\; getPowerAmount(amount)$

donde getPowerAmount() es efectivamente:

$amount\times \text{precio spot TUR/NOBEL}\times \text{precio spot NOBEL/USDT}amount\; \backslash times\; \backslash text\{precio\; spot\; TUR/NOBEL\}\; \backslash times\; \backslash text\{precio\; spot\; NOBEL/USDT\}$

La implementación lee esos precios directamente de las reservas actuales del par mediante getReserves(), por lo que la valoración del staking depende completamente de los precios spot de la misma transacción en lugar de un oráculo resistente a la manipulación o TWAP.

Esto permite a un atacante inflar temporalmente la valoración on-chain de TUR, hacer staking durante la ventana manipulada y recibir uValue y power exagerados. La lógica de referidos amplifica el daño: _distributeRefPower() otorga el 20% del poder del staker al primer referente y el 5% al segundo referente, pero estas asignaciones adicionales no van acompañadas de una actualización correspondiente de rewardDebt para esos referentes. Como resultado, las cuentas de referentes controladas por el atacante pueden reclamar inmediatamente recompensas de TUR desproporcionadas del contrato Stake.

Análisis del Ataque

El siguiente análisis se basa en la transacción 0x96c9ce3c...81e348.

• Paso 1: El atacante tomó prestados 1,900,000e18 USDT del contrato Moolah de ListaDAO como capital de flash loan.

• Paso 2: El atacante usó el capital prestado para manipular los pools NOBEL-USDT y TUR-NOBEL, empujando temporalmente la valoración spot de TUR fuertemente al alza.

• Paso 3: Durante la ventana manipulada, el atacante hizo staking de 7,770,707e18 TUR en el contrato Stake. La transacción emitió un StakeEvent que mostraba un uValue masivamente inflado de 8,283,864e18 y un power correspondiente de 828,386,488e18.

• Paso 4: Dado que el atacante ya había organizado cuentas de referentes bajo su control, _distributeRefPower() les otorgó poder de recompensa adicional derivado del stake manipulado. Los referentes de primer y segundo nivel recibieron las asignaciones de referido esperadas del 20% y 5%.

• Paso 5: Las cuentas de referentes con poder amplificado reclamaron recompensas de TUR del contrato Stake. En la misma transacción, Stake transfirió 15,238,941e18 TUR a 0xFd11...AcEaB y 3,809,924e18 TUR a 0x9007...E550B; ambas direcciones reenviaron inmediatamente las mismas cantidades al atacante. La relación de pago 4:1 coincide con la división de poder de referido del 20% versus 5% del contrato.

• Paso 6: La transacción también muestra comisiones de reclamación fluyendo desde Stake hacia la billetera de fondos 0xb302...89923, consistente con la implementación de claim() que cobra una tarifa del 3% en TUR antes de enviar recompensas a los reclamantes.

• Paso 7: Tras extraer las recompensas amplificadas de TUR, el atacante intercambió los beneficios de vuelta a USDT, devolvió el flash loan de 1,900,000 USDT y transfirió 133,490e18 USDT a 0xEf67...4e5898 como beneficio.

Conclusión

Este incidente fue causado por un modelo de valoración de recompensas manipulable en el contrato Stake, no por la contabilidad de dividendos LP separada del token TUR. Al vincular el poder de staking y las recompensas de referidos a los ratios de reservas AMM en vivo, el contrato permitió a un atacante financiado con flash loan inflar el precio spot de TUR, fabricar poder de recompensa excesivo y drenar TUR del contrato de staking a través de cuentas de referidos bajo su control. Un diseño más seguro reemplazaría el precio de las reservas spot con un oráculo resistente a la manipulación o un TWAP suficientemente largo, y aseguraría que cualquier aumento de poder de referido esté acompañado de una contabilidad de deuda de recompensa consistente.

8. Incidente del Token EST

Resumen Breve

El 27 de marzo de 2026, el contrato BNBDeposit en BNB Chain fue explotado por aproximadamente $92.3K debido a dos problemas: una dependencia del precio spot en BNBDeposit y un mecanismo de quema defectuoso en el token EST. La dependencia del precio permitió al atacante adquirir una gran cantidad de EST, y el mecanismo de quema defectuoso permitió al atacante drenar el pool EST-WBNB mediante una manipulación tipo sándwich.

Análisis de Vulnerabilidad

La causa raíz del incidente es doble:

1. La función onTokenReceived() en el contrato BNBDeposit (0xE71547...d29A61) calculaba la cantidad reclamable de los usuarios basándose en el saldo del contrato y el precio spot de EST, ambos fácilmente manipulables.

   

2. El token EST (0xD4524B...498a91) implementó un mecanismo de quema defectuoso que permite a un atacante quemar EST en el pool EST-WBNB transfiriendo directamente EST al pool.

   

Como resultado, el atacante aprovechó ambas vulnerabilidades para realizar un ataque sándwich y sifonar WBNB del pool EST-WBNB.

Análisis del Ataque

El siguiente análisis se basa en la transacción 0x2f1c33ea...bd1626.

• Paso 1: El atacante tomó prestados 250,000e18 WBNB a través de Moolah y desenvolvió 15e18 WBNB a BNB para el ataque.

• Paso 2: El atacante transfirió repetidamente 0.3e18 BNB a BNBDeposit 34 veces (total 10.2e18 BNB). Cada transferencia directa activó la lógica de depósito. En este paso, el atacante recibió ~9,100e18 tokens LP (en contabilidad virtual) y 2.65e18 WBNB como bonificación.

• Paso 3: El atacante intercambió 400e18 WBNB por ~822Me18 EST y estableció BNBDeposit como destinatario, inflando tanto el saldo de EST de BNBDeposit como el precio de EST en el pool.

• Paso 4: El atacante transfirió 1e18 EST a BNBDeposit para activar el mecanismo de reclamación, recibiendo 20Me18 EST basándose en el precio y el saldo amplificados.

• Paso 5: El atacante intercambió 245,000e18 WBNB por ~330Me18 EST y estableció BNBDeposit como destinatario.

• Paso 6: El atacante realizó acciones de transferencia-skim ~150 veces para quemar continuamente EST en el pool EST-WBNB.

• Paso 7: El atacante intercambió el EST restante por 245,560e18 WBNB.

• Paso 8: El atacante devolvió el flash loan y obtuvo 150 WBNB de beneficio.

Conclusión

Este incidente fue causado por dos problemas: una dependencia del precio spot y un mecanismo de quema defectuoso. Para mitigar riesgos similares, los proyectos deben asegurar oráculos de precios confiables y una lógica de quema de tokens sólida antes del despliegue.

Acerca de BlockSec

BlockSec es un proveedor integral de seguridad blockchain y cumplimiento cripto. Construimos 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

• 🔗 Servicio de Auditoría de BlockSec : Enviar una solicitud

• 🔗 Phalcon Security APP: Reservar una demo

• 🔗 Phalcon Compliance