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 seguintes.

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 Breve

Em 16 de fevereiro de 2026, o protocolo Moonwell na Base foi explorado devido a uma configuração incorreta de 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 confiscaram 1.096,317 cbETH enquanto pagavam dívidas mínimas antes que os limites fossem reduzidos para interromper o exploit.

Contexto

Moonwell é um protocolo de empréstimo presente 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 Optimism, ampliando 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 decorreu 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 subvalorização de ~2.200x do colateral cbETH.

Análise do Ataque

  1. Às 2:01 AM 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 que monitoravam o protocolo detectaram imediatamente a discrepância de preço e executaram liquidações nas [posições de colateral] cbETH.

  1. Em minutos, 1.096,31 cbETH foram confiscados por 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 da Moonwell, onde o cbETH da rede Base foi erroneamente associado a um feed de taxa de câmbio cbETH/ETH em vez do oráculo composto correto. Essa configuração incorreta permitiu 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 Breve

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 sem verificação na função buy(), permitindo que o atacante cunhasse quantidades extremamente grandes de tokens do jogo a um custo próximo de zero e, em seguida, os despejasse 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 da compra é 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 se baseia no pressuposto de que compras maiores exigem 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() estava envolvida em um bloco unchecked, desabilitando a proteção nativa de overflow do Solidity. Como resultado, a multiplicação usada para calcular o custo da compra não revertia ao exceder o limite máximo de inteiros. 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 quantidade enorme 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 vulnerável buy() 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 sem verificação, 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 sem verificação 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 os pressupostos econômicos do modelo de curva de bonding.

Embora a aritmética sem verificação 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 tais riscos, os desenvolvedores devem revisar cuidadosamente todas as operações aritméticas e exercer cautela ao considerar a desabilitação das verificações nativas de overflow do Solidity 0.8+, especialmente em caminhos de código que afetam precificação ou transferências.


3. Incidente IoTex

Resumo Breve

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 Validator no Ethereum. O atacante obteve a propriedade do contrato Validator 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 Layer 1 da IoTeX a outras redes, como o Ethereum. No Ethereum, a arquitetura da bridge é centrada no contrato Validator (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 Validator. Como a bridge dependia de um único 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 permitiu a retirada direta de 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 Validator no Ethereum, obtendo controle administrativo.

  2. Usar o contrato Validator 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 fazer bridge para outras redes.

Conclusão

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

O caso evidencia o risco do controle administrativo centralizado e reforça 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 é um fornecedor completo de segurança em 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 em blockchain em conferências de prestígio, reportou vários ataques de 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