Back to Blog

Resumo Semanal de Incidentes de Segurança Web3 | 16 a 22 de Fev de 2026

Code Auditing
February 25, 2026
8 min read

Durante a semana passada (16 de fev–22 de fev de 2026), a BlockSec detectou e analisou três incidentes de ataque, com perdas totais estimadas em ~$6,22M. A tabela abaixo resume esses incidentes, e análises detalhadas de cada caso são fornecidas nas subseções a seguir.

Data Incidente Tipo Perda Estimada
2026/02/16 Incidente Moonwell Configuração Incorreta ~$1,78M
2026/02/19 Incidente PearlDriver Overflow Aritmético ~$40,3K
2026/02/21 Incidente IoTex Comprometimento de Chave ~$4,4M

1. Incidente Moonwell

Resumo

Em 16 de fevereiro de 2026, o protocolo Moonwell na Base foi explorado devido a uma configuração incorreta do oráculo, resultando em aproximadamente $1,78 milhão em dívidas incobráveis. O problema ocorreu durante a execução da proposta MIP-X43, onde o oráculo cbETH da Base foi incorretamente configurado com um feed de taxa de câmbio cbETH/ETH em vez do oráculo composto que incorpora o preço ETH/USD. Isso fez com que o oráculo reportasse o cbETH a ~$1,12 em vez de seu valor de mercado real de ~$2.200. Bots de liquidação imediatamente apreenderam 1.096,317 cbETH enquanto reembolsavam dívidas mínimas antes que os limites fossem reduzidos para interromper o exploit.

Contexto

Moonwell é um protocolo de empréstimo em múltiplas redes e executou uma proposta chamada MIP-X43 em 16 de fevereiro de 2026. Essa proposta visava ativar contratos Chainlink OEV (Oracle Extractable Value) Wrapper em todos os mercados principais e isolados restantes na Base e na Optimism, expandindo a cobertura além dos três feeds iniciais habilitados no MIP-X38. Os wrappers OEV são projetados para permitir que o protocolo capture valor durante liquidações que dependem de preços de oráculos, garantindo que os liquidadores permaneçam devidamente incentivados.

Análise da Vulnerabilidade

A vulnerabilidade derivou de um erro de configuração no construtor do ChainlinkOracleConfigs.sol. Para o cbETH na rede Base, a proposta configurou o oráculo como "cbETHETH_ORACLE" (um feed de taxa de câmbio cbETH/ETH) em vez do oráculo composto adequado que combina essa taxa com o preço ETH/USD. Quando o wrapper OEV foi implantado e conectado como feed via setFeed() no ChainlinkOracle, o protocolo passou a usar uma taxa de câmbio bruta (cbETH/ETH ≈ 1,12) como preço em USD para o cbETH. Isso criou uma enorme discrepância entre o preço reportado (~$1,12) e o valor real de mercado (~$2.200–$2.400), resultando em uma subavaliação de ~2.200x do colateral cbETH.

Análise do Ataque

  1. Às 2h01 UTC+8 em 16 de fevereiro de 2026, a execução do MIP-X43 foi concluída, ativando o oráculo cbETH mal configurado na rede Base.

  2. Bots de liquidação monitorando o protocolo detectaram imediatamente a discrepância de preço e executaram liquidações sobre [posições de colateral] cbETH.

  1. Em poucos minutos, 1.096,31 cbETH foram apreendidos pelos liquidadores, gerando ~$1,78M em dívidas incobráveis nos mercados afetados.

Conclusão

Este incidente foi causado, em última análise, por um erro de configuração na implantação do MIP-X43 do Moonwell, onde o cbETH da rede Base foi erroneamente configurado com um feed de taxa de câmbio cbETH/ETH em vez do oráculo composto correto. Essa configuração incorreta possibilitou o esvaziamento rápido de uma quantidade substancial de colateral cbETH.

Para protocolos que gerenciam múltiplos feeds de oráculos, é fundamental implementar procedimentos rigorosos de validação pré-implantação para garantir que cada ativo esteja vinculado à sua fonte de preço pretendida. Uma verificação criteriosa pode reduzir significativamente o risco de configurações incorretas de alto impacto.


2. Incidente PearlDriver

Resumo

Em 19 de fevereiro de 2026, o contrato de curva de bonding NLAMM do PearlDriver na BSC foi explorado, resultando em aproximadamente $40,3K em perdas. A causa raiz foi um overflow aritmético não verificado na função buy(), permitindo que o atacante cunhasse quantidades extremamente grandes de tokens de jogo a um custo quase nulo, para então despejá-los nos pools de liquidez do PearlDEX.

Contexto

O PearlDriver utiliza uma curva de bonding NLAMM (Non-Linear Automated Market Maker) para a cunhagem de tokens. Os usuários podem adquirir tokens de recursos do jogo por meio da função buy(), onde o custo em stablecoin é calculado como: custo = quantidade * preçoAtual.

Em condições normais, essa fórmula garante que o pagamento exigido seja diretamente proporcional à quantidade adquirida. A curva de bonding baseia-se na premissa de que compras maiores requerem pagamentos proporcionalmente maiores, mantendo a integridade dos preços e evitando a emissão desproporcional de tokens.

Análise da Vulnerabilidade

A causa raiz foi um overflow aritmético no cálculo do pagamento em stablecoin. Toda a função buy() foi envolta em um bloco unchecked, desabilitando a proteção de overflow integrada do Solidity. Como resultado, a multiplicação usada para calcular o custo da compra não revertia ao ultrapassar o limite máximo de inteiro. Em vez disso, o valor sofria overflow e retornava a um número muito menor, reduzindo drasticamente o pagamento exigido.

Consequentemente, o atacante conseguiu pagar quase zero enquanto cunhava uma enorme quantidade de tokens, que foram imediatamente despejados em pares de liquidez de DEX para drenar USDT.

Análise do Ataque

Em uma única transação, o atacante explorou a função buy() vulnerável em cinco ativos (IRON ORE, COAL, WOOD, SAND e CLAY) usando o mesmo padrão de ataque. Tomando o primeiro ativo como exemplo:

  1. O atacante especificou uma quantidade de compra extremamente grande ao invocar buy(). Devido à aritmética não verificada, o cálculo quantidade * preçoAtual sofreu overflow e retornou a um valor próximo de zero, exigindo apenas 0,0053 USDT (menos de ~$0,01) como pagamento. Apesar do custo irrisório, o contrato cunhou uma quantidade enorme de IRON ORE para o atacante, especificamente 7,03 × 10⁵⁸ tokens.

  2. O atacante imediatamente trocou uma parte do IRON ORE cunhado no par de liquidez correspondente do PearlDEX, recebendo 7.805,55 USDT (~$7.805,56).

A mesma sequência de overflow e despejo foi executada contra os outros quatro ativos, drenando liquidez de cada par ativo-USDT e gerando mais de $40K em lucro total.

Conclusão

Este incidente foi causado por aritmética não verificada na lógica de precificação da função buy() do NLAMM. Ao desabilitar as verificações de overflow, a função permitiu que valores de entrada extremos distorcessem o cálculo do pagamento, quebrando as premissas econômicas do modelo de curva de bonding.

Embora a aritmética não verificada possa ser adequada em cenários rigidamente controlados, seu uso em lógica financeira que determina diretamente os valores de pagamento pode introduzir riscos significativos. Para mitigar esses riscos, os desenvolvedores devem revisar cuidadosamente todas as operações aritméticas e exercer cautela ao considerar a desativação das verificações de overflow integradas do Solidity 0.8+, especialmente em caminhos de código que afetam precificação ou transferências.


3. Incidente IoTex

Resumo

Em 21 de fevereiro de 2026, a bridge ioTube da IoTeX sofreu uma violação de segurança após o comprometimento da chave do proprietário do Validador Ethereum. O atacante obteve a propriedade do contrato Validador e, em seguida, assumiu o controle dos contratos TokenSafe e MintPool para drenar ~$4,4M em reservas da bridge e cunhar mais de 400M de tokens CIOTX. As reservas roubadas foram trocadas e parcialmente transferidas para o Bitcoin. De acordo com o projeto, aproximadamente 355M dos tokens CIOTX cunhados foram permanentemente bloqueados ou congelados.

Contexto

A ioTube comprometida é a infraestrutura de bridge cross-chain da IoTeX que conecta a Camada 1 da IoTeX a outras redes, como o Ethereum. No Ethereum, a arquitetura da bridge é centrada no contrato Validador (ou seja, TransferValidatorWithPayload), que verifica mensagens de liquidação cross-chain e gerencia contratos de cunhagem downstream. Estes incluem o TokenSafe, que mantém os ativos de reserva da bridge, e o MintPool, que detém a autoridade de cunhagem para certos tokens como o CIOTX.

Análise da Vulnerabilidade

A causa raiz foi o comprometimento da chave privada do proprietário do contrato Validador. Como a bridge dependia de uma única EOA sem controles de múltiplas assinaturas ou timelock, a posse dessa chave concedeu controle administrativo total. Usando a função upgrade() do contrato, o atacante transferiu a propriedade dos contratos TokenSafe e MintPool para um endereço controlado pelo atacante. Isso possibilitou a retirada direta dos ativos de reserva da bridge e a cunhagem não autorizada de grandes quantidades de CIOTX.

Análise do Ataque

  1. Comprometer a chave do proprietário do contrato Validador no Ethereum, obtendo controle administrativo.

  2. Usar o contrato Validador para transferir a propriedade dos contratos TokenSafe e MintPool.

  1. Drenar ~$4,4M em ativos de reserva (USDC, USDT, WBTC, WETH, BUSD, etc.) do TokenSafe e cunhar mais de 400M de CIOTX via MintPool.

  2. Trocar os tokens de reserva roubados e transferi-los para outras redes.

Conclusão

Este incidente representa um clássico comprometimento de chave com ponto único de falha. Toda a segurança da bridge no lado Ethereum dependia de uma única EOA com autoridade administrativa total e sem proteção de múltiplas assinaturas ou salvaguardas de timelock. Uma vez que a chave privada da EOA foi comprometida, o controle sobre os componentes críticos da bridge foi efetivamente perdido.

O caso destaca o risco do controle administrativo centralizado e ressalta a importância de distribuir a autoridade de atualização e custódia por meio de mecanismos de governança mais robustos.


Sobre a BlockSec

A BlockSec é uma provedora completa de segurança blockchain e conformidade em criptomoedas. 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 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.

Best Security Auditor for Web3

Validate design, code, and business logic before launch. Aligned with the highest industry security standards.

BlockSec Audit