~$16M Perdidos: DxSale, SquidRouterModule e Mais | BlockSec Semanal

Durante a semana passada (2026/05/25 - 2026/05/31), a BlockSec identificou múltiplos incidentes de ataque em vários ecossistemas de blockchain. A tabela abaixo lista 5 incidentes notáveis com perdas totais estimadas em aproximadamente $16M.

Data	Incidente	Tipo	Perda Estimada
2026/05/27	SquidRouterModule	Validação de Entrada Inadequada	~$3,2M
2026/05/29	Stake DAO	Chave Privada Comprometida	~$91K*
2026/05/29	DxSale	Lógica de Negócio Incorreta e Comprometimento de Chave	~$7,3M
2026/05/30	Gravity Bridge	Processo de Assinatura Off-chain Vulnerável	~$5,4M
2026/05/30	Alephium	Processo de Assinatura Off-chain Vulnerável	~$300K*

*Notas adicionais:

No incidente do Stake DAO, o atacante comprometeu a chave privada do deployer e a utilizou para reconfigurar o peer Axelar v2 OFT do LayerZero v2 no contrato vsdCRV na Arbitrum, permitindo a cunhagem de 5,4 trilhões de vsdCRV. Devido à liquidez limitada na DEX, apenas aproximadamente $91K foi sacado antes que os pools se esgotassem.
No incidente do Alephium, além dos aproximadamente $300K em ativos custodiados pela bridge drenados (USDT, USDC, WETH, WBTC na Ethereum e USDT, WBNB na BNB Chain), o atacante também cunhou 13,7M de wALPH sem lastro na Ethereum. A bridge foi desligada, impedindo o atacante de resgatar ou fazer bridge desses tokens de volta pela bridge da Alephium.

Dois incidentes foram selecionados para análise aprofundada:

SquidRouterModule: Assim como o exploit do CrossCurveFi, repetiu a mesma classe de erro de integração, demonstrando como fazer fork de lógica cross-chain sem compreensão profunda e revisão de segurança rigorosa pode rapidamente transformar complexidade herdada em risco herdado.
DxSale: Sua longa linha do tempo de ataque mostra que contratos legados não explorados não são necessariamente seguros, e que os protocolos devem monitorar continuamente a atividade on-chain e off-chain, minimizar o acesso privilegiado e nunca confundir anos de silêncio com prova de segurança.

Destaque da Semana: DxSale

Este incidente foi selecionado como destaque da semana porque a combinação de um contrato de bloqueio sem correção há anos e uma chave de deployer comprometida ilustra um padrão recorrente: protocolos que tratam o código do momento da implantação como permanentemente seguro, sem auditoria contínua ou rotação de privilégios, carregam riscos ocultos que podem ser utilizados como arma a qualquer momento.

Em 29 de maio de 2026, a DxSale, uma plataforma de venda de tokens e bloqueio de liquidez na BNB Chain, foi explorada [1] em aproximadamente $7,3M. A função de saque de tokens continha três atualizações de estado ausentes que permitiam que qualquer usuário com uma posição de bloqueio válida sacasse repetidamente e drenasse todo o pool compartilhado, sem necessidade de privilégios de proprietário. Um comprometimento separado da chave do deployer da DxSale via delegação EIP-7702 não era um pré-requisito para o exploit, mas amplificou a eficiência do atacante ao permitir a manipulação de taxas e bloquear outros usuários de criarem novos bloqueios.

Contexto

A DxSale é uma plataforma de venda de tokens e bloqueio de liquidez na BNB Chain. Seu componente DxLock permite que desenvolvedores de projetos bloqueiem tokens LP em cofres com bloqueio temporal, fornecendo garantia aos investidores de que a liquidez não pode ser removida de forma maliciosa (rug-pull).

O mecanismo central de bloqueio funciona da seguinte forma: um usuário deposita tokens no contrato de bloqueio, criando um registro de bloqueio indexado pela combinação do endereço do chamador e um ID de token. Cada registro armazena se o bloqueio existe, se os tokens estão atualmente bloqueados, o valor bloqueado, o timestamp de desbloqueio e o endereço do token. Quando o período de bloqueio expira, o usuário chama unlockToken(tokenId) para sacar seus tokens.

Como o contrato de bloqueio mantém tokens de muitos usuários simultaneamente em um saldo compartilhado, as alocações individuais devem ser rastreadas com precisão por meio de registros de bloqueio separados. A segurança de todo o pool depende de cada saque validar corretamente o registro do próprio chamador e atualizá-lo após a transferência.

Análise de Vulnerabilidade

A função unlockToken no contrato com bug (0xeb3a...e449) continha três defeitos compostos, cada um sendo uma atualização de estado ou verificação ausente:

function unlockToken(uint256 tokenId) public nonPayable {
    require(_increaseLockTime[msg.sender][tokenId].field0_0_0);  // locker exists
    require(_increaseLockTime[msg.sender][tokenId].field0_1_1);  // tokens are locked
    require(_increaseLockTime[msg.sender][tokenId].field2);       // amount > 0

    if (block.timestamp > _increaseLockTime[msg.sender][tokenId].field3) {
        _increaseLockTime[msg.sender][tokenId].field0_1_1 = 0;
    }

    v0, v1 = _increaseLockTime[msg.sender][tokenId].field5_0_19.balanceOf(this);
    require(v1 >= _increaseLockTime[msg.sender][tokenId].field2);
    v2, v3 = _increaseLockTime[msg.sender][tokenId].field5_0_19.transfer(
        msg.sender, _increaseLockTime[msg.sender][tokenId].field2
    );
}

Nenhuma aplicação do período de bloqueio. O período de bloqueio era protegido por uma instrução if em vez de um require. Quando chamada antes do timestamp de desbloqueio, a função simplesmente ignorava a limpeza da flag de bloqueio em vez de reverter. Isso significava que os tokens podiam ser sacados a qualquer momento, independentemente do período de bloqueio.
Valor bloqueado nunca zerado. Após transferir tokens para o chamador, a função não zerava field2 (o valor bloqueado). Cada chamada subsequente lia o mesmo valor original e sacava o mesmo valor novamente, criando um loop de saque infinito.
Verificação de saldo compartilhado em vez de alocação individual. A chamada balanceOf(this) verificava o saldo total de tokens do contrato em vez da alocação individual do chamador. Um chamador com uma pequena posição de bloqueio podia drenar todo o pool compartilhado enquanto o contrato ainda mantivesse tokens totais suficientes.

Juntos, esses três estados ausentes removeram toda condição de saída da função: a chamada nunca revertia prematuramente, o valor do saque nunca diminuía e a verificação de saldo nunca bloqueava até o contrato ser completamente esvaziado. O bug era explorável por qualquer usuário que criasse uma posição de bloqueio; nenhum privilégio de proprietário era necessário para a drenagem principal.

Análise do Ataque

A conta deployer da DxSale (0x47bacf93), operando via delegação EIP-7702, exibiu atividade anômala desde 2026-04-15, incluindo transferências em massa de propriedade, alterações de taxas e operações de desbloqueio de LP em múltiplos contratos da DxSale. Em 2026-05-26, o deployer transferiu a propriedade do contrato de bloqueio vítima (0xeb3a...e449) para o contrato do atacante (0xc457...fa69). Dois dias depois, o atacante executou uma drenagem em cinco etapas.

A análise a seguir é baseada em uma transação representativa 0x437b26...c1b303.

Etapa 1: O atacante trocou BNB por tokens BNBC na PancakeSwap e forneceu liquidez para criar um novo par Cake-LP (BNBC/WBNB), recebendo aproximadamente 0,323 tokens LP.
Etapa 2: Usando os privilégios de proprietário obtidos via transferência de propriedade anterior, o atacante chamou changeFees(1) para definir a taxa de criação de bloqueio para 1 wei, depois chamou createLocker para depositar os aproximadamente 0,323 tokens LP em uma nova posição de bloqueio (tokenId=131). Imediatamente após, o atacante chamou changeFees(10^36) para elevar a taxa a um valor astronômico, impedindo outros usuários de criarem novos bloqueios.
Etapa 3: O atacante chamou a função de exploit (0x11b432b4), que orquestrou chamadas repetidas de unlockToken em uma única transação. Em múltiplas transações, o atacante drenou sistematicamente o contrato de bloqueio: 0x437b26...c1b303 drenou 161,4 tokens LP via tokenId=131, 0x82f541...a9fa73 e 0x5dd61f...4298aa drenaram posições de bloqueio adicionais, e 0xac8f5e...d36df9 drenou 260,3 tokens LP via tokenId=319 em 478 chamadas.
Etapa 4: O atacante chamou removeLiquidity na PancakeSwap para converter os tokens LP drenados de volta em seus tokens subjacentes (BNBC e WBNB).
Etapa 5: O atacante trocou os tokens subjacentes por WBNB e BUSD via PancakeSwap e transferiu os lucros para endereços externos. O BSCScan registrou 123.447 transações ao longo de 4 dias (2026-05-28 a 05-31) para este contrato atacante.

Conclusão

A causa raiz deste incidente são as três atualizações de estado ausentes em unlockToken. Cada uma tem uma correção direta: impor o período de bloqueio com require em vez de if, zerar o valor bloqueado após cada saque e verificar a alocação individual do chamador em vez do saldo total do contrato. Esses defeitos por si só foram suficientes para a exploração; qualquer usuário que criasse uma posição de bloqueio podia drenar todo o pool compartilhado por meio de chamadas repetidas, sem necessidade de privilégios de proprietário.

O comprometimento anterior do deployer da DxSale via delegação EIP-7702 não era um pré-requisito para o exploit, mas amplificou a eficiência do atacante. Ao transferir a propriedade e manipular as taxas, o atacante criou posições de bloqueio com custo quase zero e bloqueou usuários legítimos de criarem bloqueios concorrentes. No aspecto operacional, os protocolos devem auditar continuamente contratos legados, especialmente aqueles que detêm fundos de usuários, e evitar a custódia de funções administrativas por chave única. Anos de operação sem incidentes não validam a segurança de código não auditado.

Referências

[1] Comunicado da DxSale

Mais Incidentes desta Semana

SquidRouterModule

Em 27 de maio de 2026, um contrato desconhecido chamado SquidRouterModule foi explorado [1] na Ethereum devido a validação de entrada inadequada, resultando em aproximadamente $3,2M em perdas. A causa raiz foi um uso inadequado da integração com a Axelar Bridge, similar ao padrão de ataque anterior do CrossCurveFi [2]. O contrato não validava adequadamente as mensagens cross-chain através do Axelar Gateway, permitindo que o atacante forjasse payloads que autorizavam e trocavam os tokens das vítimas em pools maliciosos pré-construídos. Um endereço de atacante separado que havia implantado o token falso e semeado os pools posteriormente removeu a liquidez para extrair os ativos reais. Este ataque afetou 86 carteiras Safe. Apesar do nome, o SquidRouterModule não foi construído, implantado ou operado pela equipe do protocolo Squid [3].

Contexto

O contrato é um módulo de serviço de câmbio cross-chain projetado para a carteira Safe, construído sobre o protocolo cross-chain Axelar. O contrato fornece a função expressExecuteWithToken, suportando a execução antecipada de transações antes da confirmação de mensagens cross-chain. Os usuários devem pré-autorizar as permissões APPROVE e SWAP do contrato em sua carteira Safe antes de usar este serviço. Quando expressExecuteWithToken é chamado, o contrato decodifica as instruções de operação no payload e chama execTransactionFromModule da carteira Safe para executar operações de autorização e troca de tokens.

Análise de Vulnerabilidade

A função _executeWithToken no contrato vulnerável (0x1f1d...23ca) apenas verificava se srcAddress era igual à constante squidRouter. No entanto, srcAddress é um parâmetro fornecido pelo chamador, enquanto squidRouter é uma string imutável que qualquer pessoa pode ler do contrato. Isso permitia ao atacante contornar trivialmente a verificação e executar a função _processPayload com conteúdo de payload arbitrário.

Em contraste, a função executeWithToken do Squid Router legítimo chama gateway.validateContractCallAndMint() e reverte com NotApprovedByGateway() se a rede de validadores Axelar não tiver confirmado a transação.

O contrato vulnerável não aplicava nenhuma autorização de gateway no caminho expressExecuteWithToken. Combinado com as permissões APPROVE e SWAP que os usuários da carteira Safe pré-autorizaram ao módulo, payloads forjados podiam operar diretamente nos fundos das vítimas.

Análise do Ataque

A análise a seguir é baseada na transação 0xd29d1c...3bb854.

Antes do ataque, um endereço de atacante separado implantou um token falso (0xe6Ff...3512) e criou múltiplos pools Uniswap V3, cada um pareando o token falso com um token valioso diferente (ex.: USDC, ENA, USDT), semeando os pools com liquidez do token falso.

Etapa 1: O atacante forjou calldata maliciosos e chamou a função expressExecuteWithToken do contrato vulnerável, usando o endereço conhecido squidRouter como sourceAddress para contornar a verificação de validação. Por meio das permissões APPROVE e SWAP que a vítima havia pré-autorizado ao módulo, o payload forjado forçou aprovações de tokens da carteira Safe da vítima para o pool Uniswap.
Etapa 2: Usando essas aprovações forçadas, o payload trocou os tokens da vítima pelo token falso sem valor por meio do pool malicioso correspondente.

O atacante repetiu esse método em múltiplas transações, visando um total de 86 carteiras Safe que haviam autorizado o contrato vulnerável. O endereço de atacante separado que havia implantado o token falso e semeado os pools subsequentemente removeu liquidez para extrair os ativos reais, lucrando aproximadamente $3,2M.

Conclusão

Este incidente foi causado por validação de entrada inadequada no caminho de tratamento de mensagens cross-chain. A única verificação de segurança dependia de um parâmetro controlável pelo chamador comparado a uma constante publicamente legível, sem fornecer proteção real. Combinado com as permissões APPROVE e SWAP pré-autorizadas pelos usuários da carteira Safe, o atacante podia forjar mensagens cross-chain e roubar fundos dos usuários.

O incidente é semelhante ao exploit do CrossCurveFi [2]: ambos envolvem integrações com a Axelar Bridge que falharam em validar adequadamente as mensagens cross-chain recebidas. Ao integrar infraestrutura de mensagens cross-chain, o contrato de destino deve validar de forma independente a autenticidade das mensagens por meio do mecanismo de autorização da bridge. Ignorar essa validação e depender de entradas controláveis pelo atacante transforma a integração em uma superfície de ataque aberta.

Referências

[1] Alerta Phalcon: exploit do SquidRouterModule
[2] Alerta Phalcon: padrão de ataque do CrossCurveFi
[3] Esclarecimento do Squid Router

Sobre a BlockSec

A BlockSec é um provedor completo 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, 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 : Enviar uma solicitação
🔗 Phalcon Security APP: Agendar uma demonstração
🔗 Phalcon Compliance