Resumen semanal de incidentes de seguridad en Web3 | 30 mar – 5 abr, 2026

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

1. Incidente de Protocolo Desconocido

Resumen

El 30 de marzo de 2026, un protocolo desconocido en BNB Chain perdió ~$10K debido a una lógica de negocio defectuosa. El protocolo asignaba parte de los depósitos de los usuarios para comprar su token de plataforma PSTART y añadir liquidez, lo que significaba que los usuarios sostenían efectivamente posiciones LP sujetas a las fluctuaciones del precio de mercado. Sin embargo, al retirar, el protocolo no liquidaba en función del valor real reembolsable del LP en ese momento. En su lugar, seguía prometiendo una cantidad fija de stablecoins basada en el depósito histórico y reglas predefinidas. Como resultado, tras comprometer capital mediante inversión forzada, el atacante podía retirar fondos a un valor fijo preacordado, transfiriendo efectivamente las pérdidas que debería haber soportado la posición LP al protocolo, logrando en última instancia un beneficio a coste cero.

Antecedentes

El protocolo funciona de la siguiente manera: tras que un usuario deposita BUSD, el protocolo utiliza automáticamente una parte de los fondos para comprar PSTART, y luego lo empareja con el BUSD restante para añadir liquidez al pool. Las participaciones LP resultantes quedan en custodia del Vault, mientras que el protocolo registra, en su libro de contabilidad interno, una orden para el usuario que promete un rendimiento diario fijo.

Posteriormente, el usuario puede reclamar recompensas a una tasa de interés fija, y al salir, el Vault liquida el principal y el rendimiento según reglas predefinidas, en lugar de reembolsar estrictamente en función del valor neto real actual de la posición LP subyacente.

Análisis de la Vulnerabilidad

Esta vulnerabilidad se origina en un diseño de protocolo irrazonable (0x587984...73a43c): la lógica de liquidación está desconectada del valor real de los activos subyacentes.

Tras que un usuario deposita BUSD, el protocolo usa parte de él para comprar PSTART y añadir liquidez, lo que significa que la posición subyacente real del usuario es una exposición LP cuyo valor fluctúa con los precios de mercado. Sin embargo, cuando el usuario sale, el protocolo no liquida en función del valor reembolsable real del LP en ese momento. En su lugar, sigue prometiendo pagar una cantidad fija de stablecoins según el monto del depósito histórico y las reglas de liquidación predefinidas.

El atacante explotó esta falla usando un préstamo flash para obtener una gran cantidad de capital y luego ejecutar deposit() repetidamente. Al hacerlo, el atacante forzó al protocolo a comprar continuamente PSTART y alterar la composición de activos del pool, impulsando artificialmente el precio de PSTART y creando una oportunidad de arbitraje.

El atacante ejecutó entonces withdraw() y redimió los fondos al valor fijo prometido previamente, transfiriendo efectivamente las pérdidas que debería haber soportado la posición LP subyacente al propio protocolo, logrando en última instancia un beneficio a coste cero.

Análisis del Ataque

El siguiente análisis se basa en la transacción 0xf3b8...55e7.

• Paso 1: El atacante obtuvo aproximadamente 2,000,000e18 BUSD mediante un préstamo flash y los intercambió en el pool por 19,013,120e18 PSTART.

• Paso 2: El atacante llamó repetidamente a la función deposit() del contrato para hacer staking de fondos. Por cada depósito, el protocolo calculaba cuánto BUSD debía usarse para comprar tokens de modo que la proporción final de tokens a BUSD usada para añadir liquidez se ajustara más a la proporción actual del pool. Al depositar repetidamente, el atacante inyectó continuamente BUSD en el pool, mientras que la cantidad de PSTART permanecía casi sin cambios. Como resultado, el valor de PSTART seguía aumentando. En esta etapa, el LP obtenido mediante los depósitos del atacante se estaba adquiriendo realmente con pérdidas.

• Paso 3: El atacante entonces vendió de vuelta al pool el PSTART comprado en el Paso 1. Debido a que el Paso 2 había aumentado las reservas de BUSD del pool, este intercambio devolvió aproximadamente 2,010,655e18 BUSD, generando un beneficio de aproximadamente 10,655 BUSD en un solo ciclo de ataque.

• Paso 4: Finalmente, el atacante ejecutó withdraw() en todas las posiciones de staking abiertas en el Paso 2. En ese momento, el valor de mercado de los activos correspondientes a estas posiciones ya estaba muy por debajo de su valor de depósito inicial. Bajo una lógica económica normal, no debería haber sido posible el reembolso completo. Sin embargo, el protocolo calculó el monto de BUSD reembolsable en función del monto del depósito histórico, lo que permitió al atacante recuperar completamente todos los costos de inversión forzada anteriores sin soportar ninguna pérdida.

Conclusión

La causa raíz de este incidente es que el protocolo invirtió los fondos de los usuarios en posiciones LP sujetas a fluctuaciones de precios de mercado, pero aun así prometió la liquidación en una cantidad fija de BUSD basada en los valores de depósito históricos y reglas predefinidas. Esto creó una desconexión entre los pasivos del protocolo y el valor real de sus activos subyacentes.

El atacante explotó esta falla utilizando repetidamente deposit() para alterar la estructura de activos del pool y elevar el precio de PSTART, luego completó el arbitraje a través de una posición externa, y finalmente usó withdraw() para redimir las posiciones previamente deficitarias a valor en libros. De esta manera, las pérdidas que debían haber soportado las propias posiciones se transfirieron al protocolo, permitiendo en última instancia un beneficio sin riesgo.

2. Incidente del Token WDGG

Resumen

El 30 de marzo de 2026, el token WDGG en BNB Chain fue explotado, resultando en pérdidas de aproximadamente $40K. La causa raíz fue la ausencia de control de acceso en la función burnFrom(). Específicamente, la función burnFrom() permitía a usuarios arbitrarios quemar tokens WDGG de cualquier dirección. El atacante explotó esto quemando tokens WDGG del pool de PancakeSwap, luego invocando la función sync() para reducir las reservas de WDGG del pool, y posteriormente realizando un intercambio inverso para extraer beneficios.

Antecedentes

Este incidente involucra un único token, WDGG, que es un token de distribución de dividendos que cobra una comisión en cada transferencia.

Análisis de la Vulnerabilidad

El contrato del token WDGG (0x512de7...6b90c5) expuso burnFrom() sin ninguna autorización del llamante. Como resultado, cualquier dirección podía quemar tokens WDGG de cualquier titular, incluido el propio pool de PancakeSwap. Combinado con la función sync() de PancakeSwap, que puede ser llamada públicamente y que realinea las reservas registradas con los saldos reales, esta falla permitió que la reserva de WDGG del pool fuera reducida arbitrariamente y que la invariante de producto constante se rompiera sin ninguna operación comercial legítima, exponiendo el pool al arbitraje por desequilibrio de precios.

Una falla secundaria en setWdgAddress() permitía a cualquier llamante marcar una dirección arbitraria como exenta de comisiones, maximizando aún más el beneficio extraíble a través de esta superficie de ataque.

Análisis del Ataque

El siguiente análisis se basa en la transacción 0x2da5...0bd1.

• Paso 1: El atacante primero llamó a setWdgAddress() para establecer su propia dirección como exenta de comisiones, lo que permitió que las transferencias posteriores evitaran la comisión de transferencia del token.

• Paso 2: El atacante luego intercambió una pequeña cantidad de BNB por tokens WDGG a través del pool de PancakeSwap.

• Paso 3: Tras obtener WDGG, el atacante invocó burnFrom() para quemar tokens WDGG directamente desde la dirección del par de PancakeSwap.

• Paso 4: El atacante posteriormente llamó a sync(), forzando al par a actualizar sus reservas para que coincidieran con los saldos de tokens manipulados. Como resultado, la reserva de WDGG en el pool se redujo a solo 1 wei.

• Paso 5: Con las reservas del pool gravemente distorsionadas, el atacante ejecutó un intercambio inverso y extrajo beneficios del desequilibrio de precios.

Conclusión

Este incidente fue causado en última instancia por la ausencia de control de acceso en la función burnFrom() del contrato del token WDGG. Como resultado, un atacante pudo quemar tokens directamente del pool de PancakeSwap, manipular las reservas del pool a través de sync(), y explotar el desequilibrio de precios resultante para obtener beneficios.

3. Incidente de i6Token

Resumen

El 31 de marzo de 2026, el token i6 en BNB Chain perdió ~$273.8K porque invest() movía el precio spot del pool mientras que withdraw() liquidaba saldos mediante un TWAP retrasado, y ambos podían componerse en la misma transacción. El atacante infló el precio spot mediante invest(), redimió i6 excedente al TWAP desactualizado a través de withdraw(), y vendió el i6 de vuelta al pool inflado para obtener beneficios.

Antecedentes

El protocolo funciona de la siguiente manera. Cuando un usuario llama a invest(), se deposita USDT y se usa parcialmente para comprar i6 en PancakeSwap. El i6 adquirido, junto con el USDT restante, se añade como liquidez al pool USDT/i6, y los tokens LP resultantes se queman. El protocolo registra los saldos de usuarios y referidos denominados en USDT.

Cuando se llama a withdraw(), el protocolo calcula el valor acumulado del usuario en términos de USDT y lo convierte en i6 utilizando un precio TWAP mantenido por el protocolo (twapPrice).

Análisis de la Vulnerabilidad

La causa raíz en el contrato del protocolo (0x1cb36b...2a18a) es que invest() muta el precio spot del pool USDT/i6 como efecto secundario de comprar i6 y añadir liquidez, mientras que withdraw() liquida los saldos acumulados denominados en USDT en i6 usando un TWAP mantenido por el protocolo (twapPrice) que solo se actualiza después de que transcurre una ventana de tiempo. Nada en el contrato impide que estas dos funciones se ejecuten en la misma transacción.

Debido a que una llamada a invest() puede inflar el precio spot dentro de la misma transacción en que un withdraw() posterior lee un TWAP aún no actualizado, las dos ven efectivamente dos precios diferentes para el mismo estado del pool. Un saldo denominado en USDT redimido a través de withdraw() se paga entonces en i6 al precio antiguo y mucho más bajo, aunque cada i6 ahora se puede realizar por mucho más USDT en el propio pool. Esta brecha convierte cualquier saldo acumulado en USDT en el protocolo en un diferencial explotable entre la liquidación interna y el pool en vivo.

Análisis del Ataque

El siguiente análisis se basa en la transacción 0xc1b9...2f16.

• Paso 1: El atacante primero obtuvo 270,000 WBNB mediante un préstamo flash, luego los proporcionó a Venus como garantía y tomó prestado una gran cantidad de USDT. El atacante también desplegó el contrato de ataque A en 0xda49 y el contrato auxiliar B en 0x096a.

• Paso 2: El contrato de ataque ejecutó el primer invest(). Durante este proceso, el protocolo primero usó 531,489e18 USDT para comprar 234,188e18 i6, y luego añadió 354,326e18 USDT junto con 72,607e18 i6 al pool. Como resultado, el precio spot del pool aumentó rápidamente de aproximadamente 1.05159 USDT/i6 a aproximadamente 4.89287 USDT/i6, mientras que el TWAP registrado del protocolo se mantenía aún en solo 1.05159.

• Paso 3: El atacante luego transfirió 124,014,184e18 USDT al contrato auxiliar B, que a su vez llamó a invest() con referrer = A. Este paso nuevamente forzó al protocolo a realizar una compra masiva de USDT -> i6 y addLiquidity(), empujando las reservas del pool a un nuevo estado correspondiente a un precio spot de aproximadamente 15,528 USDT/i6. Sin embargo, como no había transcurrido ninguna nueva ventana de tiempo, el protocolo no actualizó el TWAP en consecuencia.

• Paso 4: Después de completarse el segundo invest(), el contrato de ataque A, actuando como referido, inmediatamente adquirió el derecho a una recompensa de referido denominada en USDT. El atacante entonces llamó a withdraw(). El protocolo utilizó el TWAP desactualizado para calcular la cantidad de i6 a pagar y transfirió los tokens de su propio saldo, resultando en un pago total de 5,896,508e18 i6.

• Paso 5: Tras recibir el i6, el atacante inmediatamente llamó a swapExactTokensForTokensSupportingFeeOnTransferTokens() para vender todos los 5,896,508e18 i6 de vuelta al pool a cambio de 125,177,224e18 USDT. Dado que estos tokens i6 habían sido liquidados usando el TWAP desactualizado de aproximadamente 1.05159 USDT/i6, mientras se vendían contra un precio spot del pool que el atacante había elevado a alrededor de 15,528 USDT/i6, el atacante pudo realizar directamente el enorme diferencial entre los dos precios.

• Paso 6: Tras reembolsar el préstamo flash, el atacante retuvo 273,802e18 USDT, que fue el beneficio real del ataque.

Conclusión

La causa raíz es que una función que impacta el precio spot (invest()) y una función liquidada por TWAP (withdraw()) podían componerse dentro de una sola transacción, permitiendo que las dos vieran precios diferentes para el mismo estado del pool.

Para prevenir esta clase de falla, los protocolos que combinan interacciones AMM con precios diferidos deben evitar liquidar saldos a un TWAP en la misma transacción en que una función complementaria mueve el precio spot del pool subyacente, y en su lugar deben anclar los pagos al valor realizable en vivo del pool en lugar de un precio desactualizado o derivado.

4. Incidente del Protocolo Drift

Resumen

El 1 de abril de 2026 (UTC), el Protocolo Drift en Solana fue comprometido por aproximadamente $285.3M. La causa raíz no fue un error en el contrato inteligente sino una ruptura en el proceso de autorización multisig, agravada por un Consejo de Seguridad 2 de 5 con timelock cero y el mecanismo de nonce durable de Solana, que permitió que las aprobaciones multisig precolectadas permanecieran válidas indefinidamente hasta que el atacante eligiera ejecutarlas. Tras semanas de preparación, el atacante indujo a dos de cinco firmantes a pre-firmar transacciones de gobernanza maliciosas vinculadas a cuentas de nonce durable, las envió posteriormente para tomar el control administrativo, y luego introdujo un activo de garantía fabricado (CVT), infló su precio de oráculo, relajó los límites de retiro y drenó activos reales a través del Drift Vault (JCNCMF...XJfrw).

Antecedentes

Drift Protocol es un protocolo DeFi en Solana que soporta trading con margen, préstamos, mercados spot y derivados. Sus operaciones de alto privilegio, incluyendo cambios de administrador, creación de mercados, configuración de oráculos, actualizaciones de parámetros de riesgo y ajustes de límites de retiro, son gobernadas por el framework multisig de Squads en lugar de una sola clave privada. En el momento del ataque, el Consejo de Seguridad de Drift operaba bajo una configuración de umbral 2 de 5 con timelock cero, lo que significaba que cualquiera de los dos de los cinco firmantes podía autorizar acciones administrativas con efecto inmediato. La seguridad de este sistema depende no solo de la custodia de las claves de los firmantes, sino también de la integridad de toda la cadena de aprobación: qué transacción fue creada, qué creían los firmantes que estaban aprobando, y si las instrucciones ejecutadas finales coincidían con ese contexto de revisión.

Por separado, las cuentas de nonce durable de Solana reemplazan el blockhash de corta vida con un nonce persistente almacenado en una cuenta dedicada, lo que permite que una transacción firmada permanezca válida indefinidamente hasta que el nonce sea avanzado. Este mecanismo está diseñado para casos de uso legítimos como la firma fuera de línea y el envío diferido, pero introduce una primitiva de ataque crítica al desacoplar cuándo se firma una transacción de cuándo se ejecuta en la cadena. Una vez que un firmante aprueba una transacción de nonce durable, la aprobación no puede revocarse a menos que la autoridad del nonce avance manualmente la cuenta de nonce.

Análisis de la Vulnerabilidad

La causa raíz no es una vulnerabilidad en el contrato inteligente sino tres debilidades estructurales en la configuración de gobernanza de Drift que juntas convirtieron una oportunidad de ingeniería social en un drenaje de $285.3M. Primero, los nonces durables eliminaron la red de seguridad implícita de expiración de firma. En las transacciones normales basadas en blockhash, la aprobación de un firmante engañado se ejecuta rápidamente o expira de manera inofensiva dentro de una ventana estrecha, limitando el alcance de la explotación coordinada. Los nonces durables disuelven esta restricción: una vez que dos firmantes del Consejo de Seguridad fueron inducidos a aprobar transacciones de gobernanza maliciosas mediante solicitudes de firma engañosas, sus firmas permanecieron explotables indefinidamente, dando al atacante control total sobre el momento de ejecución.

Segundo, el timelock cero en las acciones administrativas significaba que una vez enviadas las transacciones pre-firmadas, la transferencia de administrador tomaba efecto de inmediato, sin dejar ninguna ventana de detección o intervención. Tercero, el alcance del rol de administrador era suficientemente amplio para crear nuevos mercados de garantías, cambiar fuentes de oráculos y relajar los límites de retiro en una sola vía privilegiada, por lo que una única toma de control de gobernanza exitosa fue suficiente para convertir un activo arbitrario en extracción real de fondos sin ninguna barrera de autorización adicional.

Análisis del Ataque

El ataque se desarrolló en tres fases distintas: Preparación Previa al Ataque, en la que el atacante ejecutó una operación de varias semanas para fabricar un activo de garantía falso y obtener acceso a la gobernanza mediante solicitudes de firma engañosas; Toma de Control de la Gobernanza, en la que dos transacciones de nonce durable pre-firmadas fueron enviadas en rápida sucesión para tomar el control administrativo; y Extracción de Fondos, en la que el atacante manipuló los parámetros del protocolo y drenó activos reales a través de las vías de préstamo del protocolo. El diagrama a continuación ilustra el flujo de ejecución a través de estas tres fases.

• Fase 1 (Preparación Previa al Ataque): A partir del 11 de marzo, el atacante retiró 10 ETH de Tornado Cash y desplegó CarbonVote Token (CVT), acuñando 750 millones de unidades, luego proporcionó liquidez en Raydium y usó wash trading para construir un historial de precios artificial cercano a $1. Paralelamente, para el 23 de marzo se habían creado cuatro cuentas de nonce durable, dos vinculadas a miembros del Consejo de Seguridad de Drift y dos controladas por el atacante, lo que indica que al menos dos de los cinco firmantes ya habían firmado transacciones vinculadas a cuentas de nonce durable. El 27 de marzo, Drift ejecutó una migración planificada del Consejo de Seguridad debido a un cambio de miembro, invalidando las firmas previamente recopiladas; sin embargo, para el 30 de marzo el atacante había obtenido nuevamente el umbral requerido bajo la nueva configuración, demostrando monitoreo activo de los cambios de gobernanza en cadena y adaptación en tiempo real.

• Fase 2 (Toma de Control de la Gobernanza): El 1 de abril aproximadamente a las 16:05 UTC, aproximadamente un minuto después de que Drift realizara un retiro de prueba legítimo del fondo de seguros, el atacante envió dos transacciones de nonce durable pre-firmadas con cuatro slots de diferencia. La primera transacción (2HvMSg...2C4H) creó y aprobó la propuesta maliciosa de transferencia de administrador. La segunda transacción (4BKBmA...RsN1) la aprobó y ejecutó, comenzando con AdvanceNonceAccount para activar el nonce almacenado, continuando a través de proposalApprove y vaultTransactionExecute, e invocando finalmente UpdateAdmin para transferir el control administrativo a una dirección controlada por el atacante.

• Fase 3 (Extracción de Fondos): Con plenos privilegios de administrador, el atacante creó un mercado de garantías para CVT, cambió a un oráculo controlado por el atacante para inflar su precio en libros, y aumentó o eliminó los límites de retiro en los principales mercados de activos. El atacante luego depositó una gran cantidad de CVT sobrevalorado en el protocolo y ejecutó 31 retiros rápidos en aproximadamente 12 minutos, drenando USDC, JLP, SOL, cbBTC, USDT, wETH, dSOL, WBTC, JTO y FARTCOIN por una pérdida total de aproximadamente $285.3M, calculada en función de la cuenta de retiro del atacante (HkGz4K...pZES).

Conclusión

La causa raíz de este incidente no es una vulnerabilidad en el contrato inteligente ni un compromiso de clave, sino una ruptura en el proceso de autorización multisig combinada con la ejecución diferida basada en nonce durable y una vía administrativa con timelock cero. Las aprobaciones precolectadas que normalmente habrían expirado en minutos permanecieron explotables indefinidamente, y una vez enviadas, la toma de control del administrador y la posterior extracción de fondos no dejaron ninguna ventana de intervención.

Mitigar esta clase de riesgo requiere asegurar toda la cadena de autorización y no solo la custodia de las claves de los firmantes, aplicar timelocks a las operaciones de alto privilegio, y tratar los mecanismos de ejecución diferida como los nonces durables como una superficie de amenaza distinta que exige umbrales de firma más altos, aprobaciones con límite de tiempo o revocables, y restricciones contra transacciones firmadas con validez indefinida.

5. Incidente del Protocolo LML Staking

Resumen

El 1 de abril de 2026, el protocolo de staking LML en BNB Chain fue explotado por aproximadamente $950K. La causa raíz fue una inconsistencia en la lógica de cálculo de recompensas: la conversión de recompensas leía un precio almacenado de LML/USDT bloqueado detrás de un período de enfriamiento de actualización de 3600 segundos, mientras que el LML pagado era reembolsable al precio AMM en vivo, sin ninguna comprobación de desviación entre los dos. El atacante utilizó préstamos flash para inflar el precio spot del pool y delegación de código EIP-7702 para reclamar recompensas por lotes para 11 EOAs pre-apostados en una sola transacción, recibiendo una cantidad desproporcionada de LML al precio almacenado desactualizado y vendiéndolo de vuelta a través del pool ahora gravemente distorsionado para obtener beneficios.

Antecedentes

LML es un protocolo de staking en BNB Chain donde los usuarios apuestan BNB a través del contrato APower para ganar tokens LML como recompensas. Las recompensas se calculan en términos de USDT y luego se convierten a cantidades de LML basadas en un precio LML/USDT almacenado por el protocolo antes de la distribución. El precio almacenado se actualiza mediante updatePrice(), que lee el precio spot del AMM pero impone un período de enfriamiento de 3600 segundos entre actualizaciones. Los reclamos de recompensas se activan a través de receive() de APower basándose en msg.sender, por lo que solo la dirección de staking original puede reclamar sus propias recompensas.

Análisis de la Vulnerabilidad

La falla principal en el contrato de staking (0xbe9713...adce19) es que la acumulación de recompensas y el canje de recompensas están anclados a dos precios diferentes del mismo pool sin ninguna comprobación de consistencia entre ellos. La fórmula de recompensa reward += (10^18 * base_reward) / stored_price calcula el pago en LML de _prices[], un precio LML/USDT almacenado por el protocolo que solo se actualiza mediante updatePrice() después de un período de enfriamiento de 3600 segundos, sin embargo el LML pagado es inmediatamente reembolsable al precio spot del AMM en vivo. Cualquier actividad externa que mueva el precio spot dentro de esta ventana de enfriamiento abre una brecha entre un precio de acumulación congelado y un precio de venta en vivo, y nada en el contrato rechaza un reclamo cuando esa brecha se vuelve irrazonable.

Una segunda falla estructural está en cómo se repone la fuente de recompensas. Cuando el saldo de LML del contrato PROOF es insuficiente para pagar un reclamo, swapBack() lo recarga llamando a super._transfer(swapPair, PROOF, deficit) seguido de sync(), moviendo directamente LML fuera de las reservas del par LP y realineando el estado almacenado del par en lugar de realizar un intercambio normal. Debido a que esta vía omite el descubrimiento de precios del par, cada reclamo que la activa reduce las reservas de LML del par y desplaza aún más el precio spot sin ninguna entrada compensatoria de tokens, por lo que los reclamos repetidos amplían mecánicamente la brecha entre el precio almacenado congelado y el precio de venta en vivo cuantos más reclamos se procesan.

Análisis del Ataque

El siguiente análisis se basa en las transacciones 0x805d...5b47, 0x70f7...3572.

• Paso 1: El atacante agregó una gran cantidad de USDT y WBNB a través de préstamos flash de Moolah, tomando prestado de Venus y Moolah Pool (usando WBNB como garantía), y préstamos flash de PancakeSwap V4, múltiples pools V3 y pools V2. Este capital era necesario para manipular el precio del par LML/USDT.

• Paso 2: El atacante llamó a swapAndTrans() en el contrato del token LML, que intercambió las comisiones de LML acumuladas en el contrato por USDT. Esto drenó el saldo de LML propio del contrato LML, lo que significa que ya no podía servir como fuente local de tokens; cualquier distribución posterior de recompensas necesitaría extraer LML del par LP a través de swapBack().

• Paso 3: El atacante intercambió USDT por LML a través de PancakeRouter swapExactTokensForTokensSupportingFeeOnTransferTokens, con el destinatario configurado como la dirección muerta. Los tokens LML comprados fueron quemados en lugar de ser recibidos por el atacante. El único propósito era drenar LML del par e inflar el precio de LML en el AMM; el atacante no necesitaba los tokens en sí, solo la distorsión del precio.

• Paso 4: El atacante había depositado previamente en el protocolo de staking usando 11 direcciones EOA. Dado que receive() de APower activa _claimReward(msg.sender) basándose en msg.sender, las recompensas solo pueden ser reclamadas por la propia dirección de depósito. Para reclamar recompensas para los 11 EOAs dentro de una sola transacción, el atacante usó EIP-7702 para establecer código en estos EOAs, permitiéndoles ser llamados como contratos por el contrato principal del atacante. Cada EOA ejecutó una función transfer(rst, fte) que envió una pequeña cantidad de BNB a APower, activando receive(), _claimReward(EOA). Dentro de cada reclamo: updatePrice() fue omitido (el período de enfriamiento de 3600s no se cumplió, por lo que stored_price se mantuvo en el valor histórico bajo), updateUser() calculó la recompensa usando el precio bajo desactualizado, sendMining() transfirió LML de PROOF a APower y luego activó swapBack() que repuso PROOF extrayendo LML del par LP y llamando a sync(), reduciendo aún más las reservas del par. Finalmente claimReward() distribuyó LML al EOA, y cada EOA transfirió su LML recibido de vuelta al contrato del atacante.

• Paso 5: El atacante intercambió el LML acumulado de vuelta a USDT a través del pool ahora gravemente drenado al precio extremadamente inflado.

• Paso 6: Se reembolsaron todos los préstamos flash, préstamos y comisiones. Se transfirió el beneficio restante.

Conclusión

La causa raíz es una discrepancia entre la acumulación y el canje de recompensas en el contrato de staking: los pagos se dimensionan a partir de un precio LML/USDT almacenado bloqueado detrás de un período de enfriamiento de 3600 segundos, pero se liquidan en LML cuyo valor real sigue el precio AMM en vivo, sin ninguna comprobación de desviación que los vincule. La vía de recarga swapBack() amplifica esta falla al drenar LML directamente del par LP en cada reclamo, ampliando mecánicamente la brecha entre el precio almacenado congelado y el precio de venta en vivo cuantos más reclamos se procesan.

Los protocolos de staking que dimensionan recompensas a partir de precios derivados del AMM deben aplicar una comprobación de desviación entre el precio almacenado y el precio spot actual en el momento del reclamo y revertir cuando la brecha supere un umbral seguro, y deben evitar mecanismos de recarga que muten las reservas del LP fuera de las vías normales de intercambio, ya que dichos mecanismos eluden el descubrimiento de precios que de otro modo limitaría el daño de los precios desactualizados.

6. Incidente de Tactile

Resumen

El 1 de abril de 2026, Tactile, un protocolo de depósito por niveles en Polygon, sufrió una pérdida de ~$12K. La causa raíz fue una inconsistencia en su lógica de liquidación de depósitos y retiros: tanto la entrada como la salida se convertían contra el precio spot actual de CES, y la participación interna no llevaba ningún registro del valor del activo al que fue acuñada originalmente. El atacante explotó esto inflando el precio spot antes de depositar para obtener participaciones excesivas, luego deprimiendo el precio antes de retirar para canjear más CES por participación, repitiendo el ciclo a través de contratos auxiliares para extraer beneficios.

Antecedentes

Tactile es un protocolo de depósito por niveles en Polygon donde los usuarios depositan CES en un contrato de pago según un nivel seleccionado. La cantidad de depósito requerida se calcula a partir del precio spot actual de CES y la configuración del nivel, y al usuario se le acredita una participación de contabilidad interna que representa su posición. Al retirar, la participación registrada se convierte de vuelta en CES usando el precio spot en el momento de la salida en lugar de liquidar contra la cantidad depositada originalmente, por lo que los saldos de los usuarios se rastrean efectivamente como unidades de contabilidad dependientes del precio en lugar de cantidades de activos fijas.

Análisis de la Vulnerabilidad

La falla principal en el contrato de pago (0x9153e1...09b654) es que el depósito y el retiro se liquidan contra el mismo oráculo de precio spot en dos momentos diferentes sin ningún ancla inmutable que los vincule. En el momento del depósito, el contrato lee getActualPrice() y convierte el CES depositado en una participación interna basada en el precio actual; en el momento del retiro, la misma participación se convierte de vuelta en CES usando el precio spot en el momento del canje.

Dado que la participación en sí no lleva ningún registro del precio o la cantidad de activos al que fue acuñada, cualquier movimiento del precio spot entre estos dos momentos se traduce directamente en una discrepancia entre el CES pagado y el CES pagado al salir, haciendo que la contabilidad del protocolo quede completamente expuesta a la trayectoria del precio en lugar del valor del activo subyacente.

Análisis del Ataque

El siguiente análisis se basa en la transacción 0xc321...da74.

• Paso 1: El atacante primero tomó prestado 55,365e18 CES de un pool flash de Uniswap V3 y distribuyó los fondos a 5 contratos auxiliares. Cada auxiliar primero recibió 6,426e18 CES, y luego llamó a deposit(12). Durante este proceso, cada auxiliar primero consultó getPriceForLevel(12) y luego preparó la cantidad de CES requerida para este depósito basándose en el precio actual.

• Paso 2: Después de que los 5 auxiliares completaron la primera ronda de deposit, el atacante volcó 300,000 CES en el DEX, empujando el precio utilizado por el bank desde 1.067585 hasta 0.688542. Los 5 auxiliares luego ejecutaron withdraw uno por uno, canjeando las participaciones creadas anteriormente al precio alto en CES al precio ahora más bajo. Cada auxiliar recibió 9,427e18 CES.

• Paso 3: Después de completar la primera ronda de withdraw, el atacante intercambió el activo de contraparte adquirido de vuelta en CES, empujando el precio hacia arriba nuevamente. El atacante luego repitió los Pasos 2-3.

• Paso 4: Finalmente, después de múltiples ciclos de ataque, y tras reembolsar el préstamo flash más la comisión flash de 166.097975017841805126 CES, al atacante le quedaron 567,736e18 CES como beneficio.

Conclusión

La causa raíz de este incidente es que Tactile liquidó tanto el depósito como el retiro contra un precio spot manipulable sin anclar la participación contable a la cantidad de activos o al precio en el momento del depósito, dejando su contabilidad interna completamente expuesta a cualquier movimiento de precio entre la entrada y la salida.

Los protocolos que emiten posiciones similares a participaciones contra un activo volátil deben anclar cada participación a la cantidad concreta de activos o al precio en el momento de la acuñación, de modo que el canje reproduzca el valor económico original en lugar de volver a valorar contra un oráculo en vivo. Donde las funciones de liquidación deben hacer referencia a un precio actual, deben usar fuentes ponderadas por tiempo u otras resistentes a la manipulación y evitar leer el mismo precio spot que puede ser movido por operaciones ejecutadas en la misma transacción que la llamada de liquidación.

7. Incidente del Token SAS

Resumen

El 2 de abril de 2026, el token SAS en BNB Chain fue explotado por ~$12K. La causa raíz fue una falla en la lógica de transferencia personalizada del token: enviar SAS al pool LP solo incrementaba un contador global sellBurn, y cualquier transferencia ordinaria posterior podía entonces quemar SAS directamente del pool y llamar a sync() para reescribir sus reservas, todo sin pasar por la lógica de intercambio del AMM. El atacante explotó esto acumulando sellBurn mediante ventas, activando una transferencia ordinaria no relacionada para quemar SAS del pool y empujar su reserva a 1 wei, y luego realizando un intercambio inverso con el SAS restante para obtener beneficios.

Antecedentes

SAS es un token deflacionario en BNB Chain con lógica de transferencia personalizada construida sobre un pool de PancakeSwap V2. Su función transfer() distingue entre dos vías: una vía de venta, activada cuando el destino de una transferencia es el pool LP, que incrementa un acumulador global sellBurn por la cantidad transferida; y una vía de transferencia ordinaria, que, cuando sellBurn es distinto de cero, quema SAS directamente del pool LP y luego llama a sync() para actualizar sus reservas al nuevo saldo en cadena. Las dos vías están destinadas a trabajar juntas como un mecanismo deflacionario que reduce la reserva de SAS del pool en respuesta a la presión de venta acumulada.

Análisis de la Vulnerabilidad

La falla principal en el contrato del token SAS (0xbfa266...3d91c6) está en cómo el mecanismo deflacionario está conectado a transfer(). Cuando SAS se envía al pool LP, el contrato incrementa un acumulador global sellBurn por la cantidad transferida. Luego, en cualquier transferencia ordinaria posterior, si sellBurn es distinto de cero, el contrato llama a _burnFromPair() para quemar SAS directamente del pool LP y lo sigue con sync(), que reescribe las reservas del pool para que coincidan con su saldo en cadena.

El problema es que esta vía de quema y sincronización reescribe las reservas del pool sin pasar por la lógica de intercambio del AMM. Una vez que sellBurn ha sido impulsado hacia arriba por transferencias al pool, una transferencia normal no relacionada es suficiente para activar la quema y sincronización, forzando la reserva de SAS del pool hacia cero y creando una gran distorsión de precio que luego puede ser aprovechada a través de un intercambio normal.

Análisis del Ataque

El siguiente análisis se basa en la transacción 0x878e...adc5.

• Paso 1: El atacante tomó prestado WBNB mediante un préstamo flash.

• Paso 2: El atacante intercambió WBNB por SAS.

  

• Paso 3: El atacante desplegó un contrato y ejecutó la lógica de ataque en constructor(). Esto se usó para eludir la comprobación is_contract() del protocolo, ya que el contrato del token requería que from en transfer() fuera una dirección en la lista blanca o un EOA.

• Paso 4: El atacante transfirió SAS al pool, lo que activó la vía de venta y acumuló sellBurn.

• Paso 5: El atacante desplegó un segundo contrato y, de nuevo dentro de su constructor(), inició una transferencia ordinaria. Con sellBurn ya distinto de cero desde el Paso 4, esta transferencia activó la función _burnFromPair(), que quemó SAS directamente del pool LP y luego llamó a la función sync(), reduciendo la reserva de SAS a 1 wei.

• Paso 6: El atacante realizó un intercambio inverso y vendió el SAS restante para obtener beneficios.

Conclusión

La causa raíz de este incidente es una falla en la lógica de transferencia personalizada del token SAS: una transferencia ordinaria podía quemar directamente SAS del pool LP y sincronizar sus reservas al saldo reducido, permitiendo que la actividad de venta acumulada se convirtiera en una reducción arbitraria de la reserva de SAS del pool y, a partir de ahí, en una gran distorsión de precio que luego podía ser aprovechada a través de un intercambio normal.

Los tokens no deben acceder a un pool AMM externo y mutar sus reservas fuera de las vías normales de intercambio. Si un diseño deflacionario realmente requiere quemar desde un pool, la quema y el sync() acompañante deben estar vinculados a un activador interno estrictamente controlado, como un guardián de confianza o un cronograma con límite de tasa, en lugar de acoplarse a transferencias de usuario arbitrarias.

8. Incidente Unknown-EIP-7702

Resumen

El 3 de abril de 2026, una cuenta de usuario en BNB Chain que había habilitado código delegado mediante EIP-7702 fue drenada por ~$17.2K. El código delegado exponía una función pancakeV3SwapCallback() sin control de acceso adecuado. El atacante llamó directamente a este callback con calldata manipulado, forzando a la cuenta víctima a transferir sus tokens a una dirección controlada por el atacante.

Antecedentes

La EOA víctima usó una transacción de Tipo 4 de EIP-7702 para establecer código delegado de modo que la cuenta pudiera ejecutar lógica relacionada con intercambios. Sin embargo, la implementación delegada incluía una función pública pancakeV3SwapCallback() que estaba destinada a ser llamada solo durante un callback legítimo del pool PancakeSwap V3.

Análisis de la Vulnerabilidad

La causa raíz es la ausencia de control de acceso en la función pancakeV3SwapCallback() del contrato delegado (0x02C809...aEDbAE).

En un diseño correcto de callback UniswapV3/PancakeV3, el callback debe verificar que msg.sender sea el pool canónico esperado (derivado de factory + par de tokens + comisión, o verificado contra una lista de pools de confianza). En este caso, esa validación estaba ausente, por lo que cualquier llamante externo podía invocar el callback directamente.

Dado que el callback ejecuta transferencias de tokens desde la cuenta que lo aloja, la comprobación de msg.sender faltante significa que cualquier llamada externa que lleve amount0Delta/amount1Delta positivos entra en la vía de pago dentro del callback y mueve tokens fuera de la cuenta víctima, sin que se realice ningún intercambio real.

Análisis del Ataque

El siguiente análisis se basa en la transacción 0x5b2c...4261.

• Paso 1: El atacante llamó directamente a pancakeV3SwapCallback() con parámetros manipulados, activando la lógica de transferencia del callback para mover los tokens de la víctima a direcciones controladas por el atacante.

Conclusión

Este incidente fue causado por desplegar lógica de callback de intercambio en una cuenta EIP-7702 sin autenticación estricta del callback. Debido a que pancakeV3SwapCallback() carecía de control de acceso, el callback podía ser invocado por cualquier llamante externo y usado para mover tokens fuera de la cuenta víctima sin que ocurriera nunca un intercambio legítimo.

Para cualquier contrato o código EIP-7702 delegado que implemente callbacks de estilo V3, los desarrolladores deben validar que msg.sender es el pool PancakeV3 canónico (derivado de la factory de confianza, el par de tokens y el nivel de comisión) antes de que el callback entre en cualquier lógica de transferencia.

9. Incidente de Silo Finance

Resumen

El 3 de abril de 2026, el vault soUSDC de Silo Finance en Arbitrum fue explotado por aproximadamente $359K. La causa raíz fue la convergencia de tres defectos: un oráculo de wstUSR inmutable que seguía valorando el token a ~1.133 incluso después de que su precio de mercado había caído a ~0.12, un mecanismo de límite de suministro en soUSDC que solo restringía los depósitos propios del vault pero no los externos, y una falla de contabilidad en totalAssets() que contaba las participaciones de bUSDC acreditadas externamente sin acuñar las correspondientes participaciones de soUSDC. Al depositar USDC directamente en el mercado de wstUSR de límite cero con receiver=soUSDC, el atacante infló el precio de participación del vault, tomó prestado el mismo USDC de vuelta contra garantía de wstUSR sobrevalorada, y canjeó participaciones de soUSDC previamente adquiridas a la valoración inflada, con el déficit extraído de otros mercados sanos en la cola de retiro.

Antecedentes

Silo Finance es un protocolo de préstamos de riesgo aislado en Arbitrum. Cada mercado Silo es un par de préstamos de dos lados (p. ej., wstUSR/USDC): los prestatarios depositan garantía (wstUSR) y toman prestado el activo de préstamo (USDC), mientras que los prestamistas depositan USDC y ganan intereses. Cuando un prestamista deposita USDC en un mercado específico, recibe el token de participación de depósito de ese mercado. Cuando un prestatario deposita garantía, recibe un token de participación de garantía (p. ej., bwstUSR-149).

soUSDC es un SiloVault que se asienta sobre múltiples mercados Silo para agregar préstamos de USDC. Los usuarios depositan USDC en soUSDC y reciben participaciones de soUSDC. El vault luego enruta el USDC depositado hacia los mercados Silo aprobados según los límites de suministro establecidos por el asignador, y el vault mismo mantiene las participaciones de bUSDC de cada mercado en el que ha depositado. Cuando un usuario canjea participaciones de soUSDC, el vault calcula cuánto USDC valen las participaciones usando totalAssets(), que itera cada mercado en la cola de retiro y suma el saldo de participaciones de bUSDC del vault en cada uno. El vault luego retira USDC de sus mercados subyacentes para pagar al canjeador.

wstUSR (Staked USR Envuelto) es un derivado de staking del stablecoin USR emitido por Resolv. Después de que Resolv fue explotado, USR perdió su paridad, stUSR también perdió su paridad, y el precio de mercado secundario de wstUSR cayó a ~0.12. Sin embargo, el feed de Chainlink para wstUSR solo rastreaba la tasa de cambio wstUSR/stUSR (~1.133), y el protocolo asumía implícitamente que 1 stUSR = 1 USD, por lo que el oráculo continuaba valorando wstUSR a ~1.133, una brecha de ~10x respecto a la realidad del mercado.

Análisis de la Vulnerabilidad

La dirección del oráculo del mercado wstUSR/USDC está codificada como inmutable en SiloConfig y no puede ser reemplazada. El propio contrato del oráculo (0x836a1a...04425e) es un ChainlinkV3Oracle cuyo feed de Chainlink subyacente (descripción: "Tasa de Cambio wstUSR / stUSR") solo rastrea la relación de envoltorio de wstUSR a stUSR (~1.133), no el precio de mercado secundario. El protocolo asume implícitamente que 1 stUSR = 1 USD, por lo que valora wstUSR a ~1.133. Después de que USR perdió su paridad, stUSR también perdió la suya y wstUSR cayó a ~0.12 en el mercado abierto, pero el oráculo continuó reportando ~1.133, una sobrevaloración de ~10x.

El protocolo era parcialmente consciente del riesgo: el límite de suministro de soUSDC para el mercado wstUSR se estableció en 0, lo que significa que el vault nunca enrutaría voluntariamente USDC hacia él. Sin embargo, este límite solo rige las propias llamadas de deposit() salientes del vault. Dado que wstUSR_Market.deposit() acepta un parámetro receiver arbitrario, cualquiera puede depositar USDC directamente en el mercado wstUSR y acreditar las participaciones de bUSDC resultantes a la dirección de soUSDC, eludiendo completamente el límite de suministro.

Esto crea la vía de explotación principal. Cuando las participaciones de bUSDC llegan al saldo de soUSDC a través de dicho depósito externo, totalAssets() las cuenta: itera cada mercado en la cola de retiro y lee el saldo real de participaciones del vault, sin ninguna comprobación de si la posición fue ingresada voluntariamente. Mientras tanto, no se acuñan nuevas participaciones de soUSDC para estas posiciones acreditadas externamente, porque la propia lógica de acuñación del vault nunca fue invocada. El resultado es que totalAssets aumenta mientras que totalShares permanece igual, inflando el precio de participación de soUSDC.

Análisis del Ataque

El siguiente análisis se basa en la transacción 0xf77a...f3e1.

El atacante primero compró wstUSR en el mercado secundario a ~0.12 por token.

• Paso 1: Préstamo flash de ~4,236,352 USDC de Morpho. La mala valoración del oráculo por sí sola no es suficiente: el mercado wstUSR tenía cero liquidez de USDC (cap=0, soUSDC nunca depositó allí), por lo que no hay nada que tomar prestado contra la garantía sobrevalorada. El préstamo flash proporciona el capital necesario para los pasos posteriores de depósito y donación.

• Paso 2: Depositar wstUSR en el mercado wstUSR como garantía y recibir bwstUSR-149. Esta es la preparación para el préstamo del Paso 5: el oráculo valora 13,797 wstUSR a ~15,633 (a 1.133 cada uno), aunque el atacante solo pagó ~1,656.

• Paso 3: Depositar ~4,222,007 USDC en el vault soUSDC, recibiendo participaciones de soUSDC (~91.5% del suministro total). El vault enruta este USDC hacia los mercados sanos existentes (no el mercado wstUSR, ya que cap=0). Estas participaciones de soUSDC son el instrumento para extraer beneficios en el Paso 6: cuantas más participaciones tenga el atacante, más se beneficia cuando el precio de participación es inflado.

• Paso 4: Depositar ~14,344 USDC directamente en el mercado wstUSR a través de wstUSR_Market.deposit(receiver=soUSDC) y acuñar bUSDC-149 para soUSDC. Las participaciones de bUSDC resultantes se acreditan a la dirección de soUSDC, no a la del atacante. Esta es la manipulación principal: totalAssets() de soUSDC ahora incluye estas participaciones de bUSDC a valor nominal (~14,344 USDC), pero no se acuñan nuevas participaciones de soUSDC porque la propia lógica de depósito del vault nunca fue invocada: totalAssets sube, totalShares permanece igual, y el precio de participación de soUSDC se infla. Al mismo tiempo, esto crea liquidez de USDC en el mercado wstUSR anteriormente vacío, que es necesaria para el siguiente paso.

• Paso 5: Tomar prestado ~14,344 USDC del mercado wstUSR usando la garantía depositada en el Paso 2. El oráculo valora la garantía a ~15,633, por lo que con un maxLTV del 92% el atacante puede tomar prestado ~14,344. Esto recupera el USDC donado en el Paso 4: el préstamo y la donación son neutros en efectivo. Pero el mercado wstUSR ahora está completamente drenado: todo el USDC ha sido prestado, dejando solo un préstamo pendiente respaldado por garantía de wstUSR casi sin valor. soUSDC aún mantiene las participaciones de bUSDC a valor nominal en totalAssets().

• Paso 6: Canjear todas las participaciones de soUSDC adquiridas en el Paso 3. El precio de participación ahora está inflado por la donación del Paso 4, por lo que el atacante recibe ~4,235,143 USDC, ~13,136 más que los 4,222,007 depositados en el Paso 3. El vault intenta retirar del mercado wstUSR pero encuentra cero liquidez (prestada en el Paso 5), por lo que extrae el déficit de otros mercados sanos en la cola de retiro. Aquí es donde se materializa la pérdida: USDC real de los mercados de otros depositantes de soUSDC se transfiere para cubrir el canje inflado.

• Paso 7: Reembolsar el préstamo flash.

Después de 32 bucles, soUSDC se queda con posiciones de bUSDC en el mercado wstUSR valoradas a ~359K pero respaldadas por garantía de wstUSR que vale una fracción de eso: utilización del 100%, deuda incobrable efectivamente irrecuperable soportada por los depositantes restantes de soUSDC.

Conclusión

Este incidente fue causado por la convergencia de un oráculo que rastreaba una tasa de cambio de staking en lugar del precio de mercado de un activo que perdió su paridad, un sistema de contabilidad de vault que contaba posiciones acreditadas externamente en totalAssets() sin acuñar las participaciones correspondientes, y un mecanismo de límite de suministro que solo restringía los depósitos propios del vault pero no los externos. Que la dirección del oráculo fuera inmutable en SiloConfig impidió cualquier corrección de emergencia una vez que el problema se hizo evidente.

Los protocolos de vault que agregan entre mercados de préstamos deben asegurarse de que totalAssets() solo contabilice las posiciones que el vault ingresó a través de sus propias operaciones de depósito, no los saldos de participaciones acreditados externamente. Las direcciones de los oráculos no deben ser permanentemente inmutables; deben existir mecanismos de gobernanza de emergencia para las actualizaciones de feeds de precios cuando los activos subyacentes pierden su paridad.

Acerca de BlockSec

BlockSec es un proveedor integral de seguridad blockchain y cumplimiento de criptomonedas. Desarrollamos productos y servicios que ayudan a los clientes a realizar auditorías de código (incluyendo contratos inteligentes, blockchain y carteras), interceptar ataques en tiempo real, analizar incidentes, rastrear fondos ilícitos y cumplir con las obligaciones AML/CFT, a lo largo de todo el ciclo de vida de los protocolos y plataformas.

BlockSec ha publicado múltiples artículos de seguridad blockchain en conferencias de prestigio, ha reportado varios ataques de día cero en aplicaciones DeFi, ha bloqueado múltiples hackeos para rescatar más de 20 millones de dólares, y ha 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