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

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

1. Incidente CrossCurve

Resumo

Em 2 de fevereiro de 2026, o protocolo CrossCurve foi explorado, resultando em uma perda de aproximadamente $2,8 milhões. A causa raiz foi que o contrato ReceiverAxelar expôs uma função expressExecute() sem permissão, que contornou o processo padrão de validação do Axelar Gateway. O receptor realizava apenas verificações de endereço de par com base em dados fornecidos externamente. Consequentemente, o atacante construiu uma chamada cross-chain maliciosa para acionar o mecanismo de burn e desbloqueio, levando à liberação não autorizada de 999.787.453e18 tokens EYWA para o atacante.

Contexto

CrossCurve é um protocolo de bridge cross-chain desenvolvido pela Eywa.Fi, construído sobre o framework de mensagens cross-chain Axelar.

No modelo de segurança pretendido pelo Axelar, as mensagens cross-chain são retransmitidas pelo Axelar Gateway e devem ser explicitamente validadas na cadeia de destino via validateContractCall(). Apenas mensagens que foram criptograficamente aprovadas pelo Gateway têm permissão para prosseguir para a execução.

Para reduzir a latência, o Axelar também fornece um mecanismo de execução expressa, onde um contrato receptor pode executar otimisticamente uma mensagem antes que o Gateway finalize a validação. Esse design requer controle de acesso rigoroso para garantir que apenas executores confiáveis possam invocar caminhos de execução expressa; caso contrário, mensagens cross-chain não validadas podem ser processadas prematuramente.

Análise de Vulnerabilidade

A causa raiz foi que o ReceiverAxelar expôs uma função expressExecute() sem permissão que poderia acessar diretamente o caminho privilegiado _execute() sem autorização do Axelar Gateway.

No modelo de segurança correto do Axelar, as mensagens cross-chain devem primeiro ser aprovadas pelo Gateway via execução com suporte de prova e depois validadas na cadeia de destino por meio de validateContractCall(), que vincula (commandId, sourceChain, sourceAddress, contractAddress, payloadHash) a uma única execução autorizada.

No entanto, o caminho expressExecute() ignorou completamente essa validação. Ele dependia apenas de uma verificação de par usando sourceChain e sourceAddress, ambos controlados pelo atacante, e portanto não fornecia segurança real. Isso permitiu que o atacante fornecesse uma mensagem falsificada, forçasse o branch receiveData e executasse um payload arbitrário que, em última instância, acionou unlock() no Eywa CLP Portal, resultando na liberação não autorizada de ativos cross-chain.

Análise do Ataque

• Passo 1: O atacante invocou diretamente expressExecute(), falsificando sourceChain, sourceAddress e payload. Como expressExecute() contorna a validação do Gateway e prossegue diretamente para _execute(), a única medida de segurança restante era uma verificação de lista de permissão de endereço de par: require(peers[sourceChain] == sourceAddress.toAddress()). Essa verificação era insuficiente porque tanto sourceChain quanto sourceAddress eram fornecidos externamente. Ao fornecer o endereço de par da lista de permissão correto, o atacante a contornou.

• Passo 2: O payload forjado foi então encaminhado para o branch Receiver.receiveData(). A função resume() executou a operação cross-chain PortalV2.unlock() com base no payload malicioso, resultando no desbloqueio não autorizado de fundos para o atacante.

Conclusão

Este incidente foi fundamentalmente causado por controle de acesso insuficiente em um caminho de execução acelerada dentro de um contrato receptor cross-chain. Ao expor expressExecute() como uma função sem permissão e depender exclusivamente de informações de par fornecidas externamente, a CrossCurve efetivamente permitiu que atacantes contornassem as garantias de segurança do Axelar Gateway e executassem payloads cross-chain arbitrários.

Para mitigar riscos semelhantes no futuro, protocolos cross-chain que integram mecanismos de execução expressa ou otimista devem:

• Aplicar autenticação estrita do chamador em funções de execução de caminho rápido, garantindo que apenas retransmissores ou gateways confiáveis possam invocá-las.

• Evitar depender de metadados controlados pelo atacante (como cadeia de origem ou endereço) como única base para autorização.

• Tratar a execução expressa como uma operação privilegiada e aplicar verificações de defesa em profundidade equivalentes aos caminhos de execução validados padrão.

A adesão cuidadosa a esses princípios é crítica ao projetar sistemas cross-chain, onde um único bypass de validação pode resultar em perda sistêmica de ativos em múltiplas redes.

2. Incidente GYD

Resumo

Em 3 de fevereiro de 2026, o Protocolo GYD foi explorado, resultando em aproximadamente $700K em perdas. A causa raiz foi que seu receptor CCIP confiou em dados de mensagem controlados pelo atacante como contexto de execução. O exploit foi acionado por uma mensagem CCIP enviada da Arbitrum, que foi corretamente autenticada na camada de mensagens, mas cujo payload decodificado foi posteriormente usado para realizar chamadas externas arbitrárias em _ccipReceive(). Ao definir o destinatário decodificado como o contrato do token GYD e fornecer calldata para approve(attacker, type(uint256).max), o escrow concedeu inadvertidamente permissão ilimitada sobre seu saldo de GYD. O atacante posteriormente drenou os fundos via transferFrom().

Contexto

O contrato GydL1CCipEscrow é um contrato de custódia de ativos cross-chain construído sobre o padrão Chainlink CCIP. Os usuários bloqueiam tokens GYD neste contrato na L1, que então envia uma mensagem cross-chain via CCIP para a cadeia de destino. Por outro lado, quando uma mensagem cross-chain chega ao escrow, o CCIP valida sua autenticidade e aciona _ccipReceive(). Esta função analisa os calldata recebidos para extrair tx.recipient e data, executa a lógica de transferência ou desbloqueio de GYD com base nos parâmetros analisados (valor e destinatário) e, se data não estiver vazio, realiza uma chamada externa arbitrária via recipient.functionCall(data).

Análise de Vulnerabilidade

A vulnerabilidade central é que GydL1CCipEscrow não valida o endereço tx.recipient decodificado das mensagens cross-chain. Um atacante pode definir tx.recipient como o endereço do contrato do token GYD e criar data como approve(attacker, type(uint256).max). Como o contrato de escrow mantém uma grande quantidade de tokens GYD bloqueados, essa chamada externa irrestrita faz com que o escrow conceda permissão total de seus tokens GYD ao atacante, que pode então drenar todos os fundos via transferFrom().

Análise do Ataque

• Passo 1: O atacante iniciou uma mensagem CCIP maliciosa na Arbitrum, especificando tx.recipient como o endereço do contrato do token GYD no Ethereum e tx.data como o calldata codificado para approve(attacker, type(uint256).max).

• Passo 2: Quando a mensagem foi processada no Ethereum, a função _ccipReceive() do contrato GydL1CCipEscrow executou a aprovação no contrato do token GYD sem validar tx.recipient. O atacante então chamou transferFrom() no token GYD para drenar todos os fundos em custódia.

Conclusão

A causa raiz deste incidente é que o contrato GydL1CCipEscrow falhou em validar o payload decodificado ao processar mensagens cross-chain, permitindo que um atacante construísse uma chamada cross-chain maliciosa. Para mensagens de bridge cross-chain, os desenvolvedores devem:

• Proibir chamadas diretas a contratos de token a partir do escrow: Garantir que os payloads de mensagens cross-chain não possam acionar chamadas ao contrato do token em custódia.

• Implementar uma lista de permissão de alvos de execução: Restringir tx.recipient (ou tx.target) a um conjunto bem definido de endereços confiáveis.

3. Incidente Token SOFI

Resumo

Em 5 de fevereiro de 2026, o token SOFI na BNB Chain foi explorado, resultando em aproximadamente $29,6K em perdas.

A causa raiz foi um mecanismo de burn falho implementado dentro da função _transfer() sobrescrita do token. Ao abusar da lógica de burn atrasada que removia tokens diretamente do pool de liquidez da PancakeSwap e acionava um sync() subsequente, o atacante conseguiu inflar artificialmente o preço do SOFI. Por meio de transferências e swaps repetidos, o atacante extraiu o excesso de liquidez em USDT do pool e pagou o empréstimo relâmpago com lucro.

Contexto

SOFI é um token ERC-20 personalizado implantado na BNB Chain. Ao contrário de uma implementação ERC-20 padrão, o token SOFI sobrescreve a função interna _transfer() para incorporar lógica adicional relacionada ao burn de tokens durante operações de venda.

O token é negociado em um pool AMM de produto constante no estilo PancakeSwap (SOFI–USDT). Nesses pools, o preço do token é derivado da proporção das reservas de tokens. Qualquer mudança inesperada nos saldos do pool, especialmente aquelas não causadas por swaps, pode manipular diretamente o preço.

Neste design, o próprio contrato do token interage com o pool de liquidez durante as transferências, tornando a contabilidade de reservas do pool dependente da lógica do lado do token, em vez de puramente da mecânica AMM.

Análise de Vulnerabilidade

A vulnerabilidade reside no mecanismo de burn do SOFI combinado com a interação do pool dentro de _transfer().

Quando tokens SOFI são transferidos para o endereço do pool de liquidez, o contrato interpreta a transferência como uma venda e incrementa uma variável acumuladora interna waitBurnTokenAmount. No entanto, o valor acumulado não é queimado imediatamente. Em vez disso, é queimado do saldo do pool em uma transferência subsequente para o pool, após o qual a função sync() do pool é chamada.

Este design introduz dois problemas críticos:

1. Manipulação direta do saldo do pool Queimar tokens diretamente do pool reduz a reserva de SOFI sem uma saída correspondente de USDT, violando o invariante AMM e aumentando artificialmente o preço do SOFI.

2. Execução atrasada e controlável pelo atacante Como o burn ocorre apenas em uma transferência futura, um atacante pode controlar precisamente quando o burn e o sync() acontecem, permitindo-lhe se posicionar para lucrar com a distorção de preço.

Como resultado, o preço do pool não reflete mais a dinâmica genuína de oferta e demanda, permitindo arbitragem explorável.

Análise do Ataque

• Passo 1: Tomar emprestado USDT via empréstimo relâmpago.

• Passo 2: Trocar USDT por SOFI no pool SOFI–USDT.

• Passo 3: Transferir SOFI para o pool e invocar skim() para aumentar waitBurnTokenAmount com perda mínima.

• Passo 4: Transferir SOFI para o pool novamente para acionar burn + sync(), elevando o preço do SOFI, depois trocar SOFI por USDT.

• Passo 5: Repetir o Passo 4. O waitBurnTokenAmount recém-acumulado só é queimado na próxima transferência, portanto múltiplas iterações são necessárias.

• Passo 6: Drenar USDT do pool e depois pagar o empréstimo relâmpago.

Conclusão

Este incidente foi, em última análise, causado por um mecanismo de burn no lado do token inseguro que manipulou diretamente os saldos do pool AMM. Ao incorporar lógica de burn atrasada dentro de _transfer() e executar burns a partir do próprio pool de liquidez, o token SOFI quebrou as suposições fundamentais dos AMMs de produto constante e permitiu a manipulação determinística de preços.

Para tokens ERC-20 que sobrescrevem _transfer(), os desenvolvedores devem tomar cuidado especial para evitar:

• Queimar tokens diretamente de pools de liquidez

• Introduzir mecanismos atrasados ou com estado que afetem as reservas do pool

• Acoplar a lógica do token muito estreitamente com os internos do AMM

Em geral, a lógica relacionada à tokenomia nunca deve ter permissão para alterar arbitrariamente os saldos do pool, pois mesmo pequenos desvios podem ser explorados repetidamente para drenar a liquidez.

4. Incidente de Protocolo de Staking Desconhecido (5 de fevereiro de 2026)

Resumo

Em 5 de fevereiro de 2026, o Protocolo de Staking Desconhecido no Ethereum foi explorado, resultando em aproximadamente $71,6K em perdas.

A causa raiz foi a dependência do protocolo em dados de entrada não verificados e fornecidos pelo usuário durante saques. Especificamente, o protocolo encaminhou routerCalldata controlado pelo atacante e valores de LP para o Pendle Router sem validação. Ao criar calldata que removeu toda a posição de LP do protocolo e se definindo como o receptor, o atacante conseguiu drenar todos os ativos mantidos pelo vault.

Contexto

O Protocolo de Staking Desconhecido é um vault de rendimento simples construído sobre o Pendle Finance. Os usuários depositam ativos no vault, que então roteia esses ativos pelo Pendle Router para cunhar posições de rendimento. Internamente, os depósitos são convertidos em SY, divididos em PT e YT, e combinados para formar tokens LP da Pendle.

O protocolo mantém a custódia de todos os tokens LP e mantém a contabilidade interna do valor subjacente depositado por cada usuário. Quando os usuários sacam, o vault resgata tokens LP via Pendle Router e retorna os ativos correspondentes ao usuário.

Análise de Vulnerabilidade

A causa raiz são dados de entrada não validados. A função withdrawWithCalldataMultiToken() recebe quatro parâmetros: o token subjacente, o valor subjacente, o valor de LP e routerCalldata. Ela apenas verifica se o saldo subjacente registrado do usuário é suficiente, mas não valida o valor de LP nem o conteúdo de routerCalldata. Ao remover liquidez via Pendle Router, o contrato depende inteiramente de parâmetros incorporados em routerCalldata. Como resultado, um atacante poderia passar o saldo total de LP do protocolo e se definir como o receptor, drenando todos os ativos mantidos pelo protocolo.

Análise do Ataque

• Passo 1: Tomar um empréstimo relâmpago de USDC.

• Passo 2: Depositar uma pequena quantidade de USDC no protocolo, que roteia os fundos pelo Pendle Router para adicionar liquidez e cunhar LP.

• Passo 3: Invocar withdrawWithCalldataMultiToken() com um routerCalldata criado que define o receiver como o atacante e o lpAmount como todo o saldo de LP do protocolo.

• Passo 4: O protocolo remove a liquidez via Pendle Router usando os parâmetros controlados pelo atacante e envia todos os ativos para o atacante.

• Passo 5: Trocar os ativos recebidos de volta para USDC, pagar o empréstimo relâmpago e manter o restante como lucro.

Conclusão

Este incidente foi, em última análise, causado pela confiança cega em entrada externa controlada pelo atacante dentro de um caminho crítico de saque. Ao encaminhar calldata arbitrário e valores de LP para um roteador externo sem validação, o protocolo permitiu que os usuários executassem saques muito além de sua cota, levando à drenagem completa da posição Pendle do vault.

Para vaults de produção e estratégias de rendimento, especialmente aqueles que integram roteadores externos complexos, os desenvolvedores devem:

• Tratar todas as entradas fornecidas pelo usuário, incluindo calldata, como não confiáveis e validá-las rigorosamente.

• Derivar parâmetros sensíveis (como valores de LP e receptores) internamente, em vez de aceitá-los dos usuários.

• Aplicar defesa em profundidade impondo consistência entre a contabilidade interna e os resultados de execução externa.

A falha em fazer isso pode permitir que até mesmo uma única chamada de saque comprometa todos os ativos mantidos pelo protocolo.

5. Incidente do Protocolo LZMultiCall

Resumo

Em 7 de fevereiro de 2026, o incidente LZMultiCall resultou em aproximadamente $142K em perdas no Ethereum.

O incidente não foi causado por uma vulnerabilidade no próprio contrato LZMultiCall, mas pelo uso indevido por parte dos usuários. LZMultiCall é um contrato de execução em lote sem estado que não foi projetado para custodiar ativos ou manter permissões de ERC-20. No entanto, alguns usuários aprovaram erroneamente permissões de token para o contrato. Um atacante posteriormente explorou essas aprovações pendentes invocando execute() com calldata criado para chamar transferFrom(), drenando tokens dos usuários afetados.

Contexto

LZMultiCall é um contrato utilitário genérico de execução em lote. Seu objetivo pretendido é permitir que os usuários agrupem múltiplas chamadas em uma única transação, encaminhando calldata fornecido pelo usuário para contratos alvo.

Criticamente, LZMultiCall foi projetado para ser sem estado e não custodial. Não é destinado a manter ativos, nem os usuários devem conceder a ele permissões de ERC-20. Quaisquer aprovações de token concedidas ao LZMultiCall violam suas suposições de uso explícito e expõem os usuários a riscos, já que o contrato pode encaminhar chamadas arbitrárias em nome do chamador.

Análise de Vulnerabilidade

Embora LZMultiCall tenha funcionado conforme projetado, sua função execute() sem permissão tornou-se explorável quando os usuários erroneamente concederam a ele permissões de ERC-20. Como o contrato encaminha calldata arbitrário para qualquer alvo, um atacante poderia invocar execute() com calldata codificando transferFrom(victim, attacker, amount) em contratos de token, efetivamente drenando quaisquer permissões pendentes.

Análise do Ataque

• O atacante invocou execute() com calldata criado visando o contrato do token, usando transferFrom() para transferir tokens de usuários que haviam erroneamente aprovado permissões para LZMultiCall.

Conclusão

Este incidente foi, em última análise, causado pela violação das suposições de uso explícito de um contrato de execução em lote sem estado. LZMultiCall nunca foi destinado a custodiar fundos ou manter permissões de ERC-20. Uma vez que os usuários concederam erroneamente aprovações, o modelo de execução sem permissão do contrato permitiu que qualquer chamador drenasse essas permissões por meio de chamadas encaminhadas arbitrárias.

Para usuários e integradores que interagem com contratos de execução em lote ou estilo multicall:

• Nunca conceda permissões de ERC-20 a contratos que não foram explicitamente projetados para custodiar ativos.

• Trate contratos genéricos de encaminhamento de chamadas como superfícies de execução não confiáveis.

• Prefira aprovações por transação ou designs sem permissão (por exemplo, permit) sempre que possível.

Mesmo na ausência de uma vulnerabilidade de protocolo, mal entender o modelo de confiança de um contrato pode resultar em perdas significativas e irreversíveis.

6. Incidente de Protocolo Desconhecido (8 de fevereiro de 2026)

Resumo

Em 8 de fevereiro de 2026, o Protocolo Desconhecido no Ethereum foi explorado, resultando em aproximadamente $63K em perdas.

A causa raiz foram dados de entrada controlados pelo atacante não verificados em um caminho de execução de módulo do Gnosis Safe. Um contrato utilitário (0xF5E4) registrado como SafeModule expôs um callback de empréstimo relâmpago que decodificou dados arbitrários fornecidos pelo usuário e invocou diretamente GnosisSafe.execTransactionFromModule(). Como as chamadas originadas de módulos contornam a verificação de assinatura por design, o atacante conseguiu executar transações arbitrárias autorizadas pelo Safe, pagar a dívida do Safe no Aave V3 e sacar todas as garantias para endereços controlados pelo atacante.

Contexto

A arquitetura do protocolo gira em torno de um Gnosis Safe que gerencia uma posição alavancada no Aave V3. O Gnosis Safe suporta um modelo de execução modular, onde SafeModules designados têm permissão para executar transações em nome do Safe sem exigir assinaturas dos proprietários. Esse design destina-se a suportar automação, integrações e estratégias avançadas.

Nesta configuração, o contrato 0xF5E4 foi configurado como SafeModule do Gnosis Safe. O contrato parece ser um utilitário auxiliar projetado para suportar gerenciamento de posição baseado em empréstimo relâmpago. Ele implementa um callback de empréstimo relâmpago, receiveFlashLoan(), que é invocado por provedores de liquidez externos durante a execução do empréstimo relâmpago.

Como as chamadas de módulo contornam a verificação de assinatura, a correção e a segurança da lógica do módulo são críticas: qualquer falha efetivamente concede controle irrestrito sobre o Safe.

Análise de Vulnerabilidade

O SafeModule 0xF5E4 expõe um callback de empréstimo relâmpago receiveFlashLoan() que decodifica userData fornecido externamente e o usa diretamente para chamar GnosisSafe.execTransactionFromModule(). Como 0xF5E4 está registrado como SafeModule, as chamadas originadas dele contornam a verificação de assinatura. No entanto, receiveFlashLoan() não autentica o chamador nem valida os parâmetros decodificados (por exemplo, endereço alvo, valor, calldata ou tipo de operação). Como resultado, um atacante pode fornecer userData criado para fazer o módulo executar transações arbitrárias via Safe, permitindo-lhe pagar a dívida do Safe no Aave V3, sacar todas as garantias e drenar a posição para obter lucro.

Análise do Ataque

• Passo 1: O atacante tomou um empréstimo relâmpago via Uniswap V4 e transferiu os fundos para o GnosisSafe.

• Passo 2: O atacante chamou flashLoan() do Balancer com userData criado, sem tomar emprestado nenhum ativo real, e definindo o recipient como 0xF5E4.

• Passo 3: Em 0xF5E4.receiveFlashLoan(), o contrato decodificou o userData fornecido pelo atacante. Como 0xF5E4 está registrado como módulo do Safe, ele contornou as verificações de assinatura e invocou execTransactionFromModule() para executar chamadas arbitrárias conforme ditado pelos parâmetros incorporados em userData.

• Passo 4: Usando essa capacidade, o atacante pagou a dívida do GnosisSafe no Aave V3 e sacou todas as garantias, realizando assim o lucro.

Conclusão

Este incidente foi, em última análise, causado pelo uso inseguro de execução baseada em módulo combinado com entrada externa não validada. Ao encaminhar userData arbitrário fornecido pelo atacante para execTransactionFromModule(), o SafeModule 0xF5E4 efetivamente expôs controle irrestrito sobre o Gnosis Safe. Como os módulos do Safe contornam verificações de assinatura por design, essa falha permitiu um comprometimento completo da posição Aave V3 do Safe.

Para sistemas que dependem de módulos do Gnosis Safe ou frameworks de execução privilegiados semelhantes, os desenvolvedores devem:

• Tratar todas as entradas externas, incluindo userData de empréstimos relâmpago, como não confiáveis e validá-las rigorosamente.

• Restringir a execução do módulo a um conjunto bem definido de ações, alvos e seletores.

• Evitar módulos "utilitários" genéricos que encaminham calldata arbitrário para funções de execução privilegiadas.

A falha em aplicar essas salvaguardas pode transformar um único contrato auxiliar em uma porta dos fundos administrativa completa.

Sobre a BlockSec

A BlockSec é um provedor 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 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 prestigiosas, 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