Resumo Semanal de Incidentes de Segurança Web3 | 6 a 12 de Abr de 2026

Durante a última semana (2026/04/06 - 2026/04/12), a BlockSec detectou e analisou quatro incidentes de ataque, com perdas totais estimadas em aproximadamente $928,6K. A tabela abaixo resume esses incidentes, e análises detalhadas de cada caso são fornecidas nas subseções a seguir.

*O incidente Denaria não foi coberto no relatório da semana passada e está incluído aqui para completude.

A partir desta semana, destacamos um incidente no topo de cada relatório. A seleção não é necessariamente baseada no valor da perda — pode ser escolhido por seu design de protocolo inovador, técnica de ataque inteligente ou lições mais amplas para a comunidade.

Destaque da Semana: Incidente Denaria

A DEX perpétua Denaria introduziu mecanismos de contabilidade inovadores respaldados por uma lógica de código complexa. No entanto, uma refatoração pós-auditoria introduziu uma assimetria de arredondamento que poderia produzir um caso extremo sutil — um valor negativo —, que acabou atingindo um cast inseguro e permitiu uma extração astronômica de valor.

Em 5 de abril de 2026, a DEX perpétua da Denaria na Linea foi explorada em aproximadamente $165,6K em perdas. A causa raiz foram duas falhas combinadas em getLpLiquidityBalance(): uma refatoração pós-auditoria na contabilidade de saldo de LP introduziu uma assimetria de arredondamento que poderia produzir um valor intermediário ligeiramente negativo, e um cast inseguro de int256 para uint256 silenciosamente convertia esse valor negativo em um inteiro sem sinal quase máximo, em vez de reverter. O atacante explorou isso por meio de um depósito de LP unilateral e uma operação de compra (long), retirando em seguida o PnL artificialmente inflado do cofre.

Contexto

Denaria é uma DEX perpétua na Linea construída em torno de um AMM virtual dinâmico. Ela separa negociação e liquidação em dois componentes. O mercado PerpPair gerencia as posições dos usuários e a contabilidade de LP, enquanto o Vault mantém o colateral e liquida o PnL realizado.

A propriedade de LP no PerpPair não é representada por um saldo de token explícito. Em vez disso, o protocolo reconstrói o estado de cada LP a partir de uma matriz de contabilidade interna composta por dois componentes de escrituração, referidos aqui como o lado do ativo e o lado estável. O lado do ativo rastreia a participação do LP na exposição do pool às movimentações de preço, enquanto o lado estável rastreia sua participação no valor denominado em estável do pool. Juntos, esses dois componentes determinam conjuntamente como o valor de um LP é rastreado e liquidado.

É fundamental observar que esses componentes não são armazenados como snapshots estáticos. Cada vez que uma negociação ocorre, o PerpPair atualiza seu estado global de liquidez, e o saldo reconstruído de cada LP é derivado da diferença entre os valores cumulativos globais e o snapshot do ponto de entrada do LP. Esse mecanismo de contabilidade foi introduzido em uma refatoração pós-auditoria que substituiu o acumulador original baseado em cotas por rastreamento direto de saldo. No entanto, o caminho subtrativo refatorado introduziu uma assimetria de arredondamento que poderia fazer com que os componentes de LP reconstruídos se tornassem ligeiramente negativos sob certas sequências de negociação.

Análise de Vulnerabilidade

O contrato PerpPair vulnerável (0xb683...36ae17) contém duas falhas combinadas.

1. Assimetria de arredondamento na contabilidade refatorada. A refatoração pós-auditoria que introduziu o rastreamento direto de saldo criou uma assimetria de arredondamento no caminho de reconstrução subtrativa. Sob certas sequências de negociação, o valor cumulativo global após arredondamento poderia se tornar marginalmente menor do que o snapshot do ponto de entrada do LP, fazendo com que a subtração produzisse um pequeno resultado negativo em vez de zero. Em teoria, esse valor deveria ter sido zero ou próximo de zero; a assimetria era uma falha específica dessa implementação refatorada, não uma propriedade inerente da contabilidade subtrativa em geral.

2. Cast inseguro de tipo com sinal para sem sinal. Em getLpLiquidityBalance(), um componente de saldo de LP reconstruído era convertido de int256 para uint256 sem validação. Em Solidity, converter um int256 negativo para uint256 não reverte; ele envolve o valor módulo 2^256, transformando um número negativo pequeno como -1 em um inteiro sem sinal quase máximo (2^256 - 1). Como esse saldo reconstruído alimentava calcPnL() para liquidação, qualquer entrada negativa seria interpretada como uma posição de LP enorme, permitindo que um atacante realizasse um lucro artificialmente inflado e drenasse fundos do cofre.

Nenhuma falha isolada seria explorável. A assimetria de arredondamento produzia apenas um valor ligeiramente negativo, que sob aritmética int256 normal simplesmente representaria um erro insignificante. Mas, uma vez que esse valor negativo atingia o cast sem guarda, ele se convertia em um inteiro sem sinal quase máximo. Uma verificação de limites subsequente então limitava o valor convertido à liquidez total do lado do ativo do pool, convertendo efetivamente o overflow em uma reivindicação sobre todo o lado do ativo do mercado.

Análise do Ataque

A análise a seguir é baseada na transação de ataque 0xcb0744...0c606447.

• Passo 1: O atacante tomou emprestado 60.000 USDC por meio de um flash loan da Aave.

• Passo 2: Um endereço auxiliar depositou 30.000 USDC como colateral e adicionou uma posição de LP somente no lado estável de 19.980 tokens estáveis. Ao depositar apenas no lado estável, o auxiliar garantiu que seu componente de LP do lado do ativo começasse próximo de zero, tornando-o mais suscetível a cruzar para o território negativo por arredondamento.

• Passo 3: Um segundo endereço auxiliar depositou 15.000 USDC e abriu uma posição long nocional de 100.000, causando uma atualização de liquidityM que introduziu o principal erro de arredondamento. O grande tamanho nocional em relação à liquidez do pool amplificou o impacto do arredondamento por negociação, empurrando o saldo reconstruído do lado do ativo do primeiro auxiliar ligeiramente abaixo de zero.

• Passo 4: O primeiro auxiliar então invocou realizePnL(). Durante a reconstrução do saldo de LP, o lpAssetBalance negativo foi convertido para um uint256 quase máximo. Esse valor grande foi então limitado à liquidez total do lado do ativo do mercado e gerou um lucro altamente inflado. Na prática, o protocolo acreditava que o LP possuía todo o lado do ativo do mercado.

• Passo 5: O atacante retirou o PnL inflado do cofre.

O mesmo padrão foi repetido até que a liquidez restante do cofre fosse drenada. Após reembolsar o flash loan, o atacante realizou um lucro de aproximadamente $165,6K.

Conclusão

Este exploit foi causado, em última análise, pela ausência de validação de limites em uma conversão de tipo com sinal para sem sinal. A correção imediata é direta: substituir o cast simples por SafeCast.toUint256(), que reverte em entradas negativas em vez de envolvê-las.

De forma mais ampla, este incidente ilustra o risco de refatorações pós-auditoria que ignoram a revisão externa. De acordo com o post-mortem oficial, a assimetria de arredondamento foi introduzida após a auditoria externa final, quando a equipe substituiu o acumulador original pelo rastreamento direto de saldo. Embora a refatoração tenha resolvido uma preocupação com overflow, ela criou um novo caso extremo que os testes internos não detectaram. Quando protocolos refatoram a lógica de contabilidade central, o novo caminho de código deve ser tratado como crítico para a segurança e reauditado, especialmente quando valores reconstruídos alimentam diretamente a liquidação de PnL ou a lógica de retirada.

Incidente HB Token

Em 7 de abril de 2026, o HB, um token ERC-20 personalizado com hooks de compra/venda embutidos na BNB Chain, foi explorado em aproximadamente $193K. A causa raiz foi uma lógica de liquidação de recompensas falha: quando acionada, ela chamava swapBack(), que removia reservas de HB diretamente do par da PancakeSwap e então chamava sync() para reprecificar o pool. Após o atacante comprar a maior parte do HB do par, a execução subsequente de swapBack() reduziu ainda mais a liquidez restante e inflou acentuadamente o preço spot. O atacante então vendia quantidades minúsculas de HB no pool distorcido por quantidades desproporcionalmente grandes de USDT, repetindo o ciclo até que o par fosse drenado.

Contexto

HB é um token ERC-20 personalizado na BNB Chain com hooks de compra e venda embutidos em _transfer(). Quando os usuários compram do par AMM, _handleBuy() registra informações de base de custo. Quando os usuários vendem, _handleSell() ramifica em diferentes caminhos de taxa e liquidação dependendo do estado do par.

O token também inclui um mecanismo de liquidação de recompensas que pode acionar swapBack(). Em vez de realizar uma troca normal mediada pelo roteador, swapBack() transfere HB diretamente do par da PancakeSwap para o endereço PROOF, em seguida força o par a ressincronizar via sync(). Isso permite ao contrato reduzir as reservas de HB do par fora dos fluxos normais de negociação AMM e reprecificar imediatamente o pool para cima.

Análise de Vulnerabilidade

A falha central no contrato do token HB (0x62ce...87a4b0) era que swapBack() obtinha recompensas puxando tokens diretamente do par AMM em vez de de um tesouro ou por meio de uma troca mediada por roteador. Como swapBack() era acessível pelo caminho de liquidação de recompensas, um caminho de código sem negociação poderia mutar diretamente as reservas do par e alterar o preço spot.

Quando as reservas de HB do par estão baixas, uma invocação de swapBack() reduz ainda mais o HB restante e amplifica a distorção de preço, tornando possível vender quantidades minúsculas de HB a preços extremamente inflados.

Análise do Ataque

A análise a seguir é baseada na transação de ataque 0x19671f...d71594ed.

• Passo 1: O atacante tomou grandes quantias emprestadas da Venus.

• Passo 2: O atacante transferiu aproximadamente 1.496 HB para o contrato do token, aumentando o saldo de HB do contrato para que o subsequente swapBack() pudesse puxar uma quantidade maior do par.

• Passo 3: Ao transferir uma quantidade minúscula de HB para o par da PancakeSwap, o atacante acionou _swapAndLiquify(), que trocou aproximadamente 4.163 HB mantidos pelo contrato do token por 10 USDT e aumentou as recompensas de HB reivindicáveis pelo atacante.

• Passo 4: O atacante então gastou 72.117.360 USDT para comprar 73.608.753 HB, deixando o par com muito pouca liquidez restante de HB.

• Passo 5: Em seguida, o atacante acionou o caminho de déficit de recompensas. Para satisfazer as recompensas, o token invocou swapBack(), que puxou HB adicional do par da PancakeSwap e forçou sync(), aumentando acentuadamente o preço do HB.

• Passo 6: O atacante transferiu diretamente USDT para o par para reabastecer suas reservas de USDT, depois vendeu apenas 0,000582 HB por 37.582.322 USDT ao preço distorcido.

Repetindo o Passo 6 para vender tokens HB a um preço distorcido, o atacante extraiu quase todo o USDT do pool.

Conclusão

O incidente do token HB ilustra o perigo de permitir que a lógica de recompensas mute diretamente as reservas do AMM. Funções que afetam reservas nunca devem ser acessíveis por caminhos de liquidação de recompensas, e os protocolos devem evitar confundir saldos internos de tokens com a contabilidade de reservas do AMM em fluxos de controle críticos para a segurança. Qualquer design que dependa da precificação spot do AMM após perturbar internamente o pool é inerentemente vulnerável à manipulação de preços.

Incidente Squid Multicall

Em 7 de abril de 2026, um usuário do Squid perdeu aproximadamente $517K em múltiplas redes em um incidente relacionado a aprovações. O usuário aproveitou erroneamente um contrato SquidMulticall em vez do Squid Router pretendido. Isso permitiu ao atacante invocar uma função SquidMulticall.run() sem permissão para executar chamadas externas arbitrárias. O atacante podia, portanto, usar qualquer aprovação concedida ao contrato para executar chamadas transferFrom() de tokens contra usuários que o tinham aprovado.

Contexto

No fluxo normal do Squid, os usuários devem aprovar o Squid Router, enquanto o SquidMulticall atua apenas como um auxiliar de execução. O contrato auxiliar é projetado para executar chamadas em lote como parte da lógica de roteamento, mas não deve ser o gastador que os usuários aprovam diretamente para transferências de tokens.

Como as verificações de aprovação ERC-20 são realizadas apenas contra o endereço do gastador, qualquer contrato que combine aprovações de usuários com capacidade de chamada arbitrária irrestrita cria um sumidouro de aprovação perigoso: uma vez aprovado, esse contrato pode se tornar um vetor genérico de retirada de tokens se alguém puder controlar quais chamadas ele realiza.

Análise de Vulnerabilidade

Este incidente não foi causado por uma vulnerabilidade em contrato inteligente. A perda resultou de duas condições ocorrendo juntas: uma aprovação equivocada direcionada ao SquidMulticall em vez do Router, e o design sem permissão de run() aceitando alvos e calldata arbitrários de qualquer chamador.

O SquidMulticall é destinado a executar chamadas em lote como uma etapa downstream no fluxo do Router, onde as entradas são construídas por lógica de roteamento confiável. Usado conforme pretendido, o design sem permissão não representa risco. Mas uma aprovação equivocada muda isso completamente: um bot de MEV detectou a aprovação ativa, chamou run() com calldata elaborado para invocar transferFrom(vítima, atacante, quantia) e drenou os tokens aprovados em cada rede sem qualquer ação adicional da vítima.

Análise do Ataque

O incidente afetou um usuário na BNB Chain, Arbitrum, Optimism, Avalanche e Base. A análise a seguir é baseada na transação de ataque 0x81d0c4...9b1301e9.

• Passo 1: A vítima (0xacc0...f40e98) aproveitou erroneamente o SquidMulticall em vez do Squid Router pretendido.

• Passo 2: Um bot de MEV detectou essa aprovação e invocou SquidMulticall.run() com calldata elaborado.

• Passo 3: Por meio da chamada arbitrária, o SquidMulticall invocou transferFrom(vítima, atacante, quantia) e transferiu os ativos aprovados da carteira da vítima.

Conclusão

Este incidente ilustra o risco de contratos de chamada arbitrária sem permissão coexistindo com fluxos de aprovação voltados ao usuário. A causa imediata foi uma aprovação equivocada e, como o SquidMulticall aceitava chamadores irrestritos, alvos arbitrários e calldata arbitrário, qualquer aprovação erroneamente direcionada a ele era imediata e totalmente explorável. Protocolos que utilizam contratos auxiliares de execução devem considerar adicionar restrições de chamador ou limitar os alvos de chamada permitidos por tais funções, para que uma aprovação equivocada não possa ser trivialmente usada como arma.

Incidente XBIT

Em 11 de abril de 2026, o token XBIT na BNB Chain foi explorado em aproximadamente $53K. A causa raiz foi uma falha de controle de acesso fail-open no XBITVault: a verificação de autorização da função transfer() era condicional — ela só aplicava msg.sender == xbitContract quando xbitContract era diferente de zero, e passava silenciosamente caso contrário. Como bindXBIT() nunca havia sido chamado para inicializar o contrato, essa falha estava permanentemente exposta, permitindo que chamadores arbitrários movessem saldos de XBIT de qualquer endereço, incluindo o par XBIT/USDT da PancakeSwap. O atacante usou isso para drenar XBIT do par e então vendeu repetidamente quantidades minúsculas de XBIT de volta ao pool por quantidades desproporcionalmente grandes de USDT.

Contexto

O XBITVault não é um contrato de tesouro passivo. Ele é o backend de saldo e aprovação para o sistema de tokens XBIT, expondo funções semelhantes a tokens como transfer(), approve() e mintForXBIT(). Sob o design pretendido, o proprietário deve primeiro chamar bindXBIT() para inicializar o cofre definindo xbitContract, pancakePair, pairContract e xbitDecimals. Após a inicialização, funções sensíveis de mudança de estado deveriam ser chamáveis apenas pelo contrato XBIT vinculado. Em outras palavras, o modelo de segurança do cofre depende de uma inicialização bem-sucedida antes do uso público.

Análise de Vulnerabilidade

A falha crítica é que o controle de acesso é condicional no contrato XBITVault vulnerável (0xc879...42391a). A função transfer() só verifica msg.sender == xbitContract quando xbitContract != address(0). Isso significa que a função não reverte quando xbitContract não está definido, tornando-se publicamente chamável por qualquer pessoa. Como os saldos são armazenados em _balances, qualquer chamador externo pode mover XBIT de qualquer endereço para qualquer outro endereço, desde que o endereço de origem tenha saldo suficiente.

O caminho de inicialização pretendido era bindXBIT(), mas como ele nunca foi chamado, o cofre permaneceu em estado não inicializado e fail-open. O resultado foi efetivamente uma primitiva irrestrita de transferência arbitrária de saldo.

Análise do Ataque

A análise a seguir é baseada na transação de ataque 0xbc877f...4df1b694.

• Passo 1: Por meio da função transfer() irrestrita, o atacante moveu 1.526.216,569 XBIT do par XBIT/USDT sem fornecer nenhum USDT correspondente.

• Passo 2: O atacante invocou sync() para colapsar as reservas de XBIT do par para apenas 1-2 unidades.

• Passo 3: Após o par ficar com liquidez de XBIT próxima de zero, o atacante vendeu XBIT repetidamente, drenando aproximadamente 53.112 USDT do par.

Conclusão

Este incidente foi causado por uma verificação de controle de acesso dependente de inicialização que falhou de forma aberta. O transfer() era irrestrito sempre que xbitContract não estava definido, e como bindXBIT() nunca foi chamado, o cofre expôs permanentemente uma primitiva pública de transferência arbitrária de saldo. Funções privilegiadas devem reverter até que a inicialização seja concluída, e as etapas de vinculação no momento da implantação devem ser pré-requisitos aplicados on-chain em vez de suposições operacionais.

Sobre a BlockSec

A BlockSec é um provedor completo de segurança em blockchain e conformidade cripto. Desenvolvemos produtos e serviços que ajudam 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 em blockchain em conferências de prestígio, reportou vários ataques zero-day 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