De acordo com dados monitorados pela plataforma Beosin Alert, em agosto de 2026, o valor total perdido em diversos eventos de segurança foi de aproximadamente US$ 76,15 milhões, com um total de 『29』 eventos de segurança significativos, cuja principal causa foram vulnerabilidades em contratos. Entre eles, 18 eventos foram causados por vulnerabilidades em contratos/rede, e 2 eventos resultaram em perdas devido a vazamento de chaves privadas; segurança de contratos inteligentes e gerenciamento de chaves privadas permanecem como pontos fracos na segurança Web3.
Top 10 de perdas em agosto
Em 13 de agosto, o endereço de usuário individual 0x13e3....179e sofreucomprometimento da chave privada e teve seus ativos criptográficos WBTC, cbBTC, LDO, USDS, CRV, entre outros, roubados, com perda total estimada em cerca de 25,6 milhões de dólares, sendo o incidente de segurança com o maior prejuízo real. Em 30 de agosto,Cronos a protocolo de empréstimo na rede Tectonic sofreu um ataque de hacker devido a uma vulnerabilidade no contrato, com perda prevista de cerca de 74 milhões. Este ataque levou a rede Cronos a adotar medidas de emergência, suspendendo a rede e revertendo transações; o hacker finalmente transferiu com sucesso cerca de 6 milhões de dólares para a redeEthereum.
Além disso, a cadeia Harmony teve aproximadamente 4 bilhões de tokens ONE cunhados adicionais devido a uma vulnerabilidade, com perda nominal superior a US$ 4 milhões, mas os tokens falsificados foram finalmente removidos por meio da reversão das transações, não sendo contabilizados como perda.
Tipos de projetos atacados e perdas por cadeia
Os alvos deste mês abrangem cadeias públicas, protocolos de empréstimo, aplicativos de carteira, contratos de tokens, pontes cross-chain e usuários comuns, sendo que os projetos DeFi sofreram os maiores prejuízos, totalizando US$ 33,09 milhões; enquanto endereços pessoais sofreram perdas de aproximadamente US$ 28,4 milhões devido a vazamento de chaves privadas ou phishing. Os contratos de tokens foram atacados com mais frequência, totalizando 10 ocorrências; os contratos DeFi ficaram em segundo lugar, com 9 ataques.
A cadeia com o maior valor perdido em maio foi a Ethereum, com perdas superiores a US$ 48,58 milhões, totalizando 15 incidentes de segurança; atualmente, a maioria dos protocolos DeFi e ataques de phishing direcionados a grandes detentores ainda se concentra na Ethereum. A segunda cadeia com mais incidentes de segurança foi a BNB Chain, mas os alvos principais foram contratos de tokens, com perdas menores. Além disso, outras cadeias públicas, como Cronos, Base, Harmony, Bitcoin e Solana, também registraram incidentes de segurança, indicando uma tendência de ataques multichain.
Análise principal de eventos de segurança
1. Tectonic e Moonwell: Manipulação de preços
Tectonic e Moonwell são protocolos de empréstimo on-chain cujos ataques ocorreram devido à manipulação dos preços de ativos de garantia com baixa liquidez, permitindo que os atacantes emprestassem quantias excedentes com base em valores de ativos inflados. No ataque à Tectonic, os atacantes aumentaram o preço do token de governança da Tectonic, $TONIC, em 100 vezes, obtendo um limite de empréstimo de aproximadamente US$ 74 milhões e, em seguida, retirando ativos como USDT. Após o incidente, a rede Cronos suspendeu emergencialmente a produção de blocos, e os atacantes transferiram cerca de US$ 6 milhões para a Ethereum antes da suspensão. Posteriormente, a rede Cronos realizou um rollback para recuperar os prejuízos.
Endereço de lucro do hacker do Ethereum: 0xc404160B79BD8905061a1cAecBeCa2EEab3f72DD e fluxo dos fundos roubados:
Atualmente, cerca de 2659 ETH ainda estão armazenados em 0xc4041, 140,1 ETH foram transferidos para 0x6df89c42f0abdfaa2b5b77edcdafbc945ed6ee6c e posteriormente distribuídos para múltiplos endereços recém-criados.
Moonwell sofreu uma perda de aproximadamente US$ 8,7 milhões porque o atacante manipulou o preço do token MAMO com baixa liquidez para emprestar cbBTC:
Esses dois ataques não foram baseados em vulnerabilidades de contratos inteligentes, mas sim no fato de que o protocolo precifica as garantias com base na liquidez spot frágil, calculando incorretamente o valor das garantias. Para evitar esse tipo de ataque, o protocolo pode obter dados de várias fontes por meio de múltiplos oráculos e realizar verificações adicionais em caso de flutuações bruscas de preço.
2. Harmony: Ataque de replay
Harmony é uma Layer 1 que suporta sharding, operando quatro sharding e transferindo ativos entre eles por meio de um mecanismo assíncrono baseado em recibos. O sharding de origem gera recibos criptografados para transações de saída, e o sharding de destino é responsável por verificar se o recibo e sua prova Merkle correspondem ao cabeçalho do bloco de origem assinado antes de registrar a transação, e cada recibo só pode ser usado uma vez.
A vulnerabilidade deste ataque existe na parte hereditária do sistema de sharding da Harmony. Anteriormente, a Harmony verificava se os recibos de sharding já haviam sido utilizados consultando dois campos: CXMerkleProof.ShardID e BlockNum.
Como esses dois campos estão fora do cabeçalho do bloco assinado, o atacante pode modificá-los sem comprometer qualquer funcionalidade existente. Neste ataque, o atacante obteve um recibo entre shards e alterou o ShardID e o BlockNum, fazendo com que o programa de verificação o reconhecesse como um recibo totalmente novo. O shard alvo aceitou o recibo modificado e o registrou novamente, enquanto o shard original não deduziu os ativos correspondentes.
Este é um ataque de replay muito típico. Para qualquer campo usado como "marca de uso único", ele deve fazer parte do cabeçalho assinado. Ao validar o recibo, o ID do fragmento e o número do bloco devem ser lidos diretamente do cabeçalho do bloco verificado, e não confiar em campos não autenticados na estrutura de prova.
3. Term Finance: Ataque de governança
Term Finance é um protocolo DeFi de empréstimo com taxa de juros fixa, cujo cada cofre (Vault) é um Vault ERC-4626 baseado no código do Yearn V3. A governança dos cofres do Term Finance não é baseada em votos de aprovação, mas em votos de veto. Quando um curador propõe uma alteração de parâmetros, os governantes abrem uma janela para que os detentores de tokens LP apresentem objeções. Existe uma falha grave no limite definido para a votação de governança:
● Falta de número absoluto de votos ou limite de capital: as condições para aprovação da proposta, isSupportThresholdReached() e isMinParticipationReached(), verificam apenas proporções relativas, e não números absolutos de votos. Isso significa que, desde que seja atingida a maioria relativa, a proposta será aprovada, independentemente do número total de participantes ou do volume total de capital emitido.
● Baixa participação: quase nenhum depositante transformou as cotas do cofre (tmvETH) em tokens de governança (gtmvETH) para participar das votações. Isso resultou em uma oferta total de tokens de governança do cofre relacionado extremamente baixa.
Os atacantes exploraram o defeito de design acima para realizar um ataque de governança ao cofre com custo extremamente baixo:
(1) Obter direito de voto: o atacante trocou cerca de 0,5 ETH por cerca de 0,485 cotas do tesouro tmvETH e as encapsulou 1:1 em 0,485 tokens de governança gtmvETH, obtendo direito de voto.
(2) Apresentação de proposta maliciosa: ao criar a proposta, o contrato registrou que o total em circulação de tokens de governança era de apenas 0,535 gtmvETH. Isso significa que os 0,485 gtmvETH detidos pelo atacante representavam 90,66% do total.
(3) Votação e execução: O atacante, como único votante, emitiu um voto a favor. Como não houve votos contrários, sua taxa de apoio superou amplamente o limiar de 50%; ao mesmo tempo, seu poder de voto pessoal também ultrapassou o limite mínimo de participação calculado com base na oferta total extremamente baixa (minVotingPower).
(4) Retirada de ativos: Após a aprovação da proposta, foi executada uma operação maliciosa para retirar os ativos do cofre (WETH)
Os atacantes usaram a mesma técnica para comprometer seis cofres do Term Finance, causando perdas de aproximadamente US$ 8,5 milhões.
Este ataque também é um ataque muito típico à governança de protocolo na cadeia. Para a governança na cadeia, os desenvolvedores do projeto devem definir os seguintes pontos de verificação para prevenção:
● Definir um número absoluto de votos ou um limite de capital: propostas de governança não podem ser aprovadas apenas com base em proporções relativas. Deve ser estabelecido um limite mínimo absoluto, como exigir que os votos a favor atinjam um valor específico (por exemplo, 1 milhão de dólares) ou um número mínimo de endereços independentes.
● Configure a guardian or veto path for the time lock: Although governance execution typically has a delay, this merely provides a window for response. Project teams must implement an effective guardian mechanism or proposal veto path during the execution delay period. If a malicious proposal is detected within the delay period, the guardian can immediately intervene and cancel it.
● Monitorar a participação na governança: o protocolo deve estabelecer monitoramento em tempo real da participação na governança de cada tesouraria. Quando for detectada uma participação baixa anormal no total de tokens de governança ou na taxa de participação de votação de uma tesouraria, emitir um alerta imediato e até acionar automaticamente medidas de proteção.
Tendências de ameaças à segurança Web3
A tendência mais profunda apresentada pela segurança Web3 em 2026 é a expansão sistemática da superfície de ataque. Vulnerabilidades estão surgindo simultaneamente nos níveis de código, operações cotidianas e interações; auditorias de segurança e ferramentas isoladas não conseguem cobrir aspectos como segurança operacional, governança on-chain e falhas na lógica de negócios. Isso apresenta novos desafios para os projetos Web3 construírem sistemas de defesa seguros.
Além disso, ataques a contratos DeFi e usuários individuais ocorrem com frequência. Vazamentos de contratos ou autorizações podem ser facilmente explorados por atacantes; desenvolvedores e operadores de contratos devem revisar a segurança dos contratos e, para contratos que lidam com negócios essenciais, realizar múltiplas auditorias de segurança por partes distintas. Para usuários individuais, é recomendável verificar periodicamente e revogar autorizações de contratos não mais utilizados por meio de navegadores de blockchain ou ferramentas de revogação de autorização, além de se informar sobre técnicas de phishing comuns e recém-aparecidas, aumentando assim a consciência de segurança.
Este artigo foi elaborado pela equipe de segurança da Beosin, combinando o sistema de alertas de segurança Beosin Alert, dados on-chain e análises pós-evento divulgadas oficialmente pelo projeto. Caso tenha alguma dúvida, fique à vontade para nos contatar e fornecer feedback.