~$1,6M Perdidos: Exploits nos Tokens Moke e LpdFi | BlockSec Semanal

Durante a semana passada (2026/08/03 - 2026/08/09), os seguintes 2 incidentes de segurança notáveis são destacados, envolvendo aproximadamente $1,6M em perdas totais.

• LpdFi foi selecionado porque ilustra o risco sistêmico de usar reservas AMM manipuláveis tanto para a valoração de posições quanto para o resgate de juros. O atacante primeiro inflou o principal registrado por meio de manipulação de preço spot, depois alterou as reservas do pool por meio de uma doação direta e sync() para tornar a cobrança excessiva de juros executável. Destaca a importância de validar a solvência ao longo de todo o ciclo de vida da posição, em vez de tratar a valoração do depósito, o cálculo de juros e o resgate como operações independentes.
• Moke Token foi selecionado porque demonstra como vulnerabilidades em mecanismos de contabilidade separados podem ser combinadas em um único ataque lucrativo. O atacante manipulou um preço spot para inflar a quantidade de MOKE reivindicável, duplicou registros de recompensas de LP sincronizando os mesmos tokens LP em vários endereços, e converteu os tokens resultantes em BNB extraível por meio do sistema de dividendos. Destaca a importância de usar fontes de preço resistentes à manipulação e manter a contabilidade de recompensas sincronizada com a propriedade real dos tokens.

Destaque da Semana: Protocolo LpdFi

Este incidente é destacado porque o mesmo estado AMM manipulável governava tanto a criação de passivos quanto o resgate de ativos. Ele mostra por que um protocolo deve validar a solvência ao longo de todo o ciclo de vida da posição, e não tratar a valoração do depósito, o acúmulo de juros e o resgate como etapas independentes.

Em 3 de agosto de 2026, o protocolo LpdFi na BNB Chain foi explorado em aproximadamente $697K, drenados do par LPD/USDC da PancakeSwap. O LpdFi derivava tanto o valor registrado de uma posição quanto o pagamento de juros subsequente do mesmo par PancakeSwap em tempo real, portanto, manipular esse par distorcia ambos. O atacante abriu uma posição valorada muito acima do seu valor real, aguardou o acúmulo de juros, depois deslocou as reservas do par para que a cobrança excessiva de juros pudesse ser paga, drenando quase toda a liquidez que o protocolo detinha.

Contexto

LpdFi é um protocolo de rendimento construído em torno do token LPD. Um usuário cria uma posição depositando LPD. No momento do depósito, o protocolo valoriza o depósito usando o preço spot atual do par LPD/USDC da PancakeSwap e armazena o resultado como uAmount, um principal denominado em USD para a ordem. A ordem acumula juros por emissão, onde cada emissão é um período contábil diário, e o protocolo limita o total de juros de cada ordem em relação ao principal registrado.

Quando um usuário reivindica juros, o protocolo converte os juros contábeis em USDC removendo liquidez do par LPD/USDC usando tokens LP mantidos pelo LpdFi. O USDC resgatado é então dividido entre o reivindicante e o endereço de taxa. Ambas as extremidades do ciclo de vida da posição, valoração no depósito e pagamento no resgate, leem portanto do mesmo par PancakeSwap em tempo real.

Análise da Vulnerabilidade

Os contratos com falha são 0xce6a...f295e e 0x3876...273604.

A causa raiz é que o LpdFi usava o preço spot e as reservas em tempo real do par LPD/USDC como fonte da verdade tanto para a contabilidade de ordens quanto para o resgate de juros. Nenhum valor é seguro para confiar: ambos são derivados das reservas do par que um chamador com liquidez temporária suficiente pode mover dentro de uma única transação.

No depósito, buy() calcula o valor do token a partir de token.price():

LPD.price() lê as reservas LPD/USDC diretamente por meio de getReserves(), portanto o principal registrado se move com o preço spot:

No resgate, claimInterest() paga os juros acumulados chamando removeLp():

removeLp() calcula quantos tokens LP queimar a partir da reserva em tempo real r1 (ou r0):

Dois invariantes se quebram como resultado. Primeiro, como o principal registrado é derivado do preço spot, pode ser registrado um principal muito maior do que o valor real do depósito, o que eleva o limite de juros. Segundo, como removeLp() dimensiona a queima de LP a partir da reserva em tempo real, o número de tokens LP que o protocolo deve queimar para satisfazer um determinado pagamento em USDC depende de um valor de reserva que não está fixado no momento da reivindicação.

Análise do Ataque

A análise a seguir é baseada nas transações 0xbb5b85...41c3588 e 0x70bbe0...b3315d6.

• Passo 1: No bloco 113613923, o atacante usou fundos obtidos via flash loan para realizar uma grande troca de USDC por LPD no par LPD/USDC. Isso reduziu a reserva de LPD do pool e elevou o preço spot retornado por LPD.price().

• Passo 2: Enquanto o preço estava inflado, o atacante chamou buy() para abrir uma ordem superdimensionada. Valorado pelo preço spot manipulado, o depósito foi registrado com um principal em USD de 140.324.732.

• Passo 3: No bloco seguinte, 113613924, o atacante cruzou o limite de emissão do protocolo. Embora apenas um bloco tenha passado, o protocolo trata cada mudança de emissão como um período contábil diário, portanto um período de juros sobre o principal inflado tornou-se reivindicável.

• Passo 4: Na transação de reivindicação, o atacante tomou emprestado 730.607,755349 USDC por meio do PoolManager, transferiu 3.440,992868 USDC diretamente para o par LPD/USDC e chamou sync(). No estado original das reservas, os juros inflados teriam exigido mais tokens LP do que o LpdFi detinha, portanto o resgate reverteria. Ao elevar a reserva de USDC registrada do par de 718.619,888284 para 722.060,881152, o atacante reduziu a quantidade de LP que removeLp() precisava queimar, trazendo-a para dentro do saldo real de LP do protocolo.

• Passo 5: O atacante chamou claimInterest(0). O principal inflado produziu 701.623,66 USDC de juros reivindicáveis para uma emissão. Após a manipulação das reservas, removeLp() precisou queimar apenas 1.678.049,359669 tokens LP, quase exatamente o saldo total de LP mantido pelo LpdFi. O protocolo queimou cerca de 97% do suprimento total de LP, transferiu 693.529,790711 USDC para o atacante, e o atacante reembolsou o flash loan e retirou o lucro.

Conclusão

Este incidente decorreu do uso de reservas spot AMM manipuláveis como fonte da verdade tanto para a contabilidade de ordens quanto para o resgate. A valoração e o resgate foram tratados como operações independentes lendo o mesmo pool em tempo real, portanto um principal registrado a um preço manipulado nunca foi reconciliado com o respaldo real do pool.

O protocolo não deve usar reservas AMM em tempo real como fonte da verdade para o principal de ordens ou contabilidade de saques. Designs mais seguros valoram cada depósito por meio de uma fonte de preço resistente à manipulação, como um preço médio ponderado pelo tempo com verificações de atualidade e desvio, em vez de uma valoração spot, e impõem uma verificação de solvência antes do resgate para que uma reivindicação nunca possa queimar mais respaldo do que a posição genuinamente contribuiu.

Mais Incidentes Esta Semana

Moke Token

Em 3 de agosto de 2026, o Moke Token na BNB Chain foi explorado em aproximadamente $906K por meio de dependência de preço spot combinada com contabilidade de LP duplicada. O atacante manipulou um preço spot para inflar a quantidade de MOKE reivindicável, transferiu-o para o contrato de dividendos de LP, acionou o processo de dividendos para vender o MOKE por BNB, e então coletou esse BNB por meio de registros de LP duplicados.

Contexto

O Moke Token é um ecossistema da BNB Chain construído em torno da participação dos usuários, liberação diferida de MOKE, recompensas de LP e incentivos de indicação. Os usuários participam com USDT e AC. Em vez de receber MOKE imediatamente, cada participação concede uma futura liberação de MOKE gerenciada pelo MokeRelease, que se torna reivindicável ao longo do tempo.

Quando um usuário reivindica, o contrato converte o valor em USDT liberado em MOKE usando o preço liquidado de MOKE/USDT, depois transfere o MOKE correspondente do pool de reserva para o usuário. Esses tokens liberados são restritos por padrão e só podem ser transferidos para endereços de handlers autorizados, como contratos usados para adicionar liquidez. Os usuários que detêm tokens LP recebem então distribuições de BNB dos pools de taxas e dividendos do protocolo com base em sua participação de LP.

Análise da Vulnerabilidade

Os contratos com falha são 0x684d...b302a7 e 0x5ae5...eba377.

A primeira causa raiz é a dependência de preço spot. getMokeUsdtPrice() deriva o preço de MOKE/USDT dos pares WBNB/USDT e WBNB/MOKE, sem fonte de preço resistente à manipulação:

A segunda causa raiz é a contabilidade de LP duplicada. _syncUserLP() registra o saldo de LP de um usuário lendo lpToken.balanceOf(user) em userLPRecord[user]. Como a atualização é acionada manualmente e codificada apenas no saldo atual, os mesmos tokens LP podem ser movidos para vários endereços e sincronizados em cada um deles, inflando o saldo total de LP registrado e as recompensas de dividendos que ele gera:

Análise do Ataque

A análise a seguir é baseada nas transações 0xc0f1df...e26154 e 0x077604...756a8f.

• Passo 1: Cerca de 10 dias antes do exploit, o atacante preparou cota de liberação depositando USDT por meio da função participate no MokeVault, obtendo 45.000 USDT de cota de liberação de MOKE que se desbloqueava a 5,5% por dia.

• Passo 2: O atacante cunhou tokens LP de MOKE/WBNB e chamou syncUserLP no MokeLPDividend para registrar o saldo de LP, depois transferiu os mesmos tokens LP para outro endereço e repetiu a sincronização, criando registros de LP duplicados para um único conjunto de tokens.

• Passo 3: O atacante usou flash loans para tomar emprestado uma grande quantidade de BNB e trocou por USDT no par WBNB/USDT, elevando o preço spot do USDT. O atacante então atualizou o preço do MOKE no MokeRelease, e o preço liquidado do MOKE caiu drasticamente.

• Passo 4: Com o preço manipulado do MOKE em vigor, o atacante chamou claim no MokeRelease e resgatou 24.766 USDT de cota por tokens MOKE, recebendo muito mais MOKE do que o valor real da cota.

• Passo 5: O atacante transferiu o MOKE liberado para o contrato MokeLPDividend na lista de permissões e chamou distributeDividend, que vendeu o MOKE por BNB. O atacante então usou os endereços que tinham registros de LP duplicados para chamar claimDividend e coletar o BNB distribuído, recebendo um total de 1.546 BNB.

Conclusão

O Moke Token combinou duas falhas independentes: um preço spot que podia ser movido com um flash loan, e uma contabilidade de dividendos que contava os mesmos tokens LP mais de uma vez. Nenhuma delas por si só teria sido tão danosa quanto as duas juntas.

Os protocolos devem evitar preços spot instantâneos para cálculos sensíveis à segurança e usar uma fonte resistente à manipulação. Qualquer contabilidade indexada em saldos de tokens deve ser atualizada em conjunto com as próprias mudanças de saldo, para que os mesmos tokens não possam ser contados em vários endereços.