Durante a semana passada (2026/02/23 - 2026/03/01), a BlockSec detectou e analisou sete incidentes de ataque, com perdas totais estimadas em aproximadamente $13M. 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/22 | Incidente LAXO | Falha no design do token | ~$137K |
| 2026/02/22 | Incidente YieldBloxDAO | Configuração incorreta do oráculo | ~$10M |
| 2026/02/23 | Incidente STO | Falha no design do token | ~$16.1K |
| 2026/02/25 | Incidente HedgePay | Lógica de negócio falha | ~$15.7K |
| 2026/02/26 | Incidente Ploutos | Configuração incorreta do oráculo | ~$390K |
| 2026/02/26 | Incidente FOOMCASH | Lógica de negócio falha | ~$2.26M |
| 2026/02/27 | Incidente Desconhecido | Validação de entrada inadequada | ~$180K |
1. Incidente LAXO
Resumo
Em 22 de fevereiro de 2026, o token ERC20 LAXO na BNB Smart Chain foi explorado, resultando em aproximadamente $137.320 em perdas no par LAXO-USDT. A causa raiz foi um mecanismo de queima falho que era ativado quando LAXO era transferido diretamente para o par PancakeSwap. Como o roteador estava na lista de permissões e não aciona a lógica de queima em transfer(), o atacante o contornou: enviou LAXO para o par e então chamou o swap() de baixo nível do par, que queimou tokens do par e chamou sync(), inflando o preço. O atacante então trocou de volta para USDT com lucro.
Contexto
O token LAXO implementa um mecanismo de queima. Quando o destinatário de uma transferência é o endereço do par PancakeSwap USDT–LAXO, o token trata isso como uma venda: ele queima uma quantidade correspondente de tokens do par e então chama sync() para atualizar as reservas do par.
Além disso, o token LAXO implementa uma lista de permissões (_isExcludedFromFee) para isentar certos endereços (por exemplo, roteadores de swap) do mecanismo de queima e das taxas.
Análise de Vulnerabilidade
A causa raiz do incidente foi um mecanismo de queima falho no token LAXO. Especificamente, transferir LAXO diretamente para o par aciona a queima, removendo LAXO do par e inflando seu preço. Como resultado, um atacante pode explorar isso para obter lucros por meio de ataques de manipulação de preço.
Análise do Ataque
A análise do ataque é baseada na transação 0xd58f3ef6...d98ac7d3.
-
O atacante obteve um empréstimo relâmpago de 350.000e18
USDTdo PancakeSwap V3. -
O atacante trocou
USDTporLAXOvia PancakeSwap Router. Para contornar as restrições de negociação (buyEnabled = false) e a lógica de taxas, o atacante criou um par BNB–LAXO V2 e roteou as negociações por ele.
-
O atacante transferiu todo o
LAXOmantido diretamente para o par USDT–LAXO. Isso reduziu a reserva deLAXOno pool enquanto a reserva deUSDTpermaneceu praticamente inalterada, aumentando dramaticamente o preço doLAXOno par USDT–LAXO. -
O atacante trocou
burnAmountdeLAXOpor ~487.500e18USDTcom base no preço manipulado. -
O atacante reembolsou o empréstimo relâmpago e reteve o
USDTrestante como lucro.
Conclusão
A causa raiz deste incidente decorre do mecanismo de queima falho do LAXO, que permite aos atacantes drenar USDT do pool por meio de ataques de manipulação de preço. Como resultado, o incidente causou perdas totais de aproximadamente $137.3K. Para mitigar tais problemas, o projeto deve realizar testes abrangentes de seu mecanismo de queima para evitar possíveis ataques de manipulação de preço.
2. Incidente YieldBloxDAO
Resumo
Em 22 de fevereiro de 2026, um pool de empréstimos operado pelo YieldBlox DAO no Blend V2 da Stellar foi explorado, resultando em perdas superiores a $10 milhões [1]. O incidente foi causado por uma configuração incorreta do operador do pool (YieldBlox DAO) e não por uma vulnerabilidade nos contratos inteligentes.
Especificamente, o atacante manipulou o mercado USTRY/USDC no SDEX. O caminho do oráculo Reflector configurado pelo pool aceitou o preço manipulado, que supervalorizou o USTRY como garantia e permitiu ao atacante drenar os ativos do pool, incluindo USDC e XLM.
Contexto
Na blockchain Stellar, o Blend V2 é um protocolo de liquidez que permite aos usuários criar pools de empréstimos isolados. Esses pools facilitam empréstimos e tomadas de empréstimo entre usuários para um conjunto de ativos suportados. Especificamente, o pool vítima neste incidente permite que os usuários tomem emprestado XLM e USDC usando USTRY como garantia. Além disso, o criador do pool especifica o oráculo Reflector [2] como provedor de oráculo na criação. O preço do USTRY fornecido pelo oráculo Reflector é atualizado a cada cinco minutos com base no mercado USTRY/USDC na DEX da Stellar (ou seja, SDEX) [3].
Análise de Vulnerabilidade
A causa raiz foi a manipulação de preço no mercado USTRY/USDC de baixa liquidez do SDEX, que levou a uma atualização vulnerável do preço do USTRY no oráculo Reflector. Especificamente, devido à liquidez extremamente rasa no mercado USTRY/USDC, o atacante foi capaz de consumir ordens normais e colocar ordens anormais para inflar o preço do USTRY em 100 vezes. Esse preço inflado do USTRY foi então propagado para o oráculo Reflector, permitindo ao atacante tomar emprestado todos os ativos (ou seja, XLM e USDC) do pool vítima ao colateralizar USTRY supervalorizado.
Análise do Ataque
- (Tx 1, 2) O atacante manipulou o preço do USTRY no SDEX, elevando-o de $1,06 para aproximadamente $107. Como o mercado USTRY/USDC no SDEX era extremamente raso, o atacante consumiu todas as ordens normais e então colocou ordens anormais, impulsionando acentuadamente o preço de mercado para cima.
- (Tx 3) O oráculo Reflector obteve o preço manipulado do SDEX e atualizou seu feed de preços de acordo.
- (Tx 4, 5) O atacante tomou emprestado 1.000.196e7 USDC ao colateralizar 12.881e7 USTRY.
- (Tx 6, 7) O atacante tomou emprestado 6.124.927.810e7 XLM ao colateralizar 14.987.610e7 USTRY.
- (Txs 8, 9, 10) Por fim, o atacante transferiu os ativos drenados para múltiplas cadeias, incluindo Base, BSC e Ethereum.
As tabelas abaixo resumem as principais transações de exploração e os endereços relacionados envolvidos.
Conclusão
Embora o incidente do YieldBloxDAO tenha resultado em perdas significativas, o problema subjacente não é complexo: a avaliação da garantia depende de um preço vulnerável à manipulação. Este incidente serve como um lembrete de que a dependência de preços para protocolos de empréstimo deve ser cuidadosamente selecionada e monitorada.
Referências
[2] https://reflector.network/
[3] Mercado USTRY/USDC no SDEX
3. Incidente STO
Resumo
Em 23 de fevereiro de 2026, um pool STO-WBNB no PancakeSwap na BNB Smart Chain foi drenado, resultando em aproximadamente $16.1K em perdas. A causa raiz foi um mecanismo de queima falho no token STO. Especificamente, quando os usuários vendiam tokens STO no pool, o mecanismo de queima era acionado, queimando tokens STO do pool e inflando o preço do token. Como resultado, o atacante explorou essa vulnerabilidade para drenar tokens WBNB do pool.
Contexto
O token STO introduz um mecanismo de queima direcionado ao pool PancakeSwap V2. Esse mecanismo é acionado apenas quando a função de venda do token STO está habilitada (ou seja, sellEnabled == true) e pendingBurnFromSell > 0. Quando um usuário vende tokens STO, o mecanismo queima tokens STO do pool. Especificamente, 94% dos tokens STO vendidos na transação anterior são queimados durante o processo de queima.
Análise de Vulnerabilidade
A causa raiz do incidente é o mecanismo de queima falho no token STO. Especificamente, quando um usuário vende tokens STO, o mecanismo de queima remove uma certa quantidade de tokens STO do pool e também invoca a função sync() do contrato de par para atualizar as reservas. Esse mecanismo de queima infla o preço do token STO no pool. Como resultado, os atacantes podem lucrar com esse mecanismo realizando um ataque de manipulação de preço.
Análise do Ataque
A análise a seguir é baseada na transação 0x8ba17bea...5a54020c.
-
O atacante tomou emprestado
360.894e18 WBNBvia empréstimo relâmpago. -
O atacante invocou a função
initializeLiquidity()para habilitar a funcionalidade de compra e venda do tokenSTO.
-
O atacante trocou
360.894e18 WBNBpor7.848.832e18 STO. -
O atacante invocou a função
transfer(), acionando o mecanismo de queima para manipular as reservas do par (ou seja, aumentou o preço do tokenSTO), ao mesmo tempo que definiu a quantidade de tokensSTOa serem queimados na próxima transação para173.391e18.
-
O atacante invocou a função
swap()para trocarSTOporWBNB. Esta etapa permitiu ao atacante obter lucros com base no preço manipulado. -
O atacante repetiu os passos 4 e 5 para drenar o
WBNBdo pool. -
O atacante reembolsou o empréstimo relâmpago e obteve um lucro de
26e18 WBNB.
Conclusão
A causa raiz deste incidente decorre do mecanismo de queima falho do STO, que permite aos atacantes drenar WBNB do pool. Para mitigar tais problemas, o projeto deve implementar controles de acesso adequados dentro do sistema e realizar testes abrangentes de seu mecanismo de queima para evitar possíveis ataques de manipulação de preço.
4. Incidente HedgePay
Resumo
Em 25 de fevereiro de 2026, o protocolo HedgePay na BNB Smart Chain foi explorado, resultando em aproximadamente $15.7K em perdas. A causa raiz foi uma lógica de negócio falha no contrato de staking do protocolo HedgePay. Especificamente, a função forceExit() do contrato de staking vulnerável (ou seja, 0xBe189fe9f84cA531CD979630E1f14757b88dD80d) permitia que os usuários retirassem seus ativos em staking sem atualizar seus saldos de staking. Como resultado, o atacante foi capaz de invocar repetidamente a função forceExit() para drenar os tokens HPAY do contrato.
Contexto
O protocolo HedgePay é um protocolo de staking que permite aos usuários ganhar recompensas ao fazer staking de tokens HPAY. A função forceExit() permite que os usuários retirem seus ativos em staking.
Análise de Vulnerabilidade
A causa raiz do incidente é uma lógica de negócio falha na função forceExit(). Especificamente, quando os usuários fazem staking de tokens HPAY via função stake(), seu valor em staking (ou seja, _balances[msg.sender]) é atualizado de acordo. No entanto, quando os usuários retiram seus tokens HPAY em staking via função forceExit(), o contrato falha em atualizar _balances[msg.sender]. Como resultado, o atacante consegue drenar tokens HPAY no contrato de staking ao invocar repetidamente a função forceExit().
Análise do Ataque
A análise a seguir é baseada na transação 0x5f2ea6cb...46ed137f.
-
O atacante tomou emprestado
1.247.859e18 HPAYvia empréstimo relâmpago. Na função de callback do empréstimo relâmpago:a. O atacante fez staking de
1.197.944e18 HPAYvia funçãostake().b. O atacante invocou repetidamente a função
forceExit()para drenar os tokens HPAY do contrato.
- O atacante reembolsou o empréstimo relâmpago e trocou
57.389.615e18 HPAYpor26e18 WBNB(ou seja, obteve lucro de26e18 WBNB).
Conclusão
A causa raiz deste incidente foi que a função forceExit() não atualizava _balances[msg.sender] do usuário, permitindo ao atacante drenar tokens HPAY no contrato de staking. Para prevenir tais problemas, o projeto deve realizar testes adequados orientados a estado para garantir que os invariantes de estado sejam corretamente mantidos em cada função.
5. Incidente Ploutos
Resumo
Em 26 de fevereiro de 2026, um pool do protocolo Ploutos no Ethereum sofreu perdas de aproximadamente $390.000 devido a uma configuração incorreta do oráculo. Especificamente, o oráculo foi configurado incorretamente para usar um feed de preço BTC/USD da Chainlink para USDC. Como resultado, o atacante explorou essa configuração incorreta para tomar emprestado 187 ETH ao colateralizar apenas 8 USDC.
Análise de Vulnerabilidade
Ploutos é um fork do Aave v3.0.2 implantado em múltiplas redes. O incidente foi causado por uma configuração incorreta do oráculo no pool de empréstimos (0xD060...F945D2).
No bloco 24538896, o oráculo de preço para USDC foi configurado incorretamente para referenciar um feed Chainlink BTC/USD em vez de um feed USDC/USD. No bloco subsequente (24538897), o atacante detectou a configuração incorreta e executou a exploração. Como resultado, o atacante tomou emprestado aproximadamente 187,3 ETH como lucro ao colateralizar aproximadamente 8,88 USDC.
Análise do Ataque
-
O atacante monitorou as operações de configuração do oráculo do protocolo Ploutos, que incorretamente definiu a fonte do oráculo de
USDCpara o Feed de Preço BTC/USDC da Chainlink na Tx 0xcfedf6...bd193ab6. -
O atacante enviou imediatamente uma transação (0xa17dc37e...705f8474), que permite ao atacante tomar emprestado ~187,3
ETHao colateralizar apenas ~8,8USDCdevido à configuração incorreta do oráculo. -
O atacante pagou ~5,6
ETHem subornos ao construtor e obteve ~181,7ETHde lucro líquido.
Conclusão
A causa raiz do incidente foi uma configuração incorreta do oráculo, resultando em perdas de aproximadamente $390.000. Isso serve como um lembrete de que operações sensíveis como a configuração do Oráculo devem ser protegidas por carteiras multisig ou timelock para evitar possíveis perdas.
Referências
[1] https://x.com/Phalcon_xyz/status/2026943448734114011
6. Incidente FOOMCASH
Resumo
Em 26 de fevereiro de 2026, o protocolo FOOMCASH foi explorado devido a uma verificação de prova Groth16 vulnerável [1], resultando em perdas totais de mais de $2,26M.
Contexto
O protocolo FOOMCASH é um protocolo de loteria na Base e no Ethereum que usa provas Groth16 para verificações de retirada. No contrato FoomLottery, a função collect() verifica a prova fornecida (ou seja, _pA, _pB e _pC) ao invocar a função WithdrawG16Verifier.verifyProof(). Especificamente, a verificação é realizada com base na configuração confiável (ou seja, gamma e delta) no contrato WithdrawG16Verifier. Uma vez que a prova é verificada como válida, a função collect() prossegue para transferir ativos (ou seja, tokens FOOM) com base nas entradas do usuário (por exemplo, _recipient e _rewardbits).
Análise de Vulnerabilidade
A causa raiz do incidente foi uma configuração Groth16 vulnerável. Especificamente, no contrato WithdrawG16Verifier, as variáveis gamma () e delta () compartilhavam o mesmo valor (ou seja, ), permitindo ao atacante forjar provas válidas com entradas arbitrárias. Como resultado, o atacante contornou a verificação de prova Groth16 no contrato WithdrawG16Verifier e drenou todos os ativos no contrato FoomLottery com entradas maliciosas.
Análise do Ataque
A análise do ataque é baseada na transação 0xce204482...4e275e48.
O atacante criou um contrato malicioso para construir uma prova válida e entradas maliciosas. Na lógica de fallback do contrato malicioso:
-
Ele construiu uma prova válida.
-
Ele invocou a função
collect()do contratoFoomLotterycom uma prova válida e entradas maliciosas (por exemplo,_recipiente_rewardbits).
a. Na invocação da função collect(), a verificação da prova (ou seja, WithdrawG16Verifier.verifyProof()) foi contornada e os ativos (ou seja, tokens FOOM) foram transferidos para o atacante.
- Ele repetiu os passos 1-2 por 30 vezes e drenou um total de
19.695.576.757.802e18tokensFOOM.
Conclusão
A causa raiz do incidente foi uma configuração de verificação Groth16 vulnerável, resultando em perdas de aproximadamente $2,26M. Isso ressalta que configurações criptográficas complexas devem ser completamente revisadas e auditadas antes da implantação.
Referências
[1] https://x.com/Phalcon_xyz/status/2026941738141778394
7. Incidente Desconhecido
Resumo
Em 27 de fevereiro de 2026, um contrato desconhecido na BNB Smart Chain foi explorado [1], resultando em perdas de aproximadamente $180K. A causa raiz deste incidente foi uma validação de entrada inadequada. Especificamente, a função _verifySignatures() do contrato vítima falhou em realizar uma verificação de lista vazia, permitindo ao atacante contornar a verificação de assinatura sem fornecer assinaturas e signatários. Como resultado, o atacante aproveitou essa vulnerabilidade para drenar todos os tokens USDT no contrato vítima.
Análise de Vulnerabilidade
A causa raiz deste incidente é uma validação inadequada no fluxo de verificação de assinatura. Especificamente, a função _verifySignatures() apenas verifica que allSigners.length == signatures.length e não exige que nenhum dos arrays seja não vazio. Como resultado, quando ambos os arrays estão vazios, o atacante pode contornar a verificação de assinatura e retirar ativos.
Análise do Ataque
A análise a seguir é baseada nesta transação 0x91f45260...41cfd784.
- O atacante invocou a função
0x2d0cb456()de seus contratos maliciosos. Na invocação,
a. O contrato malicioso invocou a função poolWithdraw() com entradas vazias allSigners e signatures, contornando a lógica de verificação de assinatura pretendida.
b. Após contornar a lógica de verificação de assinatura, o contrato vítima transferiu USDT para o atacante.
Conclusão
A causa raiz deste incidente foi uma validação de entrada inadequada, levando a perdas de aproximadamente $180K. O incidente ressalta a importância de verificações básicas de limite, como verificações de não vazio para entradas.
Referências
[1] https://x.com/Phalcon_xyz/status/2027328894710505581
Sobre a BlockSec
A BlockSec é uma provedora completa 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 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.
-
Site oficial: https://blocksec.com/
-
Conta oficial no Twitter: https://twitter.com/BlockSecTeam
