Resumo Semanal de Incidentes de Segurança Web3 | 30 de mar – 5 de abr de 2026

Durante a semana passada (2026/03/30 - 2026/04/05), a BlockSec detectou e analisou nove incidentes de ataques, com perdas totais estimadas de aproximadamente $287M. A tabela abaixo resume esses incidentes, e análises detalhadas de cada caso são fornecidas nas subseções a seguir.

1. Incidente de Protocolo Desconhecido

Resumo

Em 30 de março de 2026, um protocolo desconhecido na BNB Chain perdeu aproximadamente $10K devido a uma lógica de negócio falha. O protocolo alocava parte dos depósitos dos usuários para comprar seu token de plataforma PSTART e adicionar liquidez, o que significava que os usuários efetivamente detinham posições de LP sujeitas a flutuações de preço de mercado. Porém, no momento do saque, o protocolo não liquidava com base no valor real resgatável do LP naquele momento. Em vez disso, continuava prometendo uma quantidade fixa de stablecoins com base no depósito histórico e em regras predefinidas. Como resultado, após comprometer capital por meio de investimento forçado, o atacante conseguiu sacar fundos a um valor fixo pré-acordado, transferindo efetivamente as perdas que deveriam ter sido suportadas pela posição de LP para o protocolo, alcançando lucro a custo zero.

Contexto

O protocolo funciona da seguinte forma: após um usuário depositar BUSD, o protocolo usa automaticamente uma parte dos fundos para comprar PSTART, e então o combina com o BUSD restante para adicionar liquidez ao pool. As cotas de LP resultantes são custodiadas pelo Vault, enquanto o protocolo registra, em seu livro interno, uma ordem para o usuário que promete um rendimento diário fixo.

Posteriormente, o usuário pode reivindicar recompensas a uma taxa de juros fixa e, ao sair, o Vault liquida o principal e o rendimento de acordo com regras predefinidas, em vez de resgatar estritamente com base no valor patrimonial líquido real atual da posição de LP subjacente.

Análise de Vulnerabilidade

Esta vulnerabilidade decorre de um design de protocolo (0x587984...73a43c) não razoável: a lógica de liquidação está desconectada do valor real dos ativos subjacentes.

Após um usuário depositar BUSD, o protocolo usa parte dele para comprar PSTART e adicionar liquidez, o que significa que a posição subjacente real do usuário é uma exposição de LP cujo valor flutua com os preços de mercado. No entanto, quando o usuário sai, o protocolo não liquida com base no valor real resgatável do LP naquele momento. Em vez disso, ainda promete pagar uma quantidade fixa de stablecoins de acordo com o valor do depósito histórico e as regras de liquidação predefinidas.

O atacante explorou essa falha usando um empréstimo relâmpago para obter uma grande quantidade de capital e, em seguida, executando deposit() repetidamente. Ao fazer isso, o atacante forçou o protocolo a comprar continuamente PSTART e alterar a composição de ativos do pool, inflando artificialmente o preço do PSTART e criando uma oportunidade de arbitragem.

O atacante então executou withdraw() e resgatou os fundos pelo valor fixo pré-prometido, transferindo efetivamente as perdas que deveriam ter sido suportadas pela posição de LP subjacente para o próprio protocolo, alcançando lucro a custo zero.

Análise do Ataque

A análise a seguir é baseada na transação 0xf3b8...55e7.

• Etapa 1: O atacante obteve aproximadamente 2.000.000e18 BUSD por meio de um empréstimo relâmpago e os trocou no pool por 19.013.120e18 PSTART.

• Etapa 2: O atacante chamou repetidamente a função deposit() do contrato para fazer staking de fundos. A cada depósito, o protocolo calculava quanto BUSD deveria ser usado para comprar tokens, de modo que a proporção final de token/BUSD usada para adicionar liquidez se aproximasse mais da proporção atual do pool. Ao depositar repetidamente, o atacante injetava continuamente BUSD no pool, enquanto a quantidade de PSTART permanecia quase inalterada. Como resultado, o valor do PSTART continuava subindo. Nessa fase, o LP obtido por meio dos depósitos do atacante estava sendo adquirido com prejuízo.

• Etapa 3: O atacante então vendeu o PSTART comprado na Etapa 1 de volta ao pool. Como a Etapa 2 havia aumentado as reservas de BUSD do pool, essa troca retornou aproximadamente 2.010.655e18 BUSD, gerando um lucro de cerca de 10.655 BUSD em um único ciclo de ataque.

• Etapa 4: Por fim, o atacante executou withdraw() em todas as posições de staking abertas na Etapa 2. Nesse ponto, o valor de mercado dos ativos correspondentes a essas posições já estava muito abaixo do valor de depósito inicial. Sob a lógica econômica normal, o resgate integral não deveria ter sido possível. No entanto, o protocolo calculou o valor resgatável em BUSD com base no valor do depósito histórico, permitindo que o atacante recuperasse totalmente todos os custos de investimento forçado anteriores sem suportar nenhuma perda.

Conclusão

A causa raiz deste incidente é que o protocolo investiu os fundos dos usuários em posições de LP sujeitas a flutuações de preço de mercado, mas ainda assim prometeu liquidação em uma quantidade fixa de BUSD com base nos valores de depósito históricos e em regras predefinidas. Isso criou uma desconexão entre os passivos do protocolo e o valor real de seus ativos subjacentes.

O atacante explorou essa falha usando repetidamente deposit() para alterar a estrutura de ativos do pool e elevar o preço do PSTART, concluiu a arbitragem por meio de uma posição externa e, por fim, usou withdraw() para resgatar as posições anteriormente deficitárias pelo valor contábil. Dessa forma, as perdas que deveriam ter sido suportadas pelas próprias posições foram transferidas para o protocolo, possibilitando lucro sem risco.

2. Incidente do Token WDGG

Resumo

Em 30 de março de 2026, o token WDGG na BNB Chain foi explorado, resultando em aproximadamente $40K em perdas. A causa raiz foi a ausência de controle de acesso na função burnFrom(). Especificamente, a função burnFrom() permitia que usuários arbitrários queimassem tokens WDGG de qualquer endereço. O atacante explorou isso queimando tokens WDGG do pool PancakeSwap, invocando a função sync() para reduzir as reservas de WDGG do pool e, subsequentemente, realizando uma troca reversa para extrair lucro.

Contexto

Este incidente envolve um único token, WDGG, que é um token de distribuição de dividendos que cobra uma taxa em cada transferência.

Análise de Vulnerabilidade

O contrato do token WDGG (0x512de7...6b90c5) expôs burnFrom() sem nenhuma autorização do chamador. Como resultado, qualquer endereço poderia queimar tokens WDGG de qualquer titular, incluindo o próprio pool PancakeSwap. Combinada com a função sync() do PancakeSwap, que pode ser chamada publicamente e realinha as reservas registradas com os saldos reais, essa falha permitia que a reserva de WDGG do pool fosse arbitrariamente reduzida e o invariante de produto constante fosse quebrado sem nenhuma negociação legítima, expondo o pool à arbitragem de desequilíbrio de preço.

Uma falha secundária em setWdgAddress() permitia que qualquer chamador marcasse um endereço arbitrário como isento de taxas, maximizando ainda mais o lucro extraível por meio dessa superfície de ataque.

Análise do Ataque

A análise a seguir é baseada na transação 0x2da5...0bd1.

• Etapa 1: O atacante primeiro chamou setWdgAddress() para definir seu próprio endereço como isento de taxas, permitindo que transferências subsequentes contornassem a taxa de transferência do token.

• Etapa 2: O atacante então trocou uma pequena quantidade de BNB por tokens WDGG por meio do pool PancakeSwap.

• Etapa 3: Após obter WDGG, o atacante invocou burnFrom() para queimar tokens WDGG diretamente do endereço do par PancakeSwap.

• Etapa 4: O atacante subsequentemente chamou sync(), forçando o par a atualizar suas reservas para corresponder aos saldos de token manipulados. Como resultado, a reserva de WDGG no pool foi reduzida para apenas 1 wei.

• Etapa 5: Com as reservas do pool severamente distorcidas, o atacante executou uma troca reversa e extraiu lucro do desequilíbrio de preço.

Conclusão

Este incidente foi causado, em última análise, pela ausência de controle de acesso na função burnFrom() do contrato do token WDGG. Como resultado, um atacante conseguiu queimar tokens diretamente do pool PancakeSwap, manipular as reservas do pool via sync() e explorar o desequilíbrio de preço resultante para obter lucro.

3. Incidente do i6Token

Resumo

Em 31 de março de 2026, o Token i6 na BNB Chain perdeu aproximadamente $273,8K porque invest() movia o preço spot do pool enquanto withdraw() liquidava saldos por meio de um TWAP defasado, e os dois podiam ser compostos na mesma transação. O atacante inflou o preço spot via invest(), resgatou i6 excedente pelo TWAP desatualizado por meio de withdraw() e vendeu o i6 de volta ao pool inflado para obter lucro.

Contexto

O protocolo funciona da seguinte forma. Quando um usuário chama invest(), o USDT é depositado e parcialmente usado para comprar i6 no PancakeSwap. O i6 adquirido, juntamente com o USDT restante, é então adicionado como liquidez ao pool USDT/i6, e os tokens LP resultantes são queimados. O protocolo registra os saldos do usuário e de indicação denominados em USDT.

Quando withdraw() é chamado, o protocolo calcula o valor acumulado do usuário em termos de USDT e o converte em i6 usando um preço TWAP mantido pelo protocolo (twapPrice).

Análise de Vulnerabilidade

A causa raiz no contrato do protocolo (0x1cb36b...2a18a) é que invest() muta o preço spot do pool USDT/i6 como efeito colateral da compra de i6 e da adição de liquidez, enquanto withdraw() liquida saldos acumulados denominados em USDT em i6 usando um TWAP mantido pelo protocolo (twapPrice) que só é atualizado após decorrido um intervalo de tempo. Nada no contrato impede que essas duas funções sejam executadas na mesma transação.

Como uma chamada a invest() pode inflar o preço spot dentro da mesma transação em que um withdraw() subsequente lê um TWAP ainda não atualizado, os dois efetivamente veem dois preços diferentes para o mesmo estado do pool. Um saldo denominado em USDT resgatado por meio de withdraw() é então pago em i6 ao preço desatualizado e muito mais baixo, mesmo que cada i6 agora seja realizável por muito mais USDT no próprio pool. Essa diferença transforma qualquer saldo acumulado em USDT no protocolo em uma margem explorável entre a liquidação interna e o pool em tempo real.

Análise do Ataque

A análise a seguir é baseada na transação 0xc1b9...2f16.

• Etapa 1: O atacante primeiro obteve 270.000 WBNB por meio de um empréstimo relâmpago, depois os forneceu à Venus como garantia e tomou emprestado uma grande quantidade de USDT. O atacante também implantou o contrato de ataque A em 0xda49 e o contrato auxiliar B em 0x096a.

• Etapa 2: O contrato de ataque executou o primeiro invest(). Durante esse processo, o protocolo primeiro usou 531.489e18 USDT para comprar 234.188e18 i6, e então adicionou 354.326e18 USDT juntamente com 72.607e18 i6 ao pool. Como resultado, o preço spot do pool aumentou rapidamente de cerca de 1,05159 USDT/i6 para cerca de 4,89287 USDT/i6, enquanto o TWAP registrado pelo protocolo ainda permanecia em apenas 1,05159.

• Etapa 3: O atacante então transferiu 124.014.184e18 USDT para o contrato auxiliar B, que por sua vez chamou invest() com referrer = A. Esta etapa forçou novamente o protocolo a realizar uma compra massiva de USDT -> i6 e addLiquidity(), empurrando as reservas do pool para um novo estado correspondente a um preço spot de aproximadamente 15.528 USDT/i6. No entanto, como nenhum novo intervalo de tempo havia decorrido, o protocolo não atualizou o TWAP correspondentemente.

• Etapa 4: Após a conclusão do segundo invest(), o contrato de ataque A, atuando como indicador, tornou-se imediatamente elegível a uma recompensa de indicação denominada em USDT. O atacante então chamou withdraw(). O protocolo usou o TWAP desatualizado para calcular a quantidade de i6 a ser paga e transferiu os tokens de seu próprio saldo, resultando em um pagamento total de 5.896.508e18 i6.

• Etapa 5: Após receber o i6, o atacante imediatamente chamou swapExactTokensForTokensSupportingFeeOnTransferTokens() para vender todos os 5.896.508e18 i6 de volta ao pool em troca de 125.177.224e18 USDT. Como esses tokens i6 foram liquidados usando o TWAP desatualizado de aproximadamente 1,05159 USDT/i6, enquanto eram vendidos contra um preço spot do pool que havia sido elevado pelo atacante para cerca de 15.528 USDT/i6, o atacante conseguiu realizar diretamente a enorme margem entre os dois preços.

• Etapa 6: Após reembolsar o empréstimo relâmpago, o atacante reteve 273.802e18 USDT, que foi o lucro real do ataque.

Conclusão

A causa raiz é que uma função que impacta o preço spot (invest()) e uma função liquidada via TWAP (withdraw()) podiam ser compostas em uma única transação, permitindo que as duas vissem preços diferentes para o mesmo estado do pool.

Para prevenir essa classe de falha, protocolos que combinam interações com AMM e precificação com atraso devem evitar liquidar saldos pelo TWAP na mesma transação em que uma função complementar move o preço spot do pool subjacente, e devem ancorar os pagamentos ao valor realizável em tempo real do pool em vez de a um preço desatualizado ou derivado.

4. Incidente do Drift Protocol

Resumo

Em 1º de abril de 2026 (UTC), o Drift Protocol na Solana foi comprometido em aproximadamente $285,3M. A causa raiz não foi um bug no contrato inteligente, mas uma falha no processo de autorização multisig, agravada por um Conselho de Segurança 2-de-5 sem timelock e pelo mecanismo de nonce durável da Solana, que permitiu que aprovações multisig pré-coletadas permanecessem válidas indefinidamente até que o atacante escolhesse executá-las. Após semanas de preparação, o atacante induziu dois dos cinco signatários a pré-assinar transações de governança maliciosas vinculadas a contas de nonce durável, posteriormente as submeteu para assumir o controle administrativo e, em seguida, introduziu um ativo de garantia fabricado (CVT), inflou seu preço de oráculo, relaxou os limites de saque e drenou ativos reais por meio do Drift Vault (JCNCMF...XJfrw).

Contexto

O Drift Protocol é um protocolo DeFi na Solana que suporta negociação com margem, empréstimos, mercados spot e derivativos. Suas operações de alto privilégio, incluindo alterações de administrador, criação de mercado, configuração de oráculo, atualizações de parâmetros de risco e ajustes de limites de saque, são governadas pelo framework multisig Squads, em vez de uma única chave privada. Na época do ataque, o Conselho de Segurança do Drift operava com uma configuração de limite 2-de-5 com zero timelock, o que significava que quaisquer dois dos cinco signatários podiam autorizar ações administrativas com efeito imediato. A segurança desse sistema depende não apenas da custódia da chave do signatário, mas também da integridade de todo o pipeline de aprovação: qual transação foi criada, o que os signatários acreditavam estar aprovando e se as instruções finais executadas correspondiam a esse contexto de revisão.

Separadamente, as contas de nonce durável da Solana substituem o blockhash de curta duração por um nonce persistente armazenado em uma conta dedicada, permitindo que uma transação assinada permaneça válida indefinidamente até que o nonce seja avançado. Esse mecanismo é projetado para casos de uso legítimos, como assinatura offline e envio com atraso, mas introduz um primitivo de ataque crítico ao desacoplar quando uma transação é assinada de quando ela é executada on-chain. Uma vez que um signatário aprova uma transação de nonce durável, a aprovação não pode ser revogada a menos que a autoridade do nonce avance manualmente a conta de nonce.

Análise de Vulnerabilidade

A causa raiz não é um bug no contrato inteligente, mas três fraquezas estruturais na configuração de governança do Drift que juntas transformaram uma oportunidade de engenharia social em uma drenagem de $285,3M. Primeiro, os nonces duráveis removeram a proteção implícita de expiração de assinatura. Sob transações normais baseadas em blockhash, a aprovação de um signatário enganado é executada prontamente ou expira de forma inofensiva dentro de uma janela estreita, limitando o escopo para exploração coordenada. Os nonces duráveis dissolvem essa restrição: uma vez que dois membros do Conselho de Segurança foram induzidos a aprovar transações de governança maliciosas por meio de solicitações de assinatura enganosas, suas assinaturas permaneceram exploráveis indefinidamente, dando ao atacante controle completo sobre o momento de execução.

Segundo, o zero timelock em ações administrativas significava que, uma vez submetidas as transações pré-assinadas, a transferência de administrador entrava em vigor imediatamente, sem nenhuma janela de detecção ou intervenção. Terceiro, o escopo da função de administrador era amplo o suficiente para criar novos mercados de garantia, trocar fontes de oráculo e relaxar limites de saque em um único caminho privilegiado, de modo que uma única tomada de controle de governança bem-sucedida era suficiente para converter um ativo arbitrário em extração real de fundos sem nenhuma barreira de autorização adicional.

Análise do Ataque

O ataque se desenrolou em três fases distintas: Preparação Pré-Ataque, em que o atacante conduziu uma operação de várias semanas para fabricar um ativo de garantia falso e obter acesso à governança por meio de solicitações de assinatura enganosas; Tomada de Controle da Governança, em que duas transações de nonce durável pré-assinadas foram submetidas em rápida sucessão para assumir o controle administrativo; e Extração de Fundos, em que o atacante manipulou parâmetros do protocolo e drenou ativos reais pelos caminhos de empréstimo do protocolo. O diagrama abaixo ilustra o fluxo de execução nessas três fases.

• Fase 1 (Preparação Pré-Ataque): A partir de 11 de março, o atacante sacou 10 ETH do Tornado Cash e implantou o CarbonVote Token (CVT), cunhando 750 milhões de unidades, depois semeou liquidez na Raydium e usou wash trading para construir um histórico de preço artificial próximo de $1. Paralelamente, até 23 de março, quatro contas de nonce durável foram criadas, duas vinculadas a membros do Conselho de Segurança do Drift e duas controladas pelo atacante, indicando que pelo menos dois dos cinco signatários já haviam assinado transações vinculadas a contas de nonce durável. Em 27 de março, o Drift executou uma migração planejada do Conselho de Segurança devido a uma mudança de membro, invalidando as assinaturas coletadas anteriormente; no entanto, até 30 de março, o atacante havia obtido novamente o limite necessário sob a nova configuração, demonstrando monitoramento ativo das mudanças de governança on-chain e adaptação em tempo real.

• Fase 2 (Tomada de Controle da Governança): Em 1º de abril, por volta das 16h05 UTC, cerca de um minuto após o Drift realizar um saque de teste legítimo do fundo de seguros, o atacante submeteu duas transações de nonce durável pré-assinadas com quatro slots de intervalo. A primeira transação (2HvMSg...2C4H) criou e aprovou a proposta maliciosa de transferência de administrador. A segunda transação (4BKBmA...RsN1) aprovou e a executou, começando com AdvanceNonceAccount para ativar o nonce armazenado, prosseguindo com proposalApprove e vaultTransactionExecute, e finalmente invocando UpdateAdmin para transferir o controle administrativo para um endereço controlado pelo atacante.

• Fase 3 (Extração de Fundos): Com privilégios de administrador completos, o atacante criou um mercado de garantia para CVT, trocou para um oráculo controlado pelo atacante para inflar seu preço contábil e aumentou ou removeu os limites de saque nos principais mercados de ativos. O atacante então depositou uma grande quantidade de CVT supervalorizado no protocolo e executou 31 saques rápidos em aproximadamente 12 minutos, drenando USDC, JLP, SOL, cbBTC, USDT, wETH, dSOL, WBTC, JTO e FARTCOIN por uma perda total de aproximadamente $285,3M, calculada com base na conta de saque do atacante (HkGz4K...pZES).

Conclusão

A causa raiz deste incidente não é uma vulnerabilidade em contrato inteligente nem um comprometimento de chave, mas uma falha no processo de autorização multisig combinada com execução retardada baseada em nonce durável e um caminho administrativo sem timelock. Aprovações pré-coletadas que normalmente teriam expirado em minutos permaneceram exploráveis indefinidamente, e uma vez submetidas, a tomada de controle do administrador e a subsequente extração de fundos não deixaram nenhuma janela de intervenção.

Mitigar essa classe de risco requer proteger todo o pipeline de autorização, não apenas a custódia de chaves dos signatários, aplicar timelocks em operações de alto privilégio e tratar mecanismos de execução retardada como nonces duráveis como uma superfície de ameaça distinta que exige limiares de assinatura mais altos, aprovações com prazo determinado ou revogáveis e restrições contra transações assinadas com validade indefinida.

5. Incidente do LML Staking Protocol

Resumo

Em 1º de abril de 2026, o protocolo de staking LML na BNB Chain foi explorado por aproximadamente $950K. A causa raiz foi uma inconsistência na lógica de cálculo de recompensas: a conversão de recompensas lia um preço armazenado LML/USDT bloqueado por um cooldown de atualização de 3600 segundos, enquanto o LML pago era resgatável pelo preço do AMM em tempo real, sem verificação de desvio entre os dois. O atacante usou empréstimos relâmpago para inflar o preço spot do pool e delegação de código EIP-7702 para reivindicar recompensas em lote para 11 EOAs pré-apostadas em uma única transação, recebendo uma quantidade excessiva de LML ao preço armazenado desatualizado e vendendo-o de volta pelo pool agora severamente distorcido para obter lucro.

Contexto

LML é um protocolo de staking na BNB Chain onde os usuários fazem staking de BNB via o contrato APower para ganhar tokens LML como recompensas. As recompensas são calculadas em termos de USDT e depois convertidas em quantidades de LML com base em um preço LML/USDT armazenado pelo protocolo antes da distribuição. O preço armazenado é atualizado por updatePrice(), que lê o preço spot do AMM, mas impõe um cooldown de 3600 segundos entre as atualizações. As reivindicações de recompensa são acionadas por meio da função receive() do APower com base em msg.sender, portanto, apenas o endereço de staking original pode reivindicar suas próprias recompensas.

Análise de Vulnerabilidade

A falha central no contrato de staking (0xbe9713...adce19) é que o acúmulo de recompensas e o resgate de recompensas estão ancorados a dois preços diferentes do mesmo pool sem nenhuma verificação de consistência entre eles. A fórmula de recompensa reward += (10^18 * base_reward) / stored_price calcula o pagamento de LML a partir de _prices[], um preço LML/USDT armazenado pelo protocolo que só é atualizado por updatePrice() após um cooldown de 3600 segundos, mas o LML pago é imediatamente resgatável pelo preço spot do AMM em tempo real. Qualquer atividade externa que mova o preço spot dentro desta janela de cooldown abre uma lacuna entre um preço de acúmulo congelado e um preço de venda em tempo real, e nada no contrato rejeita uma reivindicação quando essa lacuna se torna irrazoável.

Uma segunda falha estrutural está em como a fonte de recompensa é reabastecida. Quando o saldo de LML do contrato PROOF é insuficiente para pagar uma reivindicação, swapBack() o reabastece chamando super._transfer(swapPair, PROOF, deficit) seguido de sync(), movendo diretamente o LML das reservas do par LP e realinhando o estado armazenado do par em vez de passar por uma troca normal. Como esse caminho contorna a descoberta de preço do par, cada reivindicação que o aciona reduz as reservas de LML do par e desloca ainda mais o preço spot sem nenhuma entrada de token compensatória, portanto, reivindicações repetidas ampliam mecanicamente a lacuna entre o preço armazenado congelado e o preço de venda em tempo real quanto mais reivindicações são processadas.

Análise do Ataque

A análise a seguir é baseada nas transações 0x805d...5b47, 0x70f7...3572.

• Etapa 1: O atacante agregou uma grande quantidade de USDT e WBNB por meio de empréstimos relâmpago da Moolah, tomando emprestado da Venus e do Moolah Pool (usando WBNB como garantia), e empréstimos relâmpago do PancakeSwap V4, múltiplos pools V3 e pools V2. Este capital era necessário para manipular o preço do par LML/USDT.

• Etapa 2: O atacante chamou swapAndTrans() no contrato do token LML, que trocou as taxas de LML acumuladas no contrato por USDT. Isso drenou o saldo próprio de LML do contrato LML, o que significa que ele não poderia mais servir como fonte local de tokens; qualquer distribuição subsequente de recompensas precisaria extrair LML do par LP via swapBack().

• Etapa 3: O atacante trocou USDT por LML via PancakeRouter swapExactTokensForTokensSupportingFeeOnTransferTokens, com o destinatário definido como o endereço morto. Os tokens LML comprados foram queimados em vez de recebidos pelo atacante. O único propósito era drenar o LML do par e inflar o preço do LML no AMM — o atacante não precisava dos tokens em si, apenas da distorção de preço.

• Etapa 4: O atacante havia previamente depositado no protocolo de staking usando 11 endereços EOA. Como a função receive() do APower aciona _claimReward(msg.sender) com base em msg.sender, as recompensas só podem ser reivindicadas pelo próprio endereço depositante. Para reivindicar recompensas para todos os 11 EOAs em uma única transação, o atacante usou EIP-7702 para definir código nesses EOAs, permitindo que fossem chamados como contratos pelo contrato principal do atacante. Cada EOA executou uma função transfer(rst, fte) que enviava uma pequena quantidade de BNB para o APower, acionando receive(), _claimReward(EOA). Dentro de cada reivindicação: updatePrice() foi ignorado (cooldown de 3600s não atingido, portanto stored_price permaneceu no valor histórico baixo), updateUser() calculou a recompensa usando o preço baixo desatualizado, sendMining() transferiu LML do PROOF para o APower e acionou swapBack(), que reabasteceu o PROOF extraindo LML do par LP e chamando sync(), reduzindo ainda mais as reservas do par. Por fim, claimReward() distribuiu LML para o EOA, e cada EOA transferiu seu LML recebido de volta para o contrato do atacante.

• Etapa 5: O atacante trocou o LML acumulado de volta para USDT pelo pool agora severamente drenado ao preço extremamente inflado.

• Etapa 6: Reembolsou todos os empréstimos relâmpago, empréstimos e taxas. Transferiu o lucro restante.

Conclusão

A causa raiz é uma incompatibilidade entre o acúmulo de recompensas e o resgate no contrato de staking: os pagamentos são dimensionados a partir de um preço LML/USDT armazenado bloqueado por um cooldown de 3600 segundos, mas liquidados em LML cujo valor real acompanha o preço do AMM em tempo real, sem verificação de desvio vinculando os dois. O caminho de reabastecimento swapBack() amplifica essa falha drenando LML diretamente do par LP a cada reivindicação, ampliando mecanicamente a lacuna entre o preço armazenado congelado e o preço de venda em tempo real quanto mais reivindicações são processadas.

Protocolos de staking que dimensionam recompensas a partir de preços derivados de AMM devem aplicar uma verificação de desvio entre o preço armazenado e o preço spot atual no momento da reivindicação e reverter quando a lacuna exceder um limite seguro, e devem evitar mecanismos de reabastecimento que mutam as reservas de LP fora dos caminhos normais de troca, uma vez que esses mecanismos contornam a descoberta de preço que, de outra forma, limitaria os danos causados por precificação desatualizada.

6. Incidente do Tactile

Resumo

Em 1º de abril de 2026, o Tactile, um protocolo de depósito em camadas na Polygon, sofreu uma perda de aproximadamente $12K. A causa raiz foi uma inconsistência em sua lógica de liquidação de depósito e saque: tanto a entrada quanto a saída eram convertidas contra o preço spot atual de CES, e a cota interna não carregava nenhum registro do valor do ativo em que foi originalmente cunhada. O atacante explorou isso inflando o preço spot antes de depositar para obter cotas excessivas, depois deprimindo o preço antes de sacar para resgatar mais CES por cota, repetindo o ciclo em contratos auxiliares para extrair lucro.

Contexto

Tactile é um protocolo de depósito em camadas na Polygon onde os usuários depositam CES em um contrato de pagamento de acordo com uma camada selecionada. O valor do depósito necessário é calculado a partir do preço spot atual de CES e da configuração da camada, e o usuário recebe uma cota de contabilidade interna representando sua posição. No saque, a cota registrada é convertida de volta em CES usando o preço spot no momento da saída, em vez de liquidar contra o valor originalmente depositado, portanto, os saldos dos usuários são efetivamente rastreados como unidades de contabilidade dependentes de preço, em vez de valores de ativos fixos.

Análise de Vulnerabilidade

A falha central no contrato de pagamento (0x9153e1...09b654) é que o depósito e o saque são liquidados contra o mesmo oráculo de preço spot em dois momentos diferentes sem nenhuma âncora imutável vinculando-os. No momento do depósito, o contrato lê getActualPrice() e converte o CES depositado em uma cota interna com base no preço atual; no momento do saque, a mesma cota é convertida de volta em CES usando o preço spot no momento do resgate.

Como a cota em si não carrega nenhum registro do preço ou valor do ativo em que foi cunhada, qualquer movimento do preço spot entre esses dois momentos se traduz diretamente em uma incompatibilidade entre o CES pago e o CES recebido, tornando a contabilidade do protocolo totalmente exposta ao caminho do preço em vez do valor do ativo subjacente.

Análise do Ataque

A análise a seguir é baseada na transação 0xc321...da74.

• Etapa 1: O atacante primeiro tomou emprestado 55.365e18 CES de um pool flash Uniswap V3 e distribuiu os fundos para 5 contratos auxiliares. Cada auxiliar primeiro recebeu 6.426e18 CES, e então chamou deposit(12). Durante esse processo, cada auxiliar primeiro consultou getPriceForLevel(12) e depois preparou a quantidade de CES necessária para esse depósito com base no preço atual.

• Etapa 2: Após todos os 5 auxiliares concluírem a primeira rodada de deposit, o atacante despejou 300.000 CES na DEX, derrubando o preço usado pelo bank de 1,067585 para 0,688542. Os 5 auxiliares então executaram withdraw um por um, resgatando as cotas criadas anteriormente ao preço alto em CES ao preço agora mais baixo. Cada auxiliar recebeu 9.427e18 CES.

• Etapa 3: Após concluir a primeira rodada de withdraw, o atacante trocou o ativo contraparte adquirido de volta por CES, elevando o preço novamente. O atacante então repetiu as Etapas 2-3.

• Etapa 4: Por fim, após múltiplos ciclos de ataque, e após reembolsar o empréstimo relâmpago mais a taxa de 166,097975017841805126 CES, o atacante ficou com 567.736e18 CES como lucro.

Conclusão

A causa raiz deste incidente é que o Tactile liquidou tanto o depósito quanto o saque contra um preço spot manipulável sem ancorar a cota de contabilidade ao valor do ativo ou ao preço no momento do depósito, deixando sua contabilidade interna totalmente exposta a qualquer movimento de preço entre a entrada e a saída.

Protocolos que emitem posições semelhantes a cotas contra um ativo volátil devem ancorar cada cota ao valor concreto do ativo ou ao preço no momento da cunhagem, de modo que o resgate reproduza o valor econômico original em vez de reprecificar contra um oráculo em tempo real. Onde as funções de liquidação devem referenciar um preço atual, elas devem usar fontes ponderadas pelo tempo ou de outra forma resistentes à manipulação e evitar ler o mesmo preço spot que pode ser movido por negociações executadas na mesma transação que a chamada de liquidação.

7. Incidente do Token SAS

Resumo

Em 2 de abril de 2026, o token SAS na BNB Chain foi explorado por aproximadamente $12K. A causa raiz foi uma falha na lógica de transferência personalizada do token: enviar SAS para o pool LP apenas incrementava um contador global sellBurn, e qualquer transferência ordinária subsequente poderia então queimar SAS diretamente do pool e chamar sync() para reescrever suas reservas, tudo sem passar pela lógica de troca do AMM. O atacante explorou isso acumulando sellBurn por meio de vendas, acionando uma transferência ordinária não relacionada para queimar SAS do pool e empurrar sua reserva para 1 wei, e então fazendo uma troca reversa do SAS restante para lucro.

Contexto

SAS é um token deflacionário na BNB Chain com lógica de transferência personalizada construída sobre um pool PancakeSwap V2. Sua função transfer() distingue entre dois caminhos: um caminho de venda, acionado quando o destino de uma transferência é o pool LP, que incrementa um acumulador global sellBurn pelo valor transferido; e um caminho de transferência ordinária, que, quando sellBurn é não nulo, queima SAS diretamente do pool LP e depois chama sync() para atualizar suas reservas ao novo saldo on-chain. Os dois caminhos foram projetados para funcionar juntos como um mecanismo deflacionário que reduz a reserva de SAS do pool em resposta à pressão cumulativa de venda.

Análise de Vulnerabilidade

A falha central no contrato do token SAS (0xbfa266...3d91c6) está em como o mecanismo deflacionário é conectado à transfer(). Quando SAS é enviado para o pool LP, o contrato incrementa um acumulador global sellBurn pelo valor transferido. Então, em qualquer transferência ordinária posterior, se sellBurn for não nulo, o contrato chama _burnFromPair() para queimar SAS diretamente do pool LP e o segue com sync(), que reescreve as reservas do pool para corresponder ao seu saldo on-chain.

O problema é que esse caminho de queima e sincronização reescreve as reservas do pool sem passar pela lógica de troca do AMM. Uma vez que sellBurn tenha sido elevado por transferências para o pool, uma transferência normal não relacionada é suficiente para acionar a queima e a sincronização, forçando a reserva de SAS do pool em direção a zero e criando uma grande distorção de preço que pode então ser explorada por meio de uma troca normal.

Análise do Ataque

A análise a seguir é baseada na transação 0x878e...adc5.

• Etapa 1: O atacante tomou emprestado WBNB via empréstimo relâmpago.

• Etapa 2: O atacante trocou WBNB por SAS.

  

• Etapa 3: O atacante implantou um contrato e executou a lógica de ataque em constructor(). Isso foi usado para contornar a verificação is_contract() do protocolo, pois o contrato do token exigia que o campo from de transfer() fosse um endereço na lista de permissões ou um EOA.

• Etapa 4: O atacante transferiu SAS para o pool, o que acionou o caminho de venda e acumulou sellBurn.

• Etapa 5: O atacante implantou um segundo contrato e, novamente dentro de seu constructor(), iniciou uma transferência ordinária. Com sellBurn já não nulo da Etapa 4, essa transferência acionou a função _burnFromPair(), que queimou SAS diretamente do pool LP e depois chamou a função sync(), reduzindo a reserva de SAS para 1 wei.

• Etapa 6: O atacante realizou uma troca reversa e vendeu o SAS restante para obter lucro.

Conclusão

A causa raiz deste incidente é uma falha na lógica de transferência personalizada do token SAS: uma transferência ordinária poderia queimar diretamente o SAS do pool LP e sincronizar suas reservas ao saldo reduzido, permitindo que a atividade cumulativa de venda fosse transformada em uma redução arbitrária da reserva de SAS do pool e, a partir daí, em uma grande distorção de preço que poderia então ser explorada por meio de uma troca normal.

Os tokens não devem alcançar um pool de AMM externo e mutar suas reservas fora dos caminhos normais de troca. Se um design deflacionário realmente exige queima a partir de um pool, a queima e o sync() acompanhante devem estar vinculados a um gatilho interno rigidamente controlado, como um keeper confiável ou uma programação com limite de taxa, em vez de serem associados a transferências arbitrárias de usuários.

8. Incidente Unknown-EIP-7702

Resumo

Em 3 de abril de 2026, uma conta de usuário na BNB Chain que havia habilitado código delegado via EIP-7702 foi drenada em aproximadamente $17,2K. O código delegado expôs uma função pancakeV3SwapCallback() sem controle de acesso adequado. O atacante chamou diretamente esse callback com calldata forjado, forçando a conta vítima a transferir seus tokens para um endereço controlado pelo atacante.

Contexto

O EOA vítima usou uma transação EIP-7702 do Tipo 4 para definir código delegado, de modo que a conta pudesse executar lógica relacionada a troca. No entanto, a implementação delegada incluía uma função pública pancakeV3SwapCallback() que se destinava a ser chamada apenas durante um callback legítimo do pool PancakeSwap V3.

Análise de Vulnerabilidade

A causa raiz é a ausência de controle de acesso na função pancakeV3SwapCallback() do contrato delegado (0x02C809...aEDbAE).

Em um design correto de callback UniswapV3/PancakeV3, o callback deve verificar que msg.sender é o pool canônico esperado (derivado de fábrica + par de tokens + taxa, ou verificado em uma lista de pools confiáveis). Neste caso, essa validação estava ausente, portanto, qualquer chamador externo poderia invocar o callback diretamente.

Como o callback executa transferências de tokens da conta que o hospeda, a verificação de msg.sender ausente significa que qualquer chamada externa carregando amount0Delta/amount1Delta positivos entra no caminho de pagamento dentro do callback e move tokens para fora da conta vítima, sem que nenhuma troca real ocorra.

Análise do Ataque

A análise a seguir é baseada na transação 0x5b2c...4261.

• Etapa 1: O atacante chamou diretamente pancakeV3SwapCallback() com parâmetros forjados, acionando a lógica de transferência do callback para mover os tokens da vítima para endereços controlados pelo atacante.

Conclusão

Este incidente foi causado pela implantação de lógica de callback de troca em uma conta EIP-7702 sem autenticação estrita do callback. Como pancakeV3SwapCallback() não tinha controle de acesso, o callback poderia ser invocado por qualquer chamador externo e usado para mover tokens para fora da conta vítima sem que nenhuma troca legítima ocorresse.

Para qualquer contrato ou código EIP-7702 delegado que implemente callbacks no estilo V3, os desenvolvedores devem validar que msg.sender é o pool PancakeV3 canônico (derivado da fábrica confiável, do par de tokens e da camada de taxa) antes que o callback entre em qualquer lógica de transferência.

9. Incidente do Silo Finance

Resumo

Em 3 de abril de 2026, o vault soUSDC do Silo Finance na Arbitrum foi explorado por aproximadamente $359K. A causa raiz foi a convergência de três defeitos: um oráculo de wstUSR imutável que ainda precificava o token em ~1,133 mesmo após o seu preço de mercado ter colapsado para ~0,12, um mecanismo de cap de fornecimento no soUSDC que restringia apenas os depósitos do próprio vault, mas não os externos, e uma falha de contabilidade em totalAssets() que contava cotas de bUSDC creditadas externamente sem cunhar as correspondentes cotas de soUSDC. Ao depositar USDC diretamente no mercado wstUSR de cap zero com receiver=soUSDC, o atacante inflou o preço da cota do vault, tomou emprestado o mesmo USDC de volta contra garantia wstUSR supervalorizada e resgatou cotas de soUSDC previamente adquiridas pela valuation inflada, com a diferença extraída de outros mercados saudáveis na fila de saque.

Contexto

Silo Finance é um protocolo de empréstimo com risco isolado na Arbitrum. Cada mercado Silo é um par de empréstimo bilateral (por exemplo, wstUSR/USDC): os tomadores depositam garantia (wstUSR) e tomam emprestado o ativo de empréstimo (USDC), enquanto os credores depositam USDC e ganham juros. Quando um credor deposita USDC em um mercado específico, ele recebe o token de cota de depósito daquele mercado. Quando um tomador deposita garantia, ele recebe um token de cota de garantia (por exemplo, bwstUSR-149).

soUSDC é um SiloVault que fica sobre múltiplos mercados Silo para agregar empréstimos de USDC. Os usuários depositam USDC no soUSDC e recebem cotas de soUSDC. O vault então direciona o USDC depositado para mercados Silo aprovados com base em caps de fornecimento definidos pelo alocador, e o próprio vault detém as cotas de bUSDC de cada mercado em que depositou. Quando um usuário resgata cotas de soUSDC, o vault calcula quanto USDC as cotas valem usando totalAssets(), que itera todos os mercados na fila de saque e soma o saldo de cotas de bUSDC do vault em cada um. O vault então saca USDC de seus mercados subjacentes para pagar o resgatador.

wstUSR (Wrapped Staked USR) é um derivativo de staking do stablecoin USR emitido pela Resolv. Após a exploração da Resolv, o USR perdeu a paridade, o stUSR também perdeu a paridade, e o preço de mercado secundário do wstUSR colapsou para ~0,12. No entanto, o feed Chainlink para wstUSR rastreava apenas a taxa de câmbio wstUSR/stUSR (~1,133), e o protocolo assumia implicitamente que 1 stUSR = 1 USD, portanto, o oráculo continuava precificando wstUSR em ~1,133, uma diferença de ~10x em relação à realidade de mercado.

Análise de Vulnerabilidade

O endereço de oráculo do mercado wstUSR/USDC é codificado como imutável no SiloConfig e não pode ser substituído. O próprio contrato de oráculo (0x836a1a...04425e) é um ChainlinkV3Oracle cujo feed Chainlink subjacente (descrição: "Taxa de Câmbio wstUSR / stUSR") rastreia apenas a proporção de empacotamento de wstUSR para stUSR (~1,133), não o preço de mercado secundário. O protocolo assume implicitamente que 1 stUSR = 1 USD, portanto precifica wstUSR em ~1,133. Após o USR perder a paridade, o stUSR também perdeu a paridade e o wstUSR colapsou para ~0,12 no mercado aberto, mas o oráculo continuou reportando ~1,133, uma supervalorização de ~10x.

O protocolo estava parcialmente ciente do risco: o cap de fornecimento do soUSDC para o mercado wstUSR foi definido como 0, o que significa que o vault nunca direcionaria voluntariamente USDC para ele. No entanto, esse cap governa apenas as chamadas de deposit() de saída do próprio vault. Como wstUSR_Market.deposit() aceita um parâmetro receiver arbitrário, qualquer pessoa pode depositar USDC diretamente no mercado wstUSR e creditar as cotas de bUSDC resultantes para o endereço do soUSDC, contornando completamente o cap de fornecimento.

Isso cria o caminho central de exploração. Quando as cotas de bUSDC chegam ao saldo do soUSDC por meio de tal depósito externo, totalAssets() as contabiliza: ele itera todos os mercados na fila de saque e lê o saldo real de cotas do vault, sem verificação de se a posição foi voluntariamente inserida. Enquanto isso, nenhuma nova cota de soUSDC é cunhada para essas posições creditadas externamente, porque a própria lógica de cunhagem do vault nunca foi invocada. O resultado é que totalAssets aumenta enquanto totalShares permanece o mesmo, inflando o preço da cota de soUSDC.

Análise do Ataque

A análise a seguir é baseada na transação 0xf77a...f3e1.

O atacante primeiro comprou wstUSR no mercado secundário a ~0,12 por token.

• Etapa 1: Empréstimo relâmpago de ~4.236.352 USDC da Morpho. A precificação incorreta do oráculo por si só não é suficiente — o mercado wstUSR tinha liquidez zero de USDC (cap=0, soUSDC nunca depositou lá), portanto não há nada a tomar emprestado contra a garantia supervalorizada. O empréstimo relâmpago fornece o capital necessário para as etapas subsequentes de depósito e doação.

• Etapa 2: Depositar wstUSR no mercado wstUSR como garantia e receber bwstUSR-149. Esta é a preparação para o empréstimo da Etapa 5 — o oráculo valoriza 13.797 wstUSR em ~15.633 (a 1,133 cada), embora o atacante tenha pago apenas ~1.656.

• Etapa 3: Depositar ~4.222.007 USDC no vault soUSDC, recebendo cotas de soUSDC (~91,5% do fornecimento total). O vault direciona esse USDC para mercados saudáveis existentes (não o mercado wstUSR, pois cap=0). Essas cotas de soUSDC são o instrumento para extrair lucro na Etapa 6 — quanto mais cotas o atacante detém, mais se beneficia quando o preço da cota é inflado.

• Etapa 4: Depositar ~14.344 USDC diretamente no mercado wstUSR via wstUSR_Market.deposit(receiver=soUSDC) e cunhar bUSDC-149 para o soUSDC. As cotas de bUSDC resultantes são creditadas ao endereço do soUSDC, não ao do atacante. Esta é a manipulação central: totalAssets() do soUSDC agora inclui essas cotas de bUSDC pelo valor nominal (~14.344 USDC), mas nenhuma nova cota de soUSDC é cunhada porque a própria lógica de depósito do vault nunca foi invocada — totalAssets sobe, totalShares permanece o mesmo, e o preço da cota de soUSDC é inflado. Ao mesmo tempo, isso cria liquidez de USDC no mercado wstUSR anteriormente vazio, o que é necessário para a próxima etapa.

• Etapa 5: Tomar emprestado ~14.344 USDC do mercado wstUSR usando a garantia depositada na Etapa 2. O oráculo precifica a garantia em ~15.633, portanto, com 92% de maxLTV, o atacante pode tomar emprestado ~14.344. Isso recupera o USDC doado na Etapa 4 — o empréstimo e a doação são neutros em caixa. Mas o mercado wstUSR agora está completamente drenado: todo o USDC foi tomado emprestado, deixando apenas um empréstimo em aberto garantido por garantia wstUSR quase sem valor. O soUSDC ainda detém as cotas de bUSDC pelo valor nominal em totalAssets().

• Etapa 6: Resgatar todas as cotas de soUSDC adquiridas na Etapa 3. O preço da cota agora está inflado pela doação da Etapa 4, portanto, o atacante recebe ~4.235.143 USDC, cerca de ~13.136 a mais do que os 4.222.007 depositados na Etapa 3. O vault tenta sacar do mercado wstUSR, mas encontra liquidez zero (tomada emprestada na Etapa 5), portanto, extrai a diferença de outros mercados saudáveis na fila de saque. É aqui que a perda se materializa: USDC real dos mercados de outros depositantes do soUSDC é transferido para cobrir o resgate inflado.

• Etapa 7: Reembolsar o empréstimo relâmpago.

Após 32 iterações, o soUSDC fica com posições de bUSDC no mercado wstUSR avaliadas pelo valor nominal em ~359K, mas garantidas por garantia wstUSR que vale uma fração disso — 100% de utilização, efetivamente dívida irrecuperável suportada pelos depositantes restantes do soUSDC.

Conclusão

Este incidente foi causado pela convergência de um oráculo que rastreava uma taxa de câmbio de staking em vez do preço de mercado de um ativo que perdeu a paridade, um sistema de contabilidade de vault que contava posições creditadas externamente em totalAssets() sem cunhar as cotas correspondentes, e um mecanismo de cap de fornecimento que restringia apenas os depósitos do próprio vault, mas não os externos. O endereço de oráculo sendo imutável no SiloConfig impediu qualquer correção de emergência após o problema se tornar aparente.

Protocolos de vault que agregam entre mercados de empréstimo devem garantir que totalAssets() apenas contabilize posições que o vault inseriu por meio de suas próprias operações de depósito, não saldos de cotas creditados externamente. Os endereços de oráculo não devem ser permanentemente imutáveis; mecanismos de governança de emergência devem existir para atualizações de feeds de preço quando os ativos subjacentes perdem a paridade.

Sobre a BlockSec

A BlockSec é uma provedora completa de segurança blockchain e conformidade cripto. Desenvolvemos produtos e serviços que ajudam nossos 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 cumprir 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, relatou 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 : Enviar uma solicitação

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

• 🔗 Phalcon Compliance