Relatório de Segurança de Agosto da Web3: 29 Principais Incidentes de Segurança, Perdas Superiores a 68,29 Milhões de Dólares

Em agosto de 2026, os principais motivos dos incidentes de segurança foram falhas em contratos, com 18 incidentes de segurança devido a falhas em contratos/rede e 2 incidentes de segurança devido ao vazamento de chaves privadas. A segurança dos contratos inteligentes e a gestão de chaves privadas continuam a ser os pontos fracos da segurança da Web3.

Escrito por: Beosin

De acordo com os dados monitorados pela plataforma Beosin Alert, em agosto de 2026, o valor total das perdas devido a vários incidentes de segurança foi de aproximadamente 76,15 milhões de dólares, com um total de 29 incidentes de segurança significativos, sendo a principal causa as falhas em contratos. Dentre estes, 18 incidentes de segurança foram causados por falhas em contratos/rede e 2 incidentes de segurança resultaram de vazamento de chaves privadas, evidenciando que a segurança dos contratos inteligentes e a gestão de chaves privadas continuam a ser os pontos fracos da segurança da Web3.

Top 10 Perdas de Agosto

No dia 13 de agosto, o endereço de um usuário pessoal 0x13e3....179e foi roubado devido ao vazamento de chaves privadas, resultando na perda de ativos criptográficos como WBTC, cbBTC, LDO, USDS, CRV, com uma perda total de aproximadamente 25,6 milhões de dólares, sendo este o incidente de segurança com a maior perda real. No dia 30 de agosto, o protocolo de empréstimo Tectonic na rede Cronos foi atacado por hackers devido a uma falha em contrato, com perdas estimadas em cerca de 74 milhões de dólares. Este ataque levou a rede Cronos a tomar medidas de emergência, suspendendo a rede e revertendo transações, com os hackers conseguindo transferir aproximadamente 6 milhões de dólares para a rede Ethereum através de transações cross-chain.

Além disso, a blockchain Harmony foi alvo de uma falha que resultou na emissão adicional de cerca de 4 bilhões de tokens ONE, com uma perda nominal superior a 4 milhões de dólares, mas que foi eliminada por meio da reversão de transações, portanto não contabilizada como perda.

Tipos de Projetos Atacados e Situação das Perdas em Cada Rede

Os alvos dos ataques deste mês incluíram várias categorias, como blockchains públicas, protocolos de empréstimo, aplicativos de carteira, contratos de tokens, pontes cross-chain e usuários comuns. Os projetos DeFi sofreram as maiores perdas, totalizando 33,09 milhões de dólares; enquanto os endereços pessoais sofreram perdas de aproximadamente 28,4 milhões de dólares devido a vazamentos de chaves privadas ou phishing. Os contratos de tokens foram os mais atacados, contabilizando 10 ataques; os contratos DeFi foram o segundo mais atacados, com um total de 9 ataques.

A blockchain com as maiores perdas em maio foi a Ethereum, com perdas superiores a 48,58 milhões de dólares, totalizando 15 incidentes de segurança. Atualmente, a maioria dos protocolos DeFi e ataques de phishing direcionados a grandes investidores ainda se concentra na Ethereum. A segunda blockchain com mais incidentes de segurança foi a BNB Chain, mas os alvos eram principalmente contratos de tokens, resultando em perdas menores. Além disso, blockchains como Cronos, Base, Harmony, Bitcoin e Solana também tiveram incidentes de segurança, apresentando uma tendência de ataques multi-chain.

Análise dos Principais Incidentes de Segurança

1. Tectonic e Moonwell: Manipulação de Preços

Tectonic e Moonwell são protocolos de empréstimo on-chain, e os motivos dos ataques foram a manipulação dos preços de colaterais de tokens com baixa liquidez, permitindo que ativos fossem emprestados a valores inflacionados, resultando em lucros. No ataque ao Tectonic, os atacantes conseguiram elevar o preço do token de governança $TONIC em 100 vezes, obtendo um limite de empréstimo de aproximadamente 74 milhões de dólares, e em seguida emprestaram ativos como USDT. Após o incidente, a rede Cronos suspendeu urgentemente toda a cadeia, e os atacantes conseguiram transferir cerca de 6 milhões de dólares para a Ethereum antes da suspensão da rede. A rede Cronos então reverteu as transações para recuperar as perdas.

Endereço de lucro do hacker na Ethereum: 0xc404160B79BD8905061a1cAecBeCa2EEab3f72DD e fluxo de fundos roubados:

Atualmente, cerca de 2659 ETH ainda estão armazenados em 0xc4041, e 140,1 ETH foram transferidos para 0x6df89c42f0abdfaa2b5b77edcdafbc945ed6ee6c e depois enviados para vários novos endereços criados.

Moonwell foi atacado porque os atacantes manipularam o preço do token MAMO com baixa liquidez para emprestar cbBTC, resultando em uma perda de aproximadamente 8,7 milhões de dólares:

Esses dois ataques não foram baseados em falhas de contratos inteligentes, mas sim porque o protocolo precificou incorretamente os colaterais a partir de uma liquidez de mercado fraca. Para evitar tais ataques, o protocolo pode obter dados de diferentes fontes através de múltiplos oráculos e fazer julgamentos adicionais em casos de flutuações de preços acentuadas.

2. Harmony: Ataque de Repetição

Harmony é uma Layer 1 que suporta sharding, operando quatro shards e transferindo ativos entre eles através de um mecanismo assíncrono baseado em recibos. O shard de origem gera um recibo criptográfico para transações de saída, enquanto o shard 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 do ataque estava em partes legadas do sistema de sharding da Harmony. Anteriormente, a Harmony verificava se os recibos de sharding haviam sido usados através de dois campos CXMerkleProof.ShardID e BlockNum,

Como esses dois campos estão fora do cabeçalho do bloco assinado, os atacantes puderam modificá-los sem comprometer nenhuma funcionalidade existente. Neste ataque, os atacantes obtiveram um recibo cross-shard e modificaram o ShardID e o BlockNum, fazendo com que o validador o reconhecesse como um novo recibo. O shard de destino aceitou o recibo modificado e o registrou novamente, enquanto o shard original não deduziu os ativos correspondentes.

Este é um ataque de repetição muito típico. Para qualquer campo usado como "token de uso único", ele deve ser parte do cabeçalho assinado. Ao validar recibos, deve-se ler diretamente o ID do shard e o número do bloco do cabeçalho já assinado, em vez de confiar em campos não autenticados na estrutura de prova.

3. Term Finance: Ataque de Governança

Term Finance é um protocolo de empréstimo DeFi de taxa fixa, onde cada cofre (Vault) é um Vault ERC-4626 baseado no código do Yearn V3. A governança do cofre da Term Finance não é baseada em votação de aprovação, mas sim em votação de rejeição. Quando um curador propõe uma alteração de parâmetro, os governantes abrem uma janela para que os detentores de tokens LP apresentem objeções. No entanto, a configuração do limiar de participação na votação apresenta sérias vulnerabilidades:

● Falta de um limite absoluto de votos ou capital: As condições para a aprovação de propostas isSupportThresholdReached() e isMinParticipationReached() apenas verificam proporções relativas, e não o número absoluto de votos. Isso significa que, desde que uma maioria relativa seja alcançada, a proposta pode ser aprovada, independentemente do número total de pessoas que votaram ou do capital total.

● Participação extremamente baixa: Quase nenhum depositante converteu sua participação no cofre (tmvETH) em tokens de governança (gtmvETH) para participar da votação. Isso resultou em um suprimento total de tokens de governança do cofre extremamente baixo.

Os atacantes exploraram essas falhas de design para realizar um ataque de governança ao cofre a um custo muito baixo:

(1) Obtenção de direitos de voto: Os atacantes trocaram cerca de 0,5 ETH por aproximadamente 0,485 de participação no cofre tmvETH e a converteram 1:1 em 0,485 de tokens de governança gtmvETH, obtendo assim direitos de voto.

(2) Proposta maliciosa: Ao criar a proposta, o contrato registrou que o suprimento total de tokens de governança era apenas 0,535 gtmvETH. Isso significa que os 0,485 gtmvETH detidos pelos atacantes representavam 90,66% do total.

(3) Votação e execução: Os atacantes, como únicos votantes, votaram 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 superou o limiar mínimo de participação calculado com base no suprimento total extremamente baixo (minVotingPower).

(4) Retirada de ativos: Após a aprovação da proposta, foram executadas operações maliciosas para retirar os ativos (WETH) do cofre.

Os atacantes usaram a mesma tática para comprometer 6 cofres da Term Finance, resultando em perdas de aproximadamente 8,5 milhões de dólares.

Este ataque também é um exemplo típico de ataque de governança de protocolo on-chain. Para a governança on-chain, os projetos devem estabelecer os seguintes pontos de verificação para prevenção:

● Estabelecer um limite absoluto de votos ou capital: As propostas de governança não podem depender apenas de proporções relativas para serem aprovadas. Deve haver um limite rígido baseado em números absolutos, como exigir que os votos a favor atinjam um certo valor (por exemplo, 1 milhão de dólares) ou um número mínimo de endereços distintos.

● Equipar o tempo de bloqueio com um guardião ou caminho de cancelamento: Embora a execução da governança geralmente tenha um atraso, isso apenas reserva um tempo de reação. Os projetos devem equipar um mecanismo de monitoramento eficaz (Guardian) ou um caminho de cancelamento para o período de atraso de execução. Se uma proposta maliciosa for descoberta durante o período de atraso, o guardião pode intervir imediatamente e cancelar.

● Monitorar a participação na governança: O protocolo deve estabelecer um monitoramento em tempo real da participação na governança de cada cofre. Quando um suprimento total de tokens de governança ou a taxa de participação de votos de um cofre for anormalmente baixa, um alerta deve ser emitido imediatamente, podendo até acionar automaticamente medidas de proteção.

Tendências de Ameaças à Segurança da Web3

A tendência mais profunda da segurança da Web3 em 2026 é a ampliação sistemática da superfície de ataque. Vulnerabilidades estão surgindo simultaneamente em nível de código, operações diárias e interações, e confiar apenas em algumas auditorias de segurança ou ferramentas não é suficiente para cobrir a segurança operacional, governança on-chain, vulnerabilidades na lógica de operação comercial, entre outros. Isso apresenta novos desafios para as equipes de projetos da Web3 na construção de sistemas de defesa de segurança.

Além disso, ataques frequentes a contratos DeFi e usuários individuais. Vulnerabilidades em contratos ou autorizações são facilmente exploradas por atacantes, e desenvolvedores ou operadores de contratos devem revisar a segurança dos contratos. Para contratos que lidam com negócios essenciais, múltiplas auditorias de segurança de diferentes partes devem ser realizadas. Para usuários individuais, é importante usar regularmente exploradores de blockchain ou ferramentas de revogação de autorização para verificar e cancelar autorizações de contratos que não estão mais em uso, além de se manter informado sobre métodos de phishing comuns e novos, aumentando a conscientização sobre segurança.