Perda de US$ 7,8 milhões em carteira Safe reacende debate sobre módulos de terceiros

Uma carteira Safe multisig sediada na rede Ethereum perdeu cerca de 7,8 milhões de dólares em rsETH na manhã desta terça-feira, em um ataque que expôs, mais uma vez, o risco de conceder permissões amplas a módulos externos conectados a esse tipo de carteira. A falha esteve em um componente adicional que o próprio dono da carteira havia autorizado a movimentar seus fundos, não nos contratos centrais do Safe nem no token envolvido.

O episódio começou por volta das 1h38 da madrugada no horário de Brasília e se estendeu por cerca de uma hora, com movimentações adicionais que somaram outros 160 mil dólares.

A carteira afetada pertencia a um grande detentor de rsETH alavancado, token de restaking líquido emitido pela Kelp DAO. Para operar sua estratégia, o titular havia conectado um módulo personalizado ligado a uma pool de liquidez da Uniswap versão quatro, pensado para automatizar parte das operações sem exigir assinatura manual a cada movimento.

Esse tipo de módulo é comum entre usuários que automatizam estratégias de rendimento, mas depende inteiramente da segurança do código de terceiros.

Segundo a análise das empresas de segurança Blockaid, BlockSec e SlowMist, o atacante usou uma função pública de execução múltipla, disponível para qualquer participante da rede, para direcionar esse módulo até uma pool criada minutos antes especialmente para o golpe. Dentro dela, o mecanismo do módulo desembrulhou o aEthrsETH, versão do token envolvida em operações da Aave, convertendo o saldo de volta para rsETH puro e deixando a carteira exposta à extração.

A pool usada para a manobra foi montada com base em um token sem valor algum, criado exclusivamente para viabilizar o ataque.

A explicação técnica converge para um mesmo ponto central. O contrato que servia de executor de estratégia continha uma checagem de autorização permissiva o bastante para aceitar qualquer chamada que apontasse para si mesmo como destino, o que deixava a porta aberta para qualquer terceiro.

A ironia da mempool pública

A transação usada para consumar o roubo não foi enviada por um canal privado, prática comum entre atacantes que querem evitar ser vistos antes da confirmação. Ela seguiu direto para a fila pública de transações pendentes da Ethereum, visível a qualquer participante da rede em tempo real.

Foi justamente essa exposição que permitiu a um robô de extração de valor chamado yoink identificar a operação antes que ela fosse processada.

O robô pagou cerca de 47 mil dólares em taxas para furar a fila e ser processado primeiro, o que lhe garantiu a captura de praticamente todo o valor em rsETH que o atacante original tentava roubar. O criminoso original não ficou com os fundos. Quem terminou com eles foi um programa automatizado dedicado a explorar justamente esse tipo de disputa por ordem de processamento.

Parte dos tokens capturados, cerca de 2.882 unidades, foi enviada a um endereço controlado pelo próprio robô.

Kelp DAO isola o endereço, mas recuperação é incerta

A Kelp DAO, responsável pelo rsETH, afirmou que seus contratos centrais permanecem seguros e que o token continua integralmente lastreado, reforçando que a falha não teve origem em sua própria infraestrutura. A equipe colocou o endereço que recebeu os fundos sob um bloqueio preventivo de 24 horas, impedindo qualquer movimentação de entrada ou saída durante esse período.

O bloqueio, no entanto, não devolve automaticamente o valor a quem perdeu os tokens, apenas ganha tempo para investigação.

Um padrão que já apareceu antes em 2026

Esse não é o primeiro caso do ano em que um módulo conectado a carteiras Safe se torna a porta de entrada para um ataque de grande escala. Em maio, cerca de 3,2 milhões de dólares saíram de 86 carteiras diferentes nas redes Base e Ethereum, em menos de duas horas, por causa de uma falha em outro módulo externo amplamente adotado por usuários da plataforma.

Em junho, um problema semelhante atingiu o Gnosis Pay, dessa vez em um módulo responsável por atrasar transações como camada extra de segurança.

Os três episódios têm uma característica comum. Em nenhum deles a arquitetura central da carteira Safe foi comprometida diretamente. O ponto de falha esteve sempre em extensões de terceiros que os próprios usuários escolheram instalar, geralmente para ganhar automação ou conveniência, e que passaram a deter autoridade suficiente para movimentar fundos sem nova assinatura.

O episódio desta terça-feira reforça que a robustez de uma carteira multisig depende cada vez menos apenas do próprio contrato principal e cada vez mais da qualidade de cada módulo externo autorizado a operar em seu nome. Quem automatiza estratégias de rendimento precisa revisar com frequência quais permissões seguem ativas dentro da própria carteira, muito tempo depois de instaladas.