Resumo Semanal de Incidentes de Segurança Web3 | 2 a 8 de Mar de 2026

Durante a semana passada (2026/03/02 - 2026/03/08), a BlockSec detectou e analisou sete incidentes de ataque, com perdas totais estimadas em ~$3,25M. A tabela abaixo resume esses incidentes, e análises detalhadas de cada caso são fornecidas nas subseções a seguir.

*O incidente BUBU2 foi omitido no relatório da semana passada e está incluído aqui para fins de completude.

1. Incidente BUBU2

Resumo Breve

Em 1º de março de 2026, o token BUBU2 na BNB Chain foi explorado, resultando em aproximadamente $19,7K em perdas. A causa raiz foi uma falha no design do token: o contrato incorpora um mecanismo deflacionário acumulado por tempo que deduz tokens diretamente das reservas do par AMM durante transferências. O proprietário do contrato reduziu o intervalo de gatilho para um valor extremamente pequeno antes do ataque, fazendo com que centenas de rodadas de queima se acumulassem e fossem executadas em uma única chamada. O atacante aproveitou um flash loan para acionar esse mecanismo, colapsando as reservas do par e inflando o preço do token, para então realizar uma troca reversa à taxa distorcida com fins lucrativos.

Contexto

BUBU2 é um protocolo de token ERC-20 deflacionário implantado na BNB Chain. O protocolo incorpora um mecanismo deflacionário periódico controlado por burnAndMintSwitch: uma vez habilitado pelo proprietário via setBurnAndMintSwitch(true), qualquer transferência não isenta que acione o hook _update() invocará _triggerDailyBurnAndMint(), que queima tokens proporcionalmente do saldo BUBU2 do par de negociação com base no número de períodos TRIGGER_INTERVAL decorridos desde o último acionamento, e sincroniza as reservas de acordo.

Análise de Vulnerabilidade

A causa raiz é uma falha de design no contrato do token BUBU2 (0x3fF3...ee52). O contrato incorpora um mecanismo deflacionário periódico em seu hook _update(): quando acionado, `_triggerDailyBurnAndMint()` calcula o número de períodos `TRIGGER_INTERVAL` decorridos desde a última execução, e queima uma quantidade proporcional de `BUBU2` diretamente do par de negociação ([0x7745...cd2f](https://bscscan.com/address/0x774547ea9d2a0cc79db3288f61e989f1b06bcd2f)), seguido de um sync() para atualizar as reservas. De forma crítica, o proprietário pode reconfigurar o TRIGGER_INTERVAL sem nenhum timelock ou proteção de valor mínimo.

Antes do ataque, o proprietário chamou setBurnAndMintSwitch(true) e depois setTriggerInterval(120), comprimindo o intervalo do padrão de 6 horas para 120 segundos. Como lastTriggerTime ainda estava ancorado várias horas no passado, o próximo acionamento computou centenas de rodadas acumuladas, e o valor de queima escalou linearmente com as rodadas. Isso fez com que uma única transferência drenasse uma quantidade massiva de BUBU2 do par, colapsando suas reservas e inflando o preço do token em aproximadamente 11x.

Análise do Ataque

A análise a seguir é baseada nas transações 0x1bc0...141c,0x191c...1ee4,0xd6e5...51a6.

• Passo 1: O proprietário do token primeiro habilitou o mecanismo deflacionário periódico via setBurnAndMintSwitch(true), depois reduziu o intervalo de gatilho do padrão de 6 horas para 120 segundos via setTriggerInterval(120). O atacante subsequentemente tomou emprestado 18 WBNB via flash loan e os trocou por aproximadamente 18.715.856 BUBU2 do pool.

• Passo 2: O atacante iniciou uma pequena transferência, acionando _triggerDailyBurnAndMint(). O saldo de BUBU2 do pool caiu em aproximadamente 1.025.988.664e18 tokens, deixando apenas 6.493.352e18 BUBU2 restantes na reserva após a execução de sync(), o que inflou o preço do BUBU2 em aproximadamente 200x.

• Passo 3: O atacante vendeu os BUBU2 adquiridos no Passo 1 de volta ao pool pelo preço inflado, recebendo aproximadamente 50 WBNB. Após o reembolso do flash loan, o lucro líquido foi de aproximadamente 32 WBNB.

Conclusão

O exploit do BUBU2 originou-se de uma falha crítica de design no contrato do token. O proprietário configurou um TRIGGER_INTERVAL extremamente pequeno, o que permitiu que o tempo decorrido se acumulasse em centenas de rodadas e drenasse as reservas do par de negociação em uma única chamada, causando um pico violento no preço do BUBU2.

Para reduzir riscos semelhantes no futuro:

• Proteja parâmetros críticos como TRIGGER_INTERVAL com limites ou timelocks.

• Limite ou restrinja as rodadas de execução acumuladas.

2. Incidente ACPRoute

Resumo Breve

Em 2 de março de 2026, o protocolo ACPRoute na Base foi explorado, resultando em aproximadamente $58K em perdas. A causa raiz foi uma lógica de negócio falha no contrato gerenciador de pagamentos: o estado do job foi carregado como uma cópia em memória em vez de uma referência de armazenamento, portanto o rastreamento de desembolso cumulativo nunca foi persistido na cadeia. Isso permitiu que o atacante criasse um job, acionasse a liberação automática de pagamento durante a transição de fase, e então reivindicasse os mesmos fundos em custódia uma segunda vez por meio de uma função de reivindicação sem permissão.

Contexto

ACP (Agent Commerce Protocol) é um protocolo de comércio on-chain modular projetado para interações entre clientes e provedores. Ele estrutura a atividade em três camadas: Contas, Jobs e Memos. Os Jobs seguem um ciclo de vida fixo (REQUEST → NEGOTIATION → TRANSACTION → EVALUATION → COMPLETED), e os pagamentos são mantidos em custódia pelo contrato PaymentManager durante a fase TRANSACTION. Quando um job chega ao estado COMPLETED, o protocolo libera os fundos em custódia para o provedor via a função releasePayment(). Para evitar dupla reivindicação, o protocolo rastreia os desembolsos cumulativos por job usando o campo amountClaimed na struct Job. Espera-se que cada chamada à função releasePayment() compare o valor solicitado com amountClaimed para garantir que os fundos sejam liberados apenas uma vez.

Análise de Vulnerabilidade

A causa raiz está na função releasePayment() do contrato PaymentManager (0x56c3...0684), onde o estado do job é carregado como uma cópia em memória em vez de uma referência de armazenamento. Embora o protocolo rastreie os desembolsos cumulativos via amountClaimed para evitar dupla reivindicação, o incremento job.amountClaimed += amount opera apenas em uma cópia local transitória e nunca é gravado de volta no armazenamento on-chain. Consequentemente, cada invocação da função releasePayment() observa amountClaimed == 0, permitindo que um atacante chame a função claimBudget() e drene o contrato vítima (0x307e...d6e8) uma segunda vez após a transição de fase já ter acionado a função releasePayment() automaticamente.

Análise do Ataque

A análise a seguir é baseada na transação 0xe94a...f9a0.

• Passo 1: O atacante tomou emprestado 97.000e6 USDC via flash loan como capital para o ataque subsequente.

• Passo 2: Dentro do callback, o atacante chamou a função createJob() no ACPRouter, enquanto implantava um novo contrato de provedor (0x1ee502dd...) para receber os fundos.

• Passo 3: O atacante chamou repetidamente a função createMemo() e invocou o próprio exec() do contrato do provedor para avançar a fase do job, até que a transição de fase COMPLETED foi acionada, chamando automaticamente a função releasePayment() e liberando o saldo total para o contrato do provedor. Neste ponto amountClaimed deveria ter sido atualizado, mas seu valor no armazenamento permaneceu 0.

• Passo 4: O atacante chamou a função claimBudget() e reivindicou com sucesso os 97.000e6 USDC em custódia uma segunda vez como lucro.

Conclusão

Este incidente foi causado por uma falha de persistência de estado que permitiu que os fundos em custódia fossem reivindicados duas vezes dentro do mesmo ciclo de vida do job.

Para reduzir riscos semelhantes no futuro:

• Certifique-se de que variáveis de estado críticas (por exemplo, amountClaimed) sejam atualizadas usando referências de armazenamento.

• Restrinja funções sensíveis de pagamento ou imponha validação de estado estrita antes da execução.

3. Incidente sDOLA Llamalend Market

Resumo Breve

Em 2 de março de 2026, o Mercado sDOLA Llamalend no Ethereum foi explorado, resultando em aproximadamente $239K em perdas. A causa raiz é a manipulação de preço. Especificamente, sDOLA é um token ERC4626 cujo preço pode ser manipulado via donate(). Llamalend é um mercado de empréstimos baseado em AMM, e devido ao mecanismo do LLAMMA, os usuários ainda podem se tornar liquidáveis mesmo quando o preço do colateral sobe. Portanto, um atacante pode usar donate() para elevar o preço do sDOLA, levar a saúde das posições dos usuários abaixo de zero, e então liquidar esses usuários com fins lucrativos.

Contexto

LLAMMA (Lending-Liquidating AMM Algorithm) é um mercado de empréstimos baseado em AMM usado pela Curve [1]. Ao contrário dos protocolos de empréstimo tradicionais, o LLAMMA coloca o colateral do usuário em faixas de preço dentro do AMM. À medida que o preço do oráculo $P{}_{oracle}P\backslash \backslash \_\{oracle\}$ se move, o colateral é progressivamente convertido entre o token de colateral e crvUSD por meio de trocas impulsionadas por arbitragem entre faixas (liquidação suave), reduzindo gradualmente o risco das posições em vez de acionar liquidações abruptas.

Se a liquidação suave não puder reduzir o risco de uma posição rápido o suficiente, a liquidação forçada é acionada [2], o que ocorre quando a saúde de uma posição cai abaixo de zero. A saúde é calculada via get_x_down() [3], que não simplesmente marca o colateral a mercado. Em vez disso, simula uma conversão de ida e volta da posição do usuário para avaliar seu valor recuperável. Essa ida e volta usa dois âncoras de preço diferentes: uma derivada do $P{}_{oracle}P\backslash \backslash \_\{oracle\}$ atual (move-se com o oráculo ao vivo), e outra derivada dos limites de faixa do usuário (fixada quando a posição foi criada).

Análise de Vulnerabilidade

Os contratos com falha incluem o Controlador crvUSD (0xad44...fb86) e o AMM LLAMMA (0x0079...a1f7). O contrato vítima é o mercado sDOLA Llamalend (0x2b08...4fbe).

sDOLA é um token de cofre ERC4626 cujo preço de cota é determinado pela proporção entre ativos totais e cotas totais. Como qualquer pessoa pode chamar donate() para adicionar ativos ao cofre, o preço da cota pode ser inflado dentro de uma única transação. Este é o oráculo manipulável do qual a função de saúde do LLAMMA depende.

Conforme descrito no Contexto, get_x_down() calcula a saúde simulando uma conversão de ida e volta por meio de dois âncoras de preço: uma derivada de $P{}_{oracle}P\backslash \backslash \_\{oracle\}$ (dinâmica, move-se com o oráculo ao vivo), e outra derivada dos limites de faixa do usuário (estática, fixada na criação da posição). O protocolo não aplica nenhum atraso ou verificação de sanidade ao ler $P{}_{oracle}P\backslash \backslash \_\{oracle\}$. Portanto, quando o preço do oráculo é inflado, a âncora dinâmica sobe, mas a âncora estática permanece a mesma. Na prática, a simulação converte crvUSD em colateral pelo preço inflado do oráculo e converte de volta pelo preço original da faixa, de modo que o valor recuperável avaliado diminui à medida que a diferença entre as duas âncoras aumenta. Isso leva a saúde abaixo de zero, mesmo que o preço do colateral tenha subido.

Análise do Ataque

A análise a seguir é baseada na transação 0xb935...d8a4.

• Passo 1: Manipular o estado do LLAMMA (grandes trocas) para mover active_band e levar muitos usuários a uma postura somente x (somente crvUSD).

• Passo 2: Manipular o preço do sDOLA via doações, então usar uma troca de valor zero (swap(0)) para escrever o preço manipulado no pool AMM.

• Passo 3: Acionar o recálculo de saúde por meio de users_to_liquidate() -> _health() -> get_x_down().

• Passo 4: Como get_x_down() calcula o valor recuperável por meio de dois âncoras de preço divergentes (a âncora dinâmica, agora inflada, versus a âncora estática, inalterada), a conversão de ida e volta produz um desconto no valor efetivo, e muitas posições cruzam abaixo de zero de saúde.

• Passo 5: Liquidar em lote esses usuários com fins lucrativos.

Adicionalmente, o rastreamento inclui duas chamadas create_loan(). O primeiro empréstimo foi utilizado principalmente para financiar operações de troca de crvUSD de grande porte. O segundo empréstimo foi usado para obter crvUSD para quitar a dívida da primeira posição e reciclar capital. Esses dois empréstimos são principalmente etapas de financiamento/liquidação e não são as etapas centrais do exploit em si.

Conclusão

O incidente é um ataque de manipulação de preço de colateral. O atacante manipulou o preço do sDOLA dentro da transação e, devido ao mecanismo de saúde baseado em caminho do LLAMMA, levou os usuários a condições de liquidação. Uma consequência importante é que as posições ainda podem se tornar liquidáveis mesmo quando o preço do colateral aumenta. Direções de fortalecimento recomendadas:

• Usar preços de colateral atrasados ou TWAP para liquidação.

Referências

• [1] Documentação do Curve crvUSD LLAMMA: [https://dev.curve.finance/crvUSD/amm/#bands](https://dev.curve.finance/crvUSD/amm/#bands)

• [2] Explicação sobre liquidação do Curve LLAMMA: [https://dev.curve.finance/crvUSD/llamma-explainer/#liquidation](https://dev.curve.finance/crvUSD/llamma-explainer/#liquidation)

• [3] Whitepaper da stablecoin Curve: [https://docs.curve.finance/pdf/whitepapers/whitepaper\_curve\_stablecoin.pdf](https://docs.curve.finance/pdf/whitepapers/whitepaper_curve_stablecoin.pdf)

4. Incidente The V4 Router by z0r0z

Resumo Breve

Em 3 de março de 2026, o V4 Router by z0r0z no Ethereum foi explorado, resultando em aproximadamente $42K em perdas. O ataque foi causado por uma lógica de autorização falha em swap(), onde o roteador dependia de um offset fixo de calldata em assembly inline para verificar se o pagador correspondia a msg.sender. Como a codificação ABI para tipos dinâmicos não garante um layout fixo, o atacante foi capaz de criar calldata não padrão, mas válido, que contornou a verificação, se passou por uma vítima previamente aprovada como pagador, e redirecionou a saída da troca para um endereço controlado pelo atacante.

Contexto

O protocolo herda do Uniswap v4 Router e substitui alguns de seus métodos. Em essência, funciona como um roteador de troca, permitindo que os usuários evitem interagir diretamente com o pool correspondente e, em vez disso, usem o roteador como um ponto de entrada unificado.

Análise de Vulnerabilidade

A causa raiz é uma lógica de negócio falha no contrato V4 Router (0x0000...ce97). O contrato vítima é 0x65a8...7675. A função swap() aceita dois parâmetros: data (bytes) e deadline (uint256). Dentro da função, uma verificação de autorização usa um bloco de assembly inline para comparar calldataload(164) com caller(), garantindo que o pagador codificado em data corresponda a msg.sender. O protocolo assume que o offset de bytes é sempre 0x40, colocando o pagador na posição de byte 164 (0xa4).

No entanto, a codificação ABI não garante esse layout: parâmetros dinâmicos armazenam apenas um offset no cabeçalho, e esse offset pode legalmente apontar para qualquer local alinhado no calldata. Ao criar uma codificação válida, mas não padrão, onde o offset de bytes é movido para 0xc0, um atacante pode inserir padding arbitrário entre o cabeçalho e a cauda real. O atacante coloca seu próprio endereço na posição de byte 164 para passar a verificação do assembly, enquanto a carga útil de bytes verdadeira na cauda relocada codifica o endereço da vítima como pagador. Ao selecionar uma vítima que aprovou anteriormente o roteador e definindo o receptor como seu próprio endereço, o atacante pode redirecionar a saída da troca e roubar fundos.

Análise do Ataque

A análise a seguir é baseada na transação 0xfe34...466a.

• Passo 1: Selecionar um usuário que aprovou anteriormente o roteador como alvo.

• Passo 2: Criar o calldata para contornar a verificação de autorização.

• Passo 3: Especificar a vítima como pagador nos dados, definir o próprio endereço do atacante como receptor do token, e então roubar os ativos da vítima.

Conclusão

Este incidente foi causado pela dependência de um offset de calldata fixo para autorização no caminho de troca. Como a codificação ABI para tipos dinâmicos não garante um layout fixo, o atacante contornou a verificação com calldata não padrão, mas válido, se passou por uma vítima aprovada como pagador, e redirecionou a saída da troca.

Para reduzir riscos semelhantes no futuro:

• Nunca dependa de offsets de calldata fixos para parâmetros ABI codificados dinamicamente.

• Decodifique e valide entradas estruturadas usando decodificação ABI canônica em vez de suposições posicionais manuais.

• Certifique-se de que o pagador real, o receptor e o fluxo de tokens sejam consistentemente validados em relação ao chamador pretendido e ao contexto de execução.

5. Incidente The BitcoinReserveOffering Contract

Resumo Breve

Em 5 de março de 2026, o contrato BitcoinReserveOffering no Ethereum foi explorado, resultando em uma perda de aproximadamente $2,7 milhões. A causa raiz foi uma lógica de negócio falha: ao processar um depósito completo de SFT ERC-3525, a lógica de cunhagem foi executada duas vezes dentro de uma única chamada, uma vez durante um callback de transferência e uma vez no fluxo principal. O atacante explorou esse comportamento de dupla cunhagem por meio de ciclos repetidos de queima e cunhagem, inflando exponencialmente seu saldo de tokens BRO, e então resgatou o excesso por SolvBTC para realizar o lucro.

Contexto

BitcoinReserveOffering é um contrato wrapper que converte posições SFT ERC-3525 em tokens ERC-20 BRO transferíveis. Os usuários podem chamar a função mint() para depositar SFTs elegíveis, e o contrato cunhará uma quantidade correspondente de BRO com base em uma taxa de câmbio configurada. Se um usuário depositar apenas parte do valor de um SFT, o contrato transfere o valor especificado para sua posição mantida internamente e então cunha o valor correspondente de BRO. Se um usuário depositar um SFT inteiro, o contrato transfere o token completo para o contrato wrapper e cunha BRO com base no valor total do SFT. Os usuários podem posteriormente chamar a função burn() para resgatar BRO de volta para sua posição SFT ERC-3525 correspondente, convertendo o valor ERC-20 encapsulado de volta em uma posição SFT.

Análise de Vulnerabilidade

A causa raiz é que o contrato BitcoinReserveOffering (0x15f7...cfcf) executa a lógica de cunhagem duas vezes ao processar um depósito completo de SFT ERC-3525 na função mint(). Especificamente, no branch amount_ == sftBalance, mint() chama ERC3525TransferHelper.doSafeTransferIn() para transferir com segurança todo o SFT para o contrato, o que aciona o callback onERC721Received(). Dentro deste callback, o contrato já calcula o valor do SFT e cunha BRO para o remetente. Após o retorno do callback, mint() continua a execução, recalcula o valor usando o mesmo amount_, e realiza uma segunda operação _mint(msg.sender, value). Esse comportamento de dupla cunhagem permite que um atacante infle repetidamente seu saldo de BRO por meio de um ciclo de queima e cunhagem.

Análise do Ataque

A análise a seguir é baseada na transação 0x44e6...958d.

• Passo 1: O atacante transfere 135e18 tokens BRO para o contrato de ataque como capital inicial.

• Passo 2: O atacante executa o seguinte ciclo:

1. Encapsular 135e18 tokens BRO em um token SFT.

2. Chamar mint() com o valor total do SFT, que aciona o callback onERC721Received() e cunha 135e18 tokens BRO; o mint() externo então continua e chama _mint() novamente, resultando em uma cunhagem dupla de 270e18 tokens BRO no total.

3. Encapsular os 270e18 tokens BRO de volta em um token SFT.

• Passo 3: Após repetir o Passo 2 22 vezes, o atacante acumula aproximadamente 567.758.816e18 tokens BRO, que são finalmente resgatados por 38e18 SolvBTC como lucro.

Conclusão

Este incidente foi causado pela dupla cunhagem durante depósitos completos de SFT, permitindo que o atacante inflasse exponencialmente seu saldo de BRO por meio de ciclos repetidos de queima e cunhagem e resgatasse o excesso por SolvBTC.

Para reduzir riscos semelhantes no futuro:

• Certifique-se de que a contabilidade de ativos ocorra apenas uma vez por operação de depósito.

• Adicione verificações de invariante para evitar que os valores cunhados excedam o valor depositado subjacente.

6. Incidente MoltEVM

Resumo Breve

Em 7 de março de 2026, o protocolo MoltEVM na Base foi explorado, resultando em aproximadamente $127K em perdas. A causa raiz foi uma lógica de controle de acesso falha no contrato do token: a função de cunhagem privilegiada era protegida por um modificador que verificava apenas se o chamador era um contrato com uma interface específica, o que podia ser trivialmente falsificado. O atacante implantou um contrato malicioso para contornar a verificação, cunhou um grande suprimento de tokens e os despejou no pool de liquidez com fins lucrativos.

Contexto

MoltEVM é um protocolo de token ERC-20 experimental implantado na Base que explora um modelo de token autorreplicante. O sistema permite que um token gere novos tokens filhos ("tokens Moltling") uma vez que determinados limites de reserva sejam atingidos. Quando um novo Moltling é criado, um suprimento inicial de tokens é distribuído por meio da função mintFromSpawner(), e a liquidez é semeada automaticamente para estabelecer um mercado de negociação para o novo token. Esse design permite que o protocolo expanda sua linhagem de tokens de forma autônoma, com cada geração de tokens capaz de gerar outros descendentes.

Análise de Vulnerabilidade

A vulnerabilidade está na lógica de controle de acesso das funções mintFromSpawner() e setExemptFromSpawner() no contrato MoltEVM (0x225d...501f). Ambas as funções dependem do modificador onlySpawnerToken, que pretendia restringir as chamadas a contratos Moltling legítimos gerados pelo protocolo.

No entanto, o modificador realiza apenas duas verificações fracas: verifica se msg.sender é um contrato e se chamar initialized() no chamador retorna true. Como essas condições podem ser trivialmente satisfeitas por qualquer contrato arbitrário que implemente a mesma interface, a verificação não fornece autenticação significativa de tokens de spawner legítimos.

Como resultado, um atacante pode implantar um contrato mínimo que simplesmente implementa uma função initialized() retornando true. Uma vez implantado, o contrato malicioso pode livremente chamar mintFromSpawner() para cunhar quantidades arbitrárias de tokens e também pode invocar setExemptFromSpawner() para incluir na lista branca endereços controlados pelo atacante. Isso efetivamente concede ao atacante controle total sobre o caminho de cunhagem e permite que os tokens recém-cunhados sejam despejados em pools de liquidez com fins lucrativos.

Análise do Ataque

A análise a seguir é baseada na transação 0x10b7...e03d.

• Passo 1: O atacante implantou um contrato mínimo implementando uma única função initialized() codificada para retornar true, o que foi suficiente para passar na verificação do modificador onlySpawnerToken.

• Passo 2: O contrato do atacante chamou a função setExemptFromSpawner() protegida pelo mesmo modificador vulnerável onlySpawnerToken para adicionar o endereço do atacante à lista branca de isenção de taxas. Isso garantiu que os despejos subsequentes de tokens em grande escala não acionassem taxas de venda ou a lógica interna de troca, maximizando o lucro.

• Passo 3: O atacante repetiu a sequência de funções setExemptFromSpawner() + mintFromSpawner() contra mEVM primeiro, seguido por múltiplos tokens filhos Moltling incluindo CSPAWN, CCUTTL, LWORM e NHYDRA, cunhando tokens em lote em todos os alvos e despejando-os em seus respectivos pools de liquidez para extrair lucro.

Conclusão

Este incidente foi causado por controle de acesso insuficiente em funções privilegiadas de cunhagem e configuração, permitindo que um atacante se passasse por um spawner legítimo e cunhasse tokens arbitrários com fins lucrativos.

Para reduzir riscos semelhantes no futuro:

• Imponha controle de acesso estrito para funções privilegiadas de cunhagem ou configuração.

• Evite depender de verificações de contrato facilmente falsificáveis para autorização.

• Valide a identidade do chamador por meio de listas brancas explícitas ou registros de contratos confiáveis.

7. Incidente LEDS

Resumo Breve

Em 8 de março de 2026, o token LEDS na BNB Chain foi explorado, resultando em aproximadamente $64K em perdas. A causa raiz foi uma lógica de negócio falha: o contrato do token expõe múltiplos mecanismos deflacionários independentes, cada um capaz de queimar tokens diretamente do par de liquidez, e nenhum é protegido por controle de acesso ou cooldown. O atacante encadeou todos os caminhos de queima dentro de uma única transação, colapsando a reserva de LEDS do par para quase zero enquanto a reserva de WBNB permanecia intacta, e então realizou trocas reversas para drenar o pool desequilibrado com fins lucrativos.

Contexto

LEDS é um token deflacionário na BNB Chain com mecânicas de taxa na transferência incorporadas. Seu _transfer() implementa múltiplos mecanismos de queima projetados para reduzir gradualmente o suprimento e sustentar o preço: uma função de queima diária triggerDailyBurnAndMint(), uma queima diferida via acumulação de stor_18 nas vendas, e um branch especial que queima tokens para 0xdead quando o receptor da troca é definido como o Roteador PancakeSwap. O token também possui uma função deposit() onde os usuários enviam BNB para cunhar LEDS e fornecer liquidez, ganhando recompensas LP resgatáveis por meio de um distribuidor.

Análise de Vulnerabilidade

A causa raiz é uma lógica de negócio falha no contrato do token LEDS (0xfb62...a48f). A vítima é o par LEDS/WBNB (0xd109...6f3f). O token implementa múltiplos mecanismos deflacionários: triggerDailyBurnAndMint(), acumulação de stor_18 no caminho de venda, e um branch de queima to == router em _transfer(). Cada um desses independentemente remove LEDS do par de liquidez e chama sync() para atualizar as reservas.

Embora individualmente esses mecanismos sirvam como ferramentas de deflação gradual, eles podem ser encadeados dentro de uma única transação para compor seus efeitos. Adicionalmente, a função pública 0x17a06174() permite que qualquer pessoa libere todo o saldo acumulado de stor_18 à vontade, sem controle de acesso ou limitação de taxa. Ao empilhar sequencialmente esses caminhos de queima, um atacante pode reduzir a reserva de LEDS do par para quase zero enquanto deixa a reserva de WBNB intocada, criando uma extrema deslocação de preço explorável via trocas reversas.

Análise do Ataque

A análise a seguir é baseada na transação 0x2608...79da.

• Passo 1: O atacante obteve uma grande quantidade de WBNB via flash loans (Moolah + empréstimo colateral Venus + Aave + PancakeSwap V4).

• Passo 2: Realizou múltiplas chamadas deposit() para acumular recompensas LP, depois acionou triggerDailyBurnAndMint(), que queimou uma parte do LEDS do par e enviou recompensas ao distribuidor, reduzindo a reserva de LEDS no pool.

• Passo 3: Chamou a função 0xde1b1942() para reivindicar as recompensas de tokens LEDS acumuladas.

• Passo 4: Vendeu os LEDS reivindicados por WBNB. Como o saldo de LEDS do par excedeu o limite após a venda, o valor transferido foi acumulado em stor_18 (queima pendente).

• Passo 5: Comprou LEDS via PancakeSwap com o receptor definido como o endereço do Roteador. Isso acionou um branch especial em _transfer() que queimou os LEDS comprados diretamente do par para 0xdead, reduzindo ainda mais a reserva de LEDS do pool.

• Passo 6: Chamou a função 0x17a06174(), que queimou todo o saldo de stor_18 (acumulado no Passo 4) do par para 0xdead e chamou sync(), colapsando a reserva de LEDS do pool para apenas 2 wei.

• Passo 7: Realizou trocas reversas para drenar WBNB do pool agora fortemente desequilibrado, reembolsou todos os flash loans e lucrou 104,56 WBNB ($64K).

Conclusão

Este incidente foi causado por múltiplos mecanismos deflacionários desprotegidos que podem ser encadeados dentro de uma única transação para deplexar catastroficamente as reservas do par de liquidez.

Para qualquer contrato de token que implemente mecânicas deflacionárias ou de queima automática, os desenvolvedores devem:

• Nunca expor funções de queima do par sem controle de acesso adequado, limitação de taxa ou aplicação de cooldown.

• Evitar permitir que múltiplos mecanismos independentes de queima sejam acionados sequencialmente dentro de uma única transação.

Sobre a BlockSec

A BlockSec é um fornecedor completo de segurança blockchain e conformidade cripto. Desenvolvemos produtos e serviços que ajudam os clientes a realizar auditorias de código (incluindo contratos inteligentes, blockchain e carteiras), interceptar ataques em tempo real, analisar incidentes, rastrear fundos ilícitos e atender obrigações de AML/CFT, ao longo de todo o ciclo de vida de protocolos e plataformas.

A BlockSec publicou múltiplos artigos de segurança blockchain em conferências de prestígio, reportou vários ataques de dia zero em aplicações DeFi, bloqueou múltiplos hacks para resgatar mais de 20 milhões de dólares e protegeu bilhões em criptomoedas.

• Site oficial: https://blocksec.com/

• Conta oficial no Twitter: https://twitter.com/BlockSecTeam

• 🔗 Serviço de Auditoria BlockSec : Envie uma solicitação

• 🔗 Phalcon Security APP: Agende uma demonstração

• 🔗 Phalcon Compliance