Resumo Semanal de Incidentes de Segurança Web3 | 23 a 29 de Mar de 2026

Durante a semana passada (2026/03/23 - 2026/03/29), a BlockSec detectou e analisou oito incidentes de ataque, com perdas totais estimadas em aproximadamente $1,53M. A tabela abaixo resume esses incidentes, e análises detalhadas de cada caso são fornecidas nas subseções a seguir.

1. Incidente Desconhecido 1

Resumo Breve

Em 23 de março de 2026, um contrato não verificado na Ethereum foi explorado por aproximadamente $97K devido a um transbordamento de inteiro em sua lógica de distribuição. A função 0x317de4f6() somava quantidades de tokens controladas pelo usuário sem proteção contra transbordamento, permitindo que o atacante provocasse um wraparound e retirasse o saldo total de USDT do contrato por meio da função claim(), pagando apenas 1 wei de USDT.

Análise da Vulnerabilidade

A causa raiz foi um transbordamento de inteiro na função 0x317de4f6() do contrato 0xF0a105...568C97. A função aceita um array de registros (cada um com uma conta e um valor) e soma todos os valores em totalAmount iterando o array. Como o acúmulo não possuía verificações de transbordamento, um atacante poderia fornecer registros manipulados cujos valores causam wraparound no uint256, tornando totalAmount arbitrariamente pequeno enquanto as alocações individuais permanecem grandes.

Análise do Ataque

A análise a seguir é baseada na transação 0x73bd1384...630b053.

• Passo 1: O atacante obteve 1 wei de USDT da Uniswap V4 como capital inicial para o ataque.

  

• Passo 2: O atacante consultou o saldo de USDT do contrato vítima e então invocou 0x317de4f6() com um array manipulado. Um valor foi definido próximo ao limite superior do uint256, e o outro foi definido como o saldo de USDT do contrato vítima. A soma deles sofreu transbordamento para 1, permitindo que o atacante pagasse apenas 1 wei de USDT enquanto registrava uma alocação igual ao saldo total de USDT da vítima.

  

• Passo 3: O atacante invocou claim() para retirar 97.812e6 USDT do contrato vítima.

  

• Passo 4: O atacante reembolsou o 1 wei de USDT emprestado da Uniswap V4 e trocou o USDT restante por WETH, concluindo o exploit.

Conclusão

Este incidente destaca os riscos do uso de aritmética sem verificação em versões do Solidity anteriores à 0.8.0. Todos os cálculos financeiros críticos devem utilizar explicitamente aritmética segura contra transbordamento (por exemplo, SafeMath ou Solidity >=0.8.x) para evitar problemas de wraparound.

2. Incidente Desconhecido 2

Resumo Breve

Em 23 de março de 2026, um contrato não verificado na Ethereum foi explorado por aproximadamente $11K devido a uma vulnerabilidade de reentrância. A função 0xbe16634e() atualizava a contabilidade relacionada à liquidez antes da liquidação e invocava um callback externo sem qualquer proteção contra reentrância. Ao reentrar na função repetidamente antes que a chamada anterior fosse liquidada, o atacante inflou sua liquidez registrada e posteriormente retirou mais USDC e WETH do que havia realmente depositado.

Análise da Vulnerabilidade

A causa raiz é um problema de reentrância na função 0xbe16634e() do contrato 0x39Ed37...9C6b08. Esta função atualiza o estado relacionado à liquidez, incluindo a liquidez do usuário e as reservas de tick, antes da liquidação e invoca um callback externo via msg.sender.call() sem qualquer proteção contra reentrância. Como a verificação de saldo é realizada por chamada, o atacante pode reentrar recursivamente na função e inflar a contabilidade interna de liquidez, enquanto uma única transferência de token na chamada mais profunda é suficiente para satisfazer o fluxo de execução aninhado.

Análise do Ataque

A análise a seguir é baseada na transação 0x1382e898...fad993.

• Passo 1: O atacante obteve 100e8 USDC e 10e18 WETH da Uniswap V4 como capital inicial para o ataque.

  

• Passo 2: O atacante invocou 0xbe16634e() para adicionar liquidez. Durante a execução, o contrato vítima chamou a função 0x7c65be42() do atacante, que reentrou em 0xbe16634e() antes que a chamada anterior fosse liquidada.

  

• Passo 3: Repetindo esse fluxo reentrante várias vezes, o atacante aumentou continuamente sua liquidez registrada. Na chamada mais profunda, o atacante transferiu os tokens necessários uma vez, o que foi suficiente para satisfazer as verificações de saldo aninhadas.

  

• Passo 4: Após inflar a liquidez registrada, o atacante verificou o estado do pool e transferiu fundos adicionais para o pool, de modo que ele contivesse USDC e WETH suficientes para cobrir a retirada futura.

  

• Passo 5: O atacante invocou 0xbe16634e() novamente para remover liquidez e retirou USDC e WETH do pool com base na contabilidade inflada.

  

• Passo 6: O atacante reembolsou a Uniswap V4, trocou o USDC restante por WETH e concluiu o exploit.

  

Conclusão

Este incidente demonstra o perigo de atualizar a contabilidade de liquidez antes da liquidação enquanto se invoca um callback externo desprotegido. Para evitar exploits semelhantes, os protocolos devem seguir rigorosamente o padrão checks-effects-interactions e proteger callbacks externos com proteções contra reentrância.

3. Incidente Cyrus Finance

Resumo Breve

Em 23 de março de 2026, a Cyrus Finance, um protocolo de yield farming na BNB Chain, foi explorada por aproximadamente $512K devido a uma fórmula de remoção de liquidez falha que depende do preço spot atual do pool. O protocolo utiliza posições NFT CYRP para representar uma parcela proporcional de sua liquidez no PancakeSwap V3, mas a conversão da participação do usuário para a liquidez subjacente lê slot0(), que é manipulável dentro da mesma transação. Ao deslocar o preço por meio de uma swap financiada por flash loan, o atacante inflou o valor de liquidez de sua posição NFT e retirou mais do que lhe era de direito.

Contexto

A Cyrus Finance é um protocolo de yield farming na BNB Chain que gerencia posições de liquidez em pools do PancakeSwap V3. Os usuários depositam USDT para receber posições NFT CYRP, que representam sua participação na liquidez do protocolo distribuída em múltiplas posições do PancakeSwap V3. Os usuários podem retirar seu principal mais recompensas por meio da função exit().

Análise da Vulnerabilidade

A vulnerabilidade está na função withdrawUSDTFromAny() no CyrusTreasury (0xb042Ea...0aE10b). Ao processar uma retirada, a função busca sqrtPriceX96 do slot0() do pool do PancakeSwap V3 (ou seja, o preço spot atual) e o passa para getAmountsForLiquidity() para estimar quanto amount0 / amount1 a liquidez total da posição do protocolo representa atualmente.

Em seguida, deriva availableUSDT dessa avaliação baseada no preço spot e usa a seguinte fórmula para determinar quanta liquidez deve ser removida para a retirada solicitada:

$liquidityToUse=liquidity\cdot remaining\mathrm{/}availableUSDTliquidityToUse\; =\; liquidity\; \backslash cdot\; remaining\; /\; availableUSDT$

Em outras palavras, o contrato não resgata diretamente uma participação de propriedade fixa. Em vez disso, primeiro estima o valor equivalente em USDT da posição usando o preço ao vivo do pool e, então, converte o valor de USDT solicitado de volta em uma quantidade proporcional de liquidez.

Isso é inseguro porque slot0() é manipulável dentro da mesma transação. Ao mover temporariamente o preço do pool, um atacante pode distorcer availableUSDT, o que afeta diretamente o liquidityToUse calculado.

Análise do Ataque

A análise a seguir é baseada na transação 0x85ac5d15...46d452.

• Passo 1: O atacante iniciou um flash loan de um pool do PancakeSwap V3, emprestando aproximadamente 1.798 ETH.

• Passo 2: O atacante executou uma grande troca de ETH por USDT no pool alvo onde o protocolo mantinha liquidez, deslocando deliberadamente o preço do pool e o tick atual. Em paralelo, o atacante transferiu a posição NFT CYRP #15505 de 0x01737d...6ffa3 para o contrato de ataque via safeTransferFrom().

• Passo 3: O atacante invocou exit(15505) no CyrusTreasury. Durante a execução, withdrawUSDTFromAny() leu slot0() do pool do PancakeSwap V3 e calculou availableUSDT com base no preço spot manipulado. Devido ao tick distorcido, o protocolo superestimou o valor de liquidez correspondente à participação do NFT. Em seguida, chamou decreaseLiquidity() e collect(), liberando USDT em excesso além do valor justo da posição Cyrus.

  

• Passo 4: O atacante restaurou o estado do pool, reembolsou o flash loan e transferiu o lucro restante (~$512K) para o EOA 0xf96EB1...3b63b.

Conclusão

A mitigação deve substituir o preço spot de slot0() por preços resistentes à manipulação (TWAP em uma janela de observação suficiente, ou um oráculo externo como o Chainlink) antes de converter liquidez em USDT resgatável.

4. Incidente Token BCE

Resumo Breve

Em 23 de março de 2026, o pool BCE-USDT da PancakeSwap na BNB Chain foi explorado por aproximadamente $679K devido a um mecanismo de queima falho no token BCE. O atacante implantou dois contratos maliciosos para contornar os limites de compra/venda do BCE e acionou queimas de tokens contra as reservas do pool de liquidez, manipulando o preço do pool e drenando seu USDT.

Análise da Vulnerabilidade

A vulnerabilidade origina-se do mecanismo de queima falho do token BCE (0xcdb189...999999). O problema central é que uma variável de estado influenciada pelo usuário scheduledDestruction é usada para queimar tokens diretamente do endereço do par PancakeSwap, em vez do saldo do próprio usuário. Durante as operações de venda, o contrato acumula um valor de destruição em scheduledDestruction com base no volume negociado e nas reservas atuais do pool. Esse valor não é deduzido do vendedor. Em vez disso, é posteriormente executado por um caminho de código separado que queima tokens do par e chama sync().

Como o atacante controla o volume de negociação e pode manipular as reservas do pool, ele pode definir scheduledDestruction para um valor arbitrário e acionar uma queima que comprime a reserva de BCE do par, distorcendo o preço do pool a seu favor.

Análise do Ataque

A análise a seguir é baseada na transação 0x85ac5d15...46d452.

• Passo 1: O atacante invocou um contrato malicioso (MC1) para tomar emprestado 123,5M de USDT via múltiplos flash loans e um pool de empréstimo.

• Passo 2: O atacante implantou um segundo contrato malicioso (MC2) e transferiu todo o USDT emprestado para o MC2.

• Passo 3: O atacante (via MC2) trocou 2,222M de USDT por 5,529M de BCE no pool BCE-USDT.

• Passo 4: O atacante transferiu 5,529M de BCE do MC2 para o MC1 (via MC1.drain()); devido ao mecanismo de queima, o MC1 recebeu 2,764M de BCE.

• Passo 5: O atacante (via MC1) trocou 2,488M de BCE por 1,368M de USDT, atualizando a variável scheduledDestruction para ~174K com base nas reservas do pool e no valor da troca. A variável foi posteriormente utilizada como o valor de queima.

• Passo 6: O atacante (via MC2) trocou 34,9M de USDT por 3,484M de BCE, manipulando ainda mais a reserva de BCE para ~174K.

• Passo 7: O atacante transferiu 3,484M de BCE e o USDT restante do MC2 para o MC1. Como scheduledDestruction era maior que 0 (ou seja, ~174K), a transferência de BCE acionou queimas que comprimiram a reserva de BCE para ~10.000.

• Passo 8: O atacante trocou o BCE restante por USDT ao preço manipulado.

• Passo 9: O atacante reembolsou todos os empréstimos e obteve aproximadamente $679K de lucro.

Conclusão

Este incidente foi causado por uma falha fundamental na lógica econômica do token, onde uma variável de estado influenciada pelo usuário foi usada para modificar o saldo do pool de liquidez em vez do saldo do próprio usuário. O contrato assumiu implicitamente que a destruição derivada da atividade de negociação refletiria o custo do usuário, mas na prática permitiu que atacantes construíssem uma queima diferida liquidada contra as reservas de LP. Como resultado, atacantes podiam manipular a profundidade e os preços do pool com exposição limitada de capital, extraindo valor dos provedores de liquidez.

5. Incidente Desconhecido 3

Resumo Breve

Em 25 de março de 2026, um contrato de staking não verificado na BNB Chain foi explorado por aproximadamente $1,2K devido a uma contabilidade inconsistente em múltiplos modos de staking. O contrato compartilhava a mesma variável de posição entre stake2()/withdraw2() e stake3()/withdraw3(), mesmo que essas funções lidassem com diferentes cestas de tokens e proporções. O atacante depositou pelo modo mais leve stake2() e resgatou pelo modo mais pesado withdraw3(), extraindo repetidamente tokens em excesso.

Contexto

Este é um contrato de staking com vários modos de stake e retirada. O caminho padrão stake() e withdraw() é o modo completo de staking, que lida com uma cesta de Pangolin, Bzzt e Bzzone junto com a lógica de contabilidade de recompensas. O caminho stake3() e withdraw3() usa a mesma cesta de três tokens e a mesma proporção de depósito/retirada, mas ignora o fluxo adicional de contabilidade de recompensas. Em contraste, o caminho stake2() e withdraw2() é um modo mais leve que lida apenas com Pangolin e Bzzt, e portanto usa uma combinação de tokens e proporção diferentes dos outros dois modos.

Análise da Vulnerabilidade

A causa raiz foi uma contabilidade inconsistente no contrato 0x29d36c...774137. Embora stake2()/withdraw2() e stake3()/withdraw3() lidassem com diferentes cestas de tokens, todos atualizavam as mesmas variáveis _exit[msg.sender] e _totalSupply. Como resultado, uma posição criada pelo modo mais leve stake2() poderia ser resgatada pelo modo mais pesado withdraw3().

Na prática, stake2(amount) retirava apenas amount de Pangolin e amount de Bzzt, mas withdraw3(amount) transferia de volta amount de Pangolin, 10 * amount de Bzzt e 10 * amount de Bzzone. Isso significava que fazer staking de 20e18 Pangolin e 20e18 Bzzt por meio de stake2() criava um saldo _exit que poderia ser usado posteriormente para retirar 20e18 Pangolin, 200e18 Bzzt e 200e18 Bzzone por meio de withdraw3(). Repetindo essa incompatibilidade, o atacante extraiu continuamente tokens em excesso do contrato.

Análise do Ataque

A análise a seguir é baseada na transação 0x7fcd5882...323f8d.

• Passo 1: O atacante implantou um contrato em 0x9bce07d8bbe4f19dfe465710ff9612878bfe3302, financiou-o com 0,05 BNB, converteu os fundos em WBNB, trocou por exatamente 20e18 Pangolin, 20e18 Bzzt e 200e18 Bzzone, e aprovou o contrato de staking para gastar os tokens adquiridos.

  

• Passo 2: O atacante chamou stake2() com o valor 20e18, o que transferiu 20e18 Pangolin e 20e18 Bzzt para o contrato de staking e aumentou o saldo compartilhado _exit do atacante em 20e18.

  

• Passo 3: O atacante então chamou withdraw3() com o valor 20e18. Como withdraw3() verificava apenas o saldo compartilhado _exit, o contrato transferiu de volta 20e18 Pangolin, 200e18 Bzzt e 200e18 Bzzone, mesmo que a posição tivesse sido criada por meio de stake2().

  

• Passo 4: O atacante repetiu o ciclo stake2() -> withdraw3() muitas vezes dentro da mesma transação. Em cada rodada, o Pangolin retornado e uma pequena parte do Bzzt retornado foram reutilizados para a próxima chamada stake2(), enquanto o Bzzone era enviado de volta ao contrato de staking para que chamadas posteriores de withdraw3() continuassem a ter sucesso. Por meio desse loop, o atacante aumentou seu saldo de Bzzt de 20e18 para 16.400e18.

• Passo 5: O atacante trocou os tokens adquiridos de volta em WBNB, converteu os fundos para BNB e transferiu aproximadamente 2,007e18 BNB de volta para o EOA do atacante, concluindo o exploit.

  

Conclusão

Para evitar exploits semelhantes, os contratos de staking devem isolar a contabilidade para cada modo e garantir que cada caminho de retirada corresponda exatamente à composição e proporção de ativos do caminho de depósito correspondente.

6. Incidente MYX

Resumo Breve

Em 25 de março de 2026, o contrato sMYX da MYX Network na Ethereum foi explorado, resultando na drenagem de aproximadamente 6,67 milhões de tokens MYX do pool (~$3,6K de lucro). A causa raiz foi uma interação falha entre a função de transferência do contabilidade de fornecimento e a lógica de distribuição de dividendos no contrato sMYX. Ao transferir repetidamente sMYX entre contas controladas, o atacante inflou a variável de lucro por participação, fabricou dividendos sem respaldo e extraiu mais MYX do que havia depositado originalmente.

Contexto

O contrato sMYX (0x404328...d27F66) segue um modelo de token de distribuição de dividendos. Os usuários depositam tokens MYX por meio de uma função de compra e recebem participações sMYX representando sua stake. Os dividendos são rastreados usando um acumulador global (lucro por participação) armazenado em stor_11. Os dividendos reclamáveis de cada usuário são calculados como a diferença entre sua parcela proporcional do lucro acumulado e sua linha de base de pagamento registrada. Este modelo é conceitualmente semelhante a tokens de estilo reflexivo anteriores, onde o valor recebido é redistribuído entre os detentores existentes.

Análise da Vulnerabilidade

A vulnerabilidade surge de uma interação falha entre a contabilidade de fornecimento e a lógica de distribuição de dividendos. A função de transferência introduz incorretamente novos dividendos ao aumentar a variável global de lucro por participação com base no valor transferido dividido pelo fornecimento total atual. Esta operação não é respaldada por nenhum afluxo real de tokens MYX, o que significa que os dividendos são efetivamente criados a partir de contabilidade interna em vez de atividade econômica real. Ao mesmo tempo, a função reduz o fornecimento total registrado pelo valor transferido devido à semântica invertida do auxiliar de subtração, mesmo que nenhum token seja realmente queimado.

Como consequência, cada transferência subsequente resulta em um incremento maior para o valor de lucro por participação, já que o mesmo valor de transferência é dividido por um fornecimento total cada vez menor.

Análise do Ataque

A análise a seguir é baseada na transação 0x843c9ea7...a55b90.

• Passo 1: O atacante obteve capital inicial via flash swap e o converteu em MYX, depois depositou no contrato sMYX para adquirir uma posição dominante dentro do sistema de dividendos, garantindo controle sobre a maior parte da distribuição futura de recompensas.

• Passo 2: O atacante dividiu sua posição entre dois contratos controlados e iniciou um loop coordenado que alternava entre a realização de dividendos e a manipulação de estado, permitindo a travessia repetida do caminho de contabilidade vulnerável.

• Passo 3: Por meio de transferências repetidas entre contas controladas, o atacante inflou artificialmente a variável de lucro por participação do protocolo enquanto reduzia simultaneamente o fornecimento total registrado, criando dividendos sem respaldo e amplificando sua taxa de distribuição.

• Passo 4: Ao retirar continuamente após cada ciclo de manipulação, o atacante extraiu a maioria dessas recompensas fabricadas, drenando efetivamente as reservas de MYX do protocolo sem introduzir novo capital.

• Passo 5: O atacante encerrou todas as posições, trocou o MYX extraído de volta para WETH, reembolsou o flash loan e reteve o saldo restante como lucro.

Conclusão

Este incidente não é meramente uma consequência de um design econômico semelhante a Ponzi, mas sim uma falha crítica na implementação da contabilidade de dividendos. Para mitigar tais vulnerabilidades, as operações de transferência não devem afetar o fornecimento total nem acionar a distribuição de dividendos, e as atualizações de lucro por participação devem ocorrer apenas quando ativos reais são introduzidos.

7. Incidente Desconhecido 4

Resumo Breve

Em 26 de março de 2026, um contrato de staking TUR com recompensas de indicação na BNB Chain foi explorado por aproximadamente $133,5K. O contrato Stake calculava o valor do depósito usando preços spot ao vivo de AMM, que são manipuláveis dentro de uma única transação. O atacante usou um flash loan para inflar o preço do TUR, fez staking durante a janela inflada e drenou recompensas excessivas de TUR por meio de contas de indicadores controladas por ele mesmo.

Contexto

O contrato Stake (0x03D809...415Abe) é um contrato de staking de TUR com recompensas de indicação. Os usuários primeiro vinculam um upline via bind(), depois chamam stake(), que queima o TUR em stake (enviando-o para 0xdead) e credita ao usuário um power interno, um peso que determina quanto de recompensa em TUR o usuário pode posteriormente reivindicar.

power não é atribuído em uma proporção fixa. Em vez disso, getPowerAmount() converte o TUR depositado em um valor denominado em USDT encadeando dois preços ao vivo de AMM: TUR/NOBEL e NOBEL/USDT, ambos lidos das reservas atuais do par. O contrato também concede power bônus aos indicadores de primeiro e segundo nível por meio de _distributeRefPower().

Análise da Vulnerabilidade

A causa raiz foi uma dependência insegura de preço spot no contrato Stake. A cada depósito, stake() calcula uValue = getPowerAmount(amount), converte para _power = _uValue * 100, atualiza a contabilidade do staker e então chama _distributeRefPower() para propagar power extra para os indicadores upstream.

Especificamente, uValue é calculado da seguinte forma:

$uValue=getPowerAmount(amount)uValue\; =\; getPowerAmount(amount)$

onde getPowerAmount() é efetivamente:

$amount\times \text{pre}\stackrel{¸}{\text{c}}\text{o spot TUR/NOBEL}\times \text{pre}\stackrel{¸}{\text{c}}\text{o spot NOBEL/USDT}amount\; \backslash times\; \backslash text\{preço\; spot\; TUR/NOBEL\}\; \backslash times\; \backslash text\{preço\; spot\; NOBEL/USDT\}$

A implementação lê esses preços diretamente das reservas atuais do par via getReserves(), portanto a avaliação do staking depende inteiramente de preços spot da mesma transação em vez de um oráculo ou TWAP resistente à manipulação.

Isso permite que um atacante infle temporariamente a avaliação on-chain do TUR, faça staking durante a janela manipulada e receba uValue e power exagerados. A lógica de indicação amplifica o dano: _distributeRefPower() concede 20% do power do staker ao primeiro indicador e 5% ao segundo indicador, mas essas alocações extras não são correspondidas por uma atualização de rewardDebt para esses indicadores. Como resultado, contas de indicadores controladas pelo atacante podem imediatamente reivindicar recompensas desproporcionais de TUR do contrato Stake.

Análise do Ataque

A análise a seguir é baseada na transação 0x96c9ce3c...81e348.

• Passo 1: O atacante emprestou 1.900.000e18 USDT do contrato Moolah da ListaDAO como capital de flash loan.

• Passo 2: O atacante usou o capital emprestado para manipular os pools NOBEL-USDT e TUR-NOBEL, empurrando temporariamente a avaliação spot do TUR para cima de forma acentuada.

• Passo 3: Durante a janela manipulada, o atacante fez staking de 7.770.707e18 TUR no contrato Stake. A transação emitiu um StakeEvent mostrando um uValue massivamente inflado de 8.283.864e18 e power correspondente de 828.386.488e18.

• Passo 4: Como o atacante já havia organizado contas de indicadores controladas por ele mesmo, _distributeRefPower() concedeu a elas power de recompensa extra derivado da stake manipulada. Os indicadores de primeiro e segundo nível receberam as alocações de indicação esperadas de 20% e 5%.

• Passo 5: As contas de indicadores impulsionadas então reivindicaram recompensas de TUR do contrato Stake. Na mesma transação, Stake transferiu 15.238.941e18 TUR para 0xFd11...AcEaB e 3.809.924e18 TUR para 0x9007...E550B; ambos os endereços imediatamente encaminharam os mesmos valores para o atacante. A proporção de pagamento de 4:1 corresponde à divisão de power de indicação de 20% versus 5% do contrato.

• Passo 6: A transação também mostra taxas de reivindicação fluindo de Stake para a carteira de fundos 0xb302...89923, consistente com a implementação de claim() cobrando uma taxa de 3% em TUR antes de enviar recompensas aos reclamantes.

• Passo 7: Após extrair as recompensas amplificadas de TUR, o atacante trocou os rendimentos de volta em USDT, reembolsou o flash loan de 1.900.000 USDT e transferiu 133.490e18 USDT para 0xEf67...4e5898 como lucro.

Conclusão

Este incidente foi causado por um modelo de avaliação de recompensas manipulável no contrato Stake, não pela contabilidade separada de dividendos de LP do token TUR. Ao vincular o power de staking e as recompensas de indicação às proporções de reservas ao vivo de AMM, o contrato permitiu que um atacante financiado por flash loan inflasse o preço spot do TUR, fabricasse power de recompensa excessivo e drenasse TUR do contrato de staking por meio de contas de indicação controladas por ele mesmo. Um design mais seguro substituiria o preço de reserva spot por um oráculo resistente à manipulação ou TWAP suficientemente longo e garantiria que qualquer aumento de power de indicação seja acompanhado de uma contabilidade consistente de dívida de recompensa.

8. Incidente Token EST

Resumo Breve

Em 27 de março de 2026, o contrato BNBDeposit na BNB Chain foi explorado por aproximadamente $92,3K devido a dois problemas: uma dependência de preço spot no BNBDeposit e um mecanismo de queima falho no token EST. A dependência de preço permitiu que o atacante adquirisse uma grande quantidade de EST, e o mecanismo de queima falho permitiu que o atacante drenasse o pool EST-WBNB por meio de uma manipulação em estilo sanduíche.

Análise da Vulnerabilidade

A causa raiz do incidente é dupla:

1. A função onTokenReceived() no contrato BNBDeposit (0xE71547...d29A61) calculava o valor reclamável dos usuários com base no saldo do contrato e no preço spot do EST, ambos facilmente manipuláveis.

   

2. O token EST (0xD4524B...498a91) implementou um mecanismo de queima falho que permite que um atacante queime EST no pool EST-WBNB transferindo EST diretamente para o pool.

   

Como resultado, o atacante aproveitou ambas as vulnerabilidades para realizar um ataque sanduíche e sifonar WBNB do pool EST-WBNB.

Análise do Ataque

A análise a seguir é baseada na transação 0x2f1c33ea...bd1626.

• Passo 1: O atacante emprestou 250.000e18 WBNB via Moolah e converteu 15e18 WBNB em BNB para o ataque.

• Passo 2: O atacante transferiu repetidamente 0,3e18 BNB para BNBDeposit 34 vezes (total de 10,2e18 BNB). Cada transferência direta acionou a lógica de depósito. Nesta etapa, o atacante recebeu ~9.100e18 tokens LP (em contabilidade virtual) e 2,65e18 WBNB como bônus.

• Passo 3: O atacante trocou 400e18 WBNB por ~822Me18 EST e definiu BNBDeposit como destinatário, inflando tanto o saldo de EST do BNBDeposit quanto o preço do EST no pool.

• Passo 4: O atacante transferiu 1e18 EST para BNBDeposit para acionar o mecanismo de reivindicação, recebendo 20Me18 EST com base no preço e saldo amplificados.

• Passo 5: O atacante trocou 245.000e18 WBNB por ~330Me18 EST e definiu BNBDeposit como destinatário.

• Passo 6: O atacante realizou ações de transferência-skim ~150 vezes para queimar continuamente EST no pool EST-WBNB.

• Passo 7: O atacante trocou o EST restante por 245.560e18 WBNB.

• Passo 8: O atacante reembolsou o flash loan e obteve 150 WBNB de lucro.

Conclusão

Este incidente foi causado por dois problemas: uma dependência de preço spot e um mecanismo de queima falho. Para mitigar riscos semelhantes, os projetos devem garantir oráculos de preço confiáveis e uma lógica de queima de tokens sólida antes da implantação.

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