Resumo Semanal de Incidentes de Segurança Web3 | 9 a 15 de Fev de 2026

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

1. Incidente Desconhecido

Breve Resumo

Em 10 de fevereiro de 2026, o contrato 0x560d39 na BNB Smart Chain foi explorado, resultando em uma perda estimada de ~$10K. A causa raiz foi uma lógica de negócio falha na função 0xb1a87f2c(), que tornava seu processo de adição de liquidez vulnerável a um ataque de sanduíche.

Contexto

No contrato 0x560d39, a função 0xb1a87f2c() transfere uma quantidade correspondente de USDT do usuário com base no parâmetro de entrada. O USDT recebido é processado, e 85% do total é alocado para operações de liquidez subsequentes.

Dessa parcela de 85%, metade é trocada por AFX por meio de um pool da PancakeSwap, e o AFX adquirido é transferido para o contrato 0x671ce4. A função então retira AFX do 0x671ce4.

Em seguida, por meio do PancakeSwap V2 Router, a metade restante dos 85% em USDT e o AFX retirado do 0x671ce4 são usados para adicionar liquidez ao par de negociação USDT-AFX. Qualquer USDT ou AFX remanescente é reembolsado ao usuário.

Após concluir a adição de liquidez USDT–AFX, a função recupera tokens AFX adicionais do endereço 0x146933. A quantidade de AFX retirada do 0x146933 é definida para corresponder à quantidade previamente retirada do 0x671ce4. Em seguida, a função calcula a quantidade necessária de AHT com base na proporção de preço atual no pool de liquidez AFX–AHT da PancakeSwap V2. Ela então fornece o AFX obtido do 0x146933, juntamente com a quantidade correspondente de AHT (também proveniente do 0x146933), para adicionar liquidez ao par de negociação AFX–AHT.

Análise de Vulnerabilidade

O contrato vulnerável é o 0x560d39. O contrato 0x146933 serve como fonte de financiamento do AFX usado na adição de liquidez AFX-AHT e, em última análise, absorve a perda.

A causa raiz está na lógica de negócio falha da função 0xb1a87f2c() no 0x560d39. Ao recuperar o AFX obtido pela troca de USDT via contrato 0x671ce4, a função não verifica a variação de saldo de AFX no 0x671ce4 antes e depois da troca. Em vez disso, ela retira todo o AFX mantido pelo 0x671ce4.

Isso permite que um atacante doe uma grande quantidade de AFX ao 0x671ce4 antecipadamente e, em seguida, invoque 0xb1a87f2c() com apenas uma pequena quantidade de USDT. Como a quantidade de AFX retirada do 0x146933 é definida para corresponder ao AFX retirado do 0x671ce4, inflar a retirada do 0x671ce4 força diretamente o 0x146933 a contribuir com uma quantidade inflada de AFX na adição de liquidez AFX-AHT.

O atacante pode recuperar sua doação por meio de reembolsos do USDT e AFX remanescentes do 0x560d39, enquanto o 0x146933 absorve o custo da provisão de liquidez excessiva.

O atacante então lucra aplicando um sanduíche na adição de liquidez AFX-AHT, realizando uma troca de AFX por AHT antes da transação alvo e uma troca de AHT por AFX depois dela.

Análise do Ataque

As etapas principais da transação de ataque são resumidas a seguir:

• Etapa 1: O atacante obteve 1.130.500e18 tokens AFX por meio de empréstimo relâmpago na PancakeSwap V2.

• Etapa 2: O atacante transferiu 511.965e18 AFX para o contrato 0x671ce4.

  

• Etapa 3: O atacante usou o AFX restante para trocar por 52.316e18 AHT no pool AFX-AHT da PancakeSwap V2. Como AHT é um token com taxa na transferência, o atacante recebeu apenas 26.158e18 AHT.

  

• Etapa 4: O atacante chamou o contrato 0x560d39, invocando a função 0xb1a87f2c() com o parâmetro definido como 100. Como a função retirou todo o AFX do 0x671ce4 (incluindo os tokens doados pelo atacante), ela tentou adicionar uma quantidade desproporcionalmente grande de liquidez nos pares USDT-AFX e AFX-AHT. Qualquer USDT e AFX restante que não pôde ser pareado foi reembolsado ao atacante, permitindo que ele recuperasse a maior parte de seu custo.

• Etapa 5: O atacante trocou 26.158e18 AHT por 1.129.417e18 AFX.

  

• Etapa 6: O atacante reembolsou o empréstimo relâmpago e trocou o AFX restante por USDT, obtendo ~$10K de lucro.

Conclusão

Este incidente foi causado pelo contrato 0x560d39 retirar diretamente todo o AFX do contrato 0x671ce4 ao recuperar o AFX obtido pela troca de USDT, sem verificar a variação de saldo de AFX do contrato 0x671ce4 antes e depois da troca.

2. Incidente OCA

Breve Resumo

Em 14 de fevereiro de 2026, um protocolo desconhecido na BNB Smart Chain sofreu uma exploração, resultando em uma perda de ~$422K. A causa raiz foi uma lógica de negócio falha: após a conclusão de uma troca, o protocolo chama uma função de reciclagem no contrato do Token OCA para recuperar tokens do DEX e retorná-los ao chamador e a outros endereços designados. Essa retirada unilateral do Token OCA reduz artificialmente as reservas de OCA do pool, inflando seu preço na cadeia e permitindo que um atacante drene repetidamente USDC do pool.

Contexto

O contrato do protocolo (0xe0d5ec) expõe uma função sellOCA() (seletor 0x9c1dad28) que vende uma quantidade de OCA especificada pelo usuário por USDC em um DEX. O OCA inclui um mecanismo deflacionário de "reciclagem": após a troca, o contrato recupera a mesma quantidade de OCA que acabou de ser vendida no pool e a redistribui ao chamador e a outros endereços designados. Como o OCA é removido do pool após o USDC já ter sido pago, as reservas de OCA do pool diminuem enquanto suas reservas de USDC permanecem menores, o que artificialmente eleva o preço de OCA na cadeia.

Análise de Vulnerabilidade

A vulnerabilidade central é que o estorno pós-troca em sellOCA() cria uma primitiva repetível de manipulação de preço. Cada invocação tem o seguinte efeito líquido no pool do DEX: o pool perde USDC durante a troca e também perde OCA quando o mecanismo deflacionário recupera tokens do pool, enquanto o chamador recebe os rendimentos em USDC e recupera OCA por meio da redistribuição. Como as reservas de OCA do pool são reduzidas sem qualquer entrada correspondente de USDC para equilibrar a negociação, cada ciclo infla artificialmente o preço de OCA/USDC no DEX. Um atacante pode repetir esse processo comprando OCA, chamando sellOCA() para acionar o estorno e, em seguida, vendendo o OCA recuperado ao preço inflado, drenando progressivamente a liquidez de USDC do pool.

Análise do Ataque

As etapas principais da transação de ataque são resumidas a seguir:

• Etapa 1: Obteve 8.704.860e18 USDC por meio de empréstimo relâmpago.

• Etapa 2: Trocou 8.704.860e18 USDC por 940.991e18 OCA na PancakeSwap.

  

• Etapa 3: Chamou sellOCA() com todo o 940.991e18 de OCA. A função trocou o OCA por USDC no DEX; em seguida, o mecanismo deflacionário de reciclagem recuperou o OCA vendido do pool e o redistribuiu — devolvendo OCA ao chamador. Como resultado, o atacante recebeu os rendimentos em USDC da troca e também recuperou seus tokens OCA. As reservas de OCA do pool caíram drasticamente, inflando o preço de OCA.

  

• Etapa 4: Trocou o 940.991e18 OCA recuperado de volta para USDC na PancakeSwap ao preço agora inflado, e repetiu as etapas 2–4 para drenar progressivamente o pool.

• Etapa 5: Na iteração final, o atacante trocou apenas 9.999e18 OCA por 433.238e18 USDC (refletindo o preço de OCA massivamente inflado) e, em seguida, reembolsou o empréstimo relâmpago para concluir a exploração.

  

Conclusão

A causa fundamental desta exploração foi uma falha de lógica no fluxo sellOCA do protocolo: após trocar o OCA fornecido pelo usuário por USDC, o contrato recuperava essencialmente todo o OCA inserido do DEX por meio do mecanismo de ``recuperação'' deflacionário do OCA e o redistribuía ao chamador e a outros endereços designados. Esse estorno pós-troca reduzia artificialmente o saldo de OCA remanescente no pool de liquidez, fazendo o preço de OCA na cadeia disparar acentuadamente. Ao repetir o ciclo "comprar OCA → invocar sellOCA para acionar o estorno → vender OCA de volta ao preço inflado", o atacante conseguiu extrair quase toda a liquidez de USDC com relativamente pouco OCA.

3. Incidente SOF

Breve Resumo

Em 14 de fevereiro de 2026, o token SOF na BNB Smart Chain foi explorado em ~$225K devido a um mecanismo de lista branca incorreto em sua lógica _update() e ao sistema de isenção de taxas. A vulnerabilidade permitiu que um atacante contornasse as restrições de compra usando um endereço isento de taxas, acionando subsequentemente um mecanismo de queima na venda que manipulou as reservas do pool Uniswap V2 (PancakeSwap). Ao forçar o pool a transferir seus próprios tokens para um endereço de queima e imediatamente chamar sync(), o atacante inflou artificialmente o preço do token. Isso permitiu a drenagem de USDT do pool ao trocar uma pequena quantidade de SOF à taxa manipulada. A exploração foi ainda facilitada por uma proteção inadequada contra empréstimos relâmpago que não rastreava o tx.origin, permitindo que as fases de compra e venda do ataque ocorressem na mesma transação usando múltiplos endereços.

Contexto

SOF é um token BEP-20 implantado na BNB Smart Chain, projetado com mecânicas deflacionárias personalizadas e gestão automatizada de taxas. O token interage com um par de liquidez compatível com Uniswap V2 (especificamente PancakeSwap com USDT) para facilitar as negociações.

Para usuários isentos de taxas, as operações de compra e venda são gratuitas. Para todos os outros usuários, as operações de compra são restritas e serão revertidas.

Durante as operações de venda, o contrato transfere 90% do valor vendido do par para um _destroyAddress diretamente e chama sync() para atualizar as reservas imediatamente, refletindo o saldo reduzido.

Análise de Vulnerabilidade

A causa raiz decorre do mecanismo de lista branca falho na função _update() do contrato 0x1f3863 na linha 438. Se o endereço to estiver na lista branca, qualquer from pode processar uma operação de compra.

 /// SOF.sol:433-480
433|      function _update(
434|          address from,
435|          address to,
436|          uint256 amount
437|      ) internal override {
438|          if (isExcludedFromFees[to] || isExcludedFromFees[from]) {
439|              super._update(from, to, amount);
440|              return;
441|          }
442|  
443|          require(!_blackList[from] && !_blackList[to], "refuse address");
444|  
445|          if (!inSwap && _isPairs[to]) {
446|              if (feeAmount1 >= swapTokensAtAmount) {
447|                  swapTokenForUsdt(feeAmount1, feeAddress);
448|                  feeAmount1 = 0;
449|              }
450|              if (feeAmount2 >= swapTokensAtAmount) {
451|                  swapTokenForUsdt(feeAmount2, feeAddress2);
452|                  feeAmount2 = 0;
453|              }
454|          }
455|  
456|          bool isSell;
457|          uint256 taxAmount;
458|  
459|          if (_isPairs[from]) {
460|              //buy
461|              revert("not alw buy");
462|          } else if (_isPairs[to]) {
463|              //sell
464|  
465|              isSell = true;
466|              taxAmount = takeFee(from, amount);
467|              super._update(_uniswapV2Pair, _destroyAddress, amount - taxAmount);
468|              IUniswapV2Pair(_uniswapV2Pair).sync();
469|          }
470|  
471|          emit TranserFeeLog(amount, taxAmount);
472|  
473|          if (isSell) {
474|              _antiFlashloanGuard(from, to, false, isSell);
475|          }
476|  
477|          amount = amount - taxAmount;
478|  
479|          super._update(from, to, amount);
480|      }

Análise do Ataque

As etapas principais da transação de ataque são resumidas a seguir:

• Etapa 1: O atacante obteve 315.520.309e18 USDT por empréstimo relâmpago para a etapa 2, e transferiu 875e18 SOF para o endereço 0xc4DB5B para a etapa 3.

• Etapa 2: Trocou 313.567.718e18 USDT por 991.223e18 SOF via swapTokensForExactTokens(). O endereço to era um endereço isento de taxas, o que satisfaz a verificação isExcludedFromFees[to] no contrato SOF, ignorando assim a verificação _isPairs[from] (caso contrário, a operação de compra seria revertida). Isso permite que o atacante queime quase todo o token SOF do pool na Etapa 3. Isso também contorna a verificação _antiFlashloanGuard() — o contrato não registra essa operação de compra, permitindo que a etapa 3 prossiga sem ser bloqueada. Criticamente, essa compra massiva foi orquestrada para deixar o par com apenas 787e18 SOF (ao lado de 313.816.344e18 USDT).

• Etapa 3: A partir do endereço 0xc4DB5B, trocou 875e18 SOF por USDT via swapExactTokensForTokensSupportingFeeOnTransferTokens(). O PancakeSwap Router V2 executa SOF.transferFrom() primeiro e, em seguida, processa a troca. Durante SOF.transferFrom(), a lógica de venda em _update() transfere 90% de 875e18 (ou seja, 787e18) do par para _destroyAddress — o que, conforme orquestrado na etapa 2, era quase todo o saldo de SOF do par. Após essa queima e sync(), o par possuía 313.816.344e18 USDT e apenas 10e9 SOF. Com o preço do SOF agora astronomicamente inflado, a troca subsequente gerou um pagamento massivo em USDT.

• Etapa 4: O atacante reembolsou o empréstimo relâmpago e reteve o lucro de ~$225K.

Conclusão

A vulnerabilidade demonstra que, para tokens que suportam um mecanismo de queima antes da venda, controlar quem pode comprar o token é crítico. Qualquer pessoa capaz de vender o token pode lucrar; se um atacante puder comprar tokens do pool, ele poderá inflar artificialmente o preço e depois trocar de volta para drenar todo o pool.

A investigação observou que a função _antiFlashloanGuard() está implementada incorretamente. Ela apenas restringe o mesmo msg.sender de comprar e vender, em vez de rastrear o tx.origin. Isso permite que um atacante contorne a proteção selecionando um endereço isento de taxas como endereço to (receptor) durante a operação de compra.

Para prevenir explorações semelhantes, os desenvolvedores devem garantir que apenas funções autorizadas possam comprar do pool. Além disso, a implementação de _antiFlashloanGuard() deve registrar tanto o tx.origin quanto o endereço do usuário para impedir que atacantes usem múltiplos endereços para executar operações de compra e venda na mesma transação.

Sobre a BlockSec

A BlockSec é um provedor completo de segurança em blockchain e conformidade cripto. Desenvolvemos produtos e serviços que ajudam 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 atender às 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, 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