~$1.6M Perdidos: Exploits de Moke Token y LpdFi | BlockSec Semanal

Durante la semana pasada (2026/08/03 - 2026/08/09), se destacan los siguientes 2 incidentes de seguridad notables, con pérdidas totales aproximadas de $1.6M.

• LpdFi fue seleccionado porque ilustra el riesgo sistémico de utilizar reservas AMM manipulables tanto para la valoración de posiciones como para el cobro de intereses. El atacante primero infló el capital registrado mediante manipulación del precio spot, luego alteró las reservas del pool a través de una donación directa y sync() para hacer ejecutable el cobro de intereses sobredimensionado. Destaca la importancia de validar la solvencia a lo largo del ciclo de vida completo de la posición, en lugar de tratar la valoración del depósito, el cálculo de intereses y el cobro como operaciones independientes.
• Moke Token fue seleccionado porque demuestra cómo las vulnerabilidades en mecanismos de contabilidad separados pueden combinarse en un único ataque rentable. El atacante manipuló un precio spot para inflar la cantidad de MOKE reclamable, duplicó los registros de recompensas LP sincronizando los mismos tokens LP en múltiples direcciones, y convirtió los tokens resultantes en BNB extraíble a través del sistema de dividendos. Destaca la importancia de utilizar fuentes de precio resistentes a la manipulación y mantener la contabilidad de recompensas sincronizada con la propiedad real de los tokens.

Destacado de la Semana: Protocolo LpdFi

Este incidente se destaca porque el mismo estado AMM manipulable gobernaba tanto la creación de pasivos como el cobro de activos. Muestra por qué un protocolo debe validar la solvencia a lo largo del ciclo de vida completo de la posición, y no tratar la valoración del depósito, la acumulación de intereses y el cobro como pasos independientes.

El 3 de agosto de 2026, el protocolo LpdFi en BNB Chain fue explotado por aproximadamente $697K, drenados del par LPD/USDC de PancakeSwap. LpdFi derivaba tanto el valor registrado de una posición como su posterior pago de intereses del mismo par activo de PancakeSwap, por lo que manipular dicho par distorsionaba ambos. El atacante abrió una posición valorada muy por encima de su valor real, esperó a que se acumularan intereses y luego desplazó las reservas del par para que el cobro de intereses sobredimensionado pudiera ejecutarse, drenando casi toda la liquidez que el protocolo mantenía.

Antecedentes

LpdFi es un protocolo de rendimiento construido alrededor del token LPD. Un usuario crea una posición depositando LPD. En el momento del depósito, el protocolo valora el depósito utilizando el precio spot actual de LPD/USDC en PancakeSwap y almacena el resultado como uAmount, un capital denominado en USD para la orden. La orden acumula intereses por emisión, donde cada emisión es un período contable diario, y el protocolo limita el interés total de cada orden al capital registrado.

Cuando un usuario reclama intereses, el protocolo convierte el interés contable en USDC eliminando liquidez del par LPD/USDC mediante tokens LP en posesión de LpdFi. El USDC cobrado se divide luego entre el reclamante y la dirección de comisiones. Ambos extremos del ciclo de vida de la posición, la valoración en el depósito y el pago en el cobro, leen del mismo par activo de PancakeSwap.

Análisis de la Vulnerabilidad

Los contratos con errores son 0xce6a...f295e y 0x3876...273604.

La causa raíz es que LpdFi utilizó el precio spot activo y las reservas de LPD/USDC como fuente de verdad tanto para la contabilidad de órdenes como para el cobro de intereses. Ningún valor es seguro de confiar: ambos se derivan de reservas del par que un llamante con suficiente liquidez temporal puede mover dentro de una sola transacción.

En el depósito, buy() calcula la cantidad de tokens a partir de token.price():

LPD.price() lee las reservas LPD/USDC directamente a través de getReserves(), por lo que el capital registrado se mueve con el precio spot:

En el cobro, claimInterest() paga el interés acumulado llamando a removeLp():

removeLp() calcula cuántos tokens LP quemar a partir de la reserva activa r1 (o r0):

Como resultado, se rompen dos invariantes. Primero, dado que el capital registrado se deriva del precio spot, se puede registrar un capital mucho mayor que el valor real del depósito, lo que eleva el límite de intereses. Segundo, dado que removeLp() dimensiona la quema de LP a partir de la reserva activa, el número de tokens LP que el protocolo debe quemar para satisfacer un pago de USDC determinado depende de un valor de reserva que no está fijado en el momento del cobro.

Análisis del Ataque

El siguiente análisis se basa en las transacciones 0xbb5b85...41c3588 y 0x70bbe0...b3315d6.

• Paso 1: En el bloque 113613923, el atacante utilizó fondos obtenidos mediante préstamo flash para realizar un gran intercambio de USDC a LPD en el par LPD/USDC. Esto redujo la reserva de LPD del pool y elevó el precio spot devuelto por LPD.price().

• Paso 2: Mientras el precio estaba inflado, el atacante llamó a buy() para abrir una orden sobredimensionada. Valorado al precio spot manipulado, el depósito fue registrado con un capital en USD de 140,324,732.

• Paso 3: En el siguiente bloque, 113613924, el atacante cruzó el límite de emisión del protocolo. Aunque solo pasó un bloque, el protocolo trata cada cambio de emisión como un período contable diario, por lo que un período de interés sobre el capital inflado se volvió reclamable.

• Paso 4: En la transacción de cobro, el atacante tomó prestados 730,607.755349 USDC a través de PoolManager, transfirió 3,440.992868 USDC directamente al par LPD/USDC y llamó a sync(). Bajo el estado original de las reservas, el interés inflado habría requerido más tokens LP de los que LpdFi poseía, por lo que el cobro habría revertido. Al elevar la reserva de USDC registrada del par de 718,619.888284 a 722,060.881152, el atacante redujo la cantidad de LP que removeLp() necesitaba quemar, situándola dentro del saldo real de LP del protocolo.

• Paso 5: El atacante llamó a claimInterest(0). El capital inflado produjo 701,623.66 USDC de interés reclamable por una emisión. Tras la manipulación de las reservas, removeLp() solo necesitaba quemar 1,678,049.359669 tokens LP, casi exactamente el saldo LP completo en posesión de LpdFi. El protocolo quemó aproximadamente el 97% del suministro total de LP, transfirió 693,529.790711 USDC al atacante, y el atacante reembolsó el préstamo flash y extrajo el beneficio.

Conclusión

Este incidente se originó por el uso de reservas spot AMM manipulables como fuente de verdad tanto para la contabilidad de órdenes como para el cobro. La valoración y el cobro fueron tratados como operaciones independientes que leían el mismo pool activo, por lo que un capital registrado a un precio manipulado nunca fue reconciliado con el respaldo real del pool.

El protocolo no debería utilizar reservas AMM activas como fuente de verdad para el capital de las órdenes ni para la contabilidad de retiros. Los diseños más seguros valoran cada depósito a través de una fuente de precio resistente a la manipulación, como un precio promedio ponderado en el tiempo con verificaciones de actualidad y desviación, en lugar de una valoración spot, y aplican una verificación de solvencia antes del cobro para que un reclamo nunca pueda quemar más respaldo del que la posición realmente aportó.

Más Incidentes de Esta Semana

Moke Token

El 3 de agosto de 2026, Moke Token en BNB Chain fue explotado por aproximadamente $906K mediante dependencia del precio spot combinada con contabilidad LP duplicada. El atacante manipuló un precio spot para inflar la cantidad de MOKE reclamable, lo transfirió al contrato de dividendos LP, activó el proceso de dividendos para vender el MOKE por BNB, y luego recaudó ese BNB a través de registros LP duplicados.

Antecedentes

Moke Token es un ecosistema en BNB Chain construido alrededor de la participación de usuarios, la liberación diferida de MOKE, recompensas LP e incentivos de referidos. Los usuarios participan con USDT y AC. En lugar de recibir MOKE de inmediato, cada participación otorga una futura liberación de MOKE gestionada por MokeRelease, que se vuelve reclamable con el tiempo.

Cuando un usuario reclama, el contrato convierte el valor en USDT liberado en MOKE utilizando el precio liquidado de MOKE/USDT, y luego transfiere el MOKE correspondiente del pool de reservas al usuario. Estos tokens liberados están restringidos por defecto y solo pueden transferirse a direcciones autorizadas, como contratos utilizados para agregar liquidez. Los usuarios que poseen tokens LP reciben distribuciones de BNB de los pools de impuestos y dividendos del protocolo según su participación en LP.

Análisis de la Vulnerabilidad

Los contratos con errores son 0x684d...b302a7 y 0x5ae5...eba377.

La primera causa raíz es la dependencia del precio spot. getMokeUsdtPrice() deriva el precio MOKE/USDT de los pares WBNB/USDT y WBNB/MOKE, sin una fuente de precio resistente a la manipulación:

La segunda causa raíz es la contabilidad LP duplicada. _syncUserLP() registra el saldo LP de un usuario leyendo lpToken.balanceOf(user) en userLPRecord[user]. Dado que la actualización se activa manualmente y está codificada solo con el saldo actual, los mismos tokens LP pueden moverse entre múltiples direcciones y sincronizarse en cada una, inflando el saldo LP total registrado y las recompensas de dividendos que genera:

Análisis del Ataque

El siguiente análisis se basa en las transacciones 0xc0f1df...e26154 y 0x077604...756a8f.

• Paso 1: Aproximadamente 10 días antes del exploit, el atacante preparó cuota de liberación depositando USDT a través de la función participate en MokeVault, obteniendo una cuota de liberación de MOKE equivalente a 45,000 USDT que se desbloqueaba al 5.5% diario.

• Paso 2: El atacante acuñó tokens LP MOKE/WBNB y llamó a syncUserLP en MokeLPDividend para registrar el saldo LP, luego transfirió los mismos tokens LP a otra dirección y repitió la sincronización, creando registros LP duplicados para un mismo conjunto de tokens.

• Paso 3: El atacante utilizó préstamos flash para tomar prestada una gran cantidad de BNB y la intercambió por USDT en el par WBNB/USDT, elevando el precio spot de USDT. Luego, el atacante actualizó el precio de MOKE en MokeRelease, y el precio liquidado de MOKE cayó drásticamente.

• Paso 4: Con el precio de MOKE manipulado en su lugar, el atacante llamó a claim en MokeRelease y canjeó una cuota equivalente a 24,766 USDT por tokens MOKE, recibiendo muchos más MOKE de los que correspondían al valor real de la cuota.

• Paso 5: El atacante transfirió el MOKE liberado al contrato MokeLPDividend incluido en la lista blanca y llamó a distributeDividend, que vendió el MOKE por BNB. Luego, el atacante utilizó las direcciones que habían registrado saldos LP duplicados para llamar a claimDividend y recaudar el BNB distribuido, recibiendo un total de 1,546 BNB.

Conclusión

Moke Token combinó dos fallos independientes: un precio spot que podía moverse con un préstamo flash, y una contabilidad de dividendos que contabilizaba los mismos tokens LP más de una vez. Ninguno por sí solo habría sido tan dañino como ambos juntos.

Los protocolos deben evitar los precios spot instantáneos para cálculos sensibles a la seguridad y utilizar en su lugar una fuente resistente a la manipulación. Cualquier contabilidad basada en saldos de tokens debe actualizarse junto con los propios cambios de saldo, para que los mismos tokens no puedan contabilizarse en múltiples direcciones.