2025 foi mais um ano intenso para a segurança em cripto. Uma série de incidentes de alto impacto abalou o ecossistema e deixou danos reais em seu rastro, afetando usuários, equipes e comunidades em todo o espaço. Embora os resultados frequentemente tenham sido dolorosos, cada evento também reforça uma verdade familiar: a segurança deve ser tratada como uma prioridade de primeira classe.
Para ajudar a comunidade a aprender com o que aconteceu, a BlockSec selecionou dez incidentes que mais se destacaram este ano. Esses casos foram escolhidos não apenas pela escala das perdas, mas também pelas técnicas distintas envolvidas, pelos reviravoltas inesperados na execução e pelas superfícies de ataque novas ou pouco exploradas que revelaram.
Neste post, destacamos os dez principais incidentes de segurança de 2025 e explicamos por que cada um merece atenção. Também publicaremos um artigo dedicado de acompanhamento para cada caso, detalhando a causa raiz e o caminho completo do ataque.
Incidente Cetus: O Maior Hack DeFi de 2025
Resumo
Em 22 de maio de 2025, o Cetus Protocol, a maior DEX de liquidez concentrada na Sui, foi explorado por aproximadamente ~$223M, com liquidez drenada de múltiplos pools. A causa raiz foi uma função auxiliar de prevenção de overflow com falha (checked_shlw()) na matemática de ponto fixo u256: um limiar incorreto permitiu que um deslocamento à esquerda << 64 inseguro prosseguisse, truncando silenciosamente os bits superiores. Ao escolher cuidadosamente o tamanho da liquidez e faixas de tick estreitas, o atacante fez o Cetus calcular o depósito de token necessário como ~1 unidade, enquanto creditava uma posição de LP com liquidez enorme, e então removeu essa posição inflada para sacar reservas reais.
Motivo da Seleção
Uma única comparação incorreta em uma função auxiliar de ponto fixo foi suficiente para drenar $223M. O atacante não manipulou oráculos nem explorou governança: todo o ataque baseou-se em casos extremos de aritmética pura (deslocamento + truncamento) para criar liquidez quase gratuita e retirar reservas reais de forma determinística. Para qualquer protocolo construído sobre matemática de liquidez concentrada, este caso é um alerta direto de que erros silenciosos de limite em operações de ponto fixo de baixo nível podem escalar até uma catástrofe em nível de protocolo.
Saiba mais sobre a causa raiz e as etapas do ataque em detalhes.
Bybit: O Maior Hack de 2025
Resumo
Em 21 de fevereiro de 2025, a Bybit perdeu aproximadamente $1,5 bilhão após um atacante comprometer a máquina de um desenvolvedor do Safe{Wallet} por meio de engenharia social. Com esse acesso, o atacante injetou JavaScript malicioso no bucket AWS S3 do Safe{Wallet}. O código injetado tinha como alvo específico as transações do Safe{Wallet} da Bybit, adulterando o conteúdo das transações durante o processo de assinatura. A transação adulterada atualizou o contrato Safe{Wallet} da Bybit para uma implementação maliciosa, permitindo que o atacante drenasse todos os ativos mantidos pelo contrato.
Motivo da Seleção
A maior violação de segurança da história das criptomoedas não começou com um bug em contrato inteligente. Começou com a máquina de um desenvolvedor comprometida e um arquivo JavaScript adulterado em um bucket S3. O caminho do ataque ocorreu inteiramente por meio de infraestrutura Web2: engenharia social, armazenamento em nuvem e injeção de código no front-end. Para um setor focado em segurança on-chain, a Bybit é um lembrete direto de que segurança operacional e de infraestrutura são igualmente essenciais. Uma multisig é tão segura quanto a interface de assinatura em que seus proprietários confiam.
Saiba mais sobre a causa raiz e as etapas do ataque em detalhes.
Balancer V2
Resumo
Em 3 de novembro de 2025, os Composable Stable Pools do Balancer V2 e vários projetos derivados em múltiplas redes foram explorados em um ataque coordenado, resultando em perdas totais superiores a $125 milhões. A causa raiz foi a perda de precisão no cálculo do invariante, que distorceu a precificação do BPT (Balancer Pool Token). O atacante explorou essa distorção em duas etapas: primeiro manipulando o preço do BPT por meio de um batch swap elaborado, e depois extraindo lucro ao retirar ativos em uma transação separada.
Motivo da Seleção
Ao contrário dos ataques típicos de manipulação de oráculos, esse exploit teve origem dentro do próprio cálculo do invariante: uma pequena perda de precisão na matemática de ponto fixo foi suficiente para distorcer a precificação do BPT e possibilitar a extração lucrativa em uma única transação. O ataque se propagou por múltiplas redes e afetou tanto o Balancer quanto seus forks, ilustrando como bases de código compartilhadas amplificam o risco sistêmico no DeFi composável. As discussões da comunidade sobre a causa raiz frequentemente simplificaram demais a mecânica. A análise completa rastreia como a perda de precisão no solver do invariante se traduz em lacunas de precificação exploráveis.
Saiba mais sobre a causa raiz e as etapas do ataque em detalhes.
GMX
Resumo
Em 9 de julho de 2025, o GMX V1 na Arbitrum foi explorado por aproximadamente $42 milhões. O atacante acionou uma vulnerabilidade de reentrância para manipular o preço do GLP no meio da transação e, em seguida, usou o preço distorcido para adquirir ativos muito além do valor depositado. Por meio de exploração repetida, o atacante gradualmente drenou os ativos subjacentes dos pools de liquidez do GMX V1.
Motivo da Seleção
A reentrância é uma das vulnerabilidades mais antigas conhecidas em contratos inteligentes, ainda assim derrubou um protocolo battle-tested com um modelo de ACL estabelecido. O modificador nonReentrant no contrato OrderBook preveniu reentrância no mesmo contrato, mas não fez nada para impedir chamadas entre contratos ao Vault durante o fallback. O GMX V1 estava ativo há anos, um histórico que pode criar uma falsa sensação de segurança. Este caso demonstra que a maturidade do protocolo não substitui a análise de reentrância em nível de sistema, e que guardas de contrato único são insuficientes quando múltiplos contratos compartilham estado mutável.
Saiba mais sobre a causa raiz e as etapas do ataque em detalhes.
Yearn Finance
Resumo
Em 30 de novembro de 2025, o yETH Weighted Stable Pool da Yearn Finance foi explorado por mais de $9 milhões. A causa raiz primária foi a aritmética insegura no solver do invariante _calc_supply(), cujas falhas de arredondamento para baixo e underflow foram responsáveis independentemente por ~$8,1M (90% das perdas). Uma vulnerabilidade secundária, um caminho de bootstrap não desabilitado em add_liquidity(), possibilitou ~$0,9M adicionais após o exploit primário já ter drenado o pool.
O atacante executou uma estratégia em múltiplas fases: primeiro, adicionando e removendo liquidez repetidamente para criar um desequilíbrio extremo nos saldos virtuais do pool; em seguida, explorando as falhas aritméticas para colapsar o termo do produto e reduzir o supply total a zero; por fim, reingressando no caminho de inicialização do bootstrap para cunhar ~2,35e56 yETH via underflow e trocá-los por ativos reais no pool yETH-WETH da Curve.
Motivo da Seleção
A perda financeira foi moderada para os padrões de 2025, mas a complexidade técnica do exploit é excepcional. O ataque encadeia casos extremos numéricos (colapso de divisão, inversões de sinal no solver do invariante) com reentrada na máquina de estados (re-acionamento da inicialização do pool após o deploy), exigindo manipulação precisa e em múltiplas fases do estado on-chain. Reconstruir completamente o exploit exige compreender tanto a aritmética de baixo nível quanto as transições de estado mais amplas. A combinação de sutileza, rigor e profundidade educacional deste caso o torna um dos incidentes analiticamente mais ricos do ano.
Saiba mais sobre a causa raiz e as etapas do ataque em detalhes.
Cork Protocol
Resumo
Em 28 de maio de 2025, o Cork Protocol na Ethereum foi explorado, resultando em aproximadamente $12 milhões em perdas. A causa raiz foi uma combinação de manipulação do preço HIYA no momento de expiração e ausência de controle de acesso em um callback de hook do Uniswap v4. Como o HIYA (Historical Implied Yield Average, uma métrica de prêmio de risco usada para precificar novas emissões de mercado) aumenta exponencialmente conforme o tempo até o vencimento se aproxima de zero, swaps realizados próximos ao vencimento inflaram o HIYA e fizeram com que mercados recém-inicializados precificassem os Cover Tokens muito abaixo do valor real. Ao mesmo tempo, CorkHook.beforeSwap não possuía autenticação de msg.sender, permitindo chamadas arbitrárias com parâmetros elaborados. Ao explorar ambas as falhas, o atacante extraiu grandes quantidades de CT e DS e os converteu de volta em wstETH, drenando as reservas do protocolo.
Motivo da Seleção
Nem a curva de precificação no momento de expiração nem o callback de hook sem autenticação eram individualmente catastróficos. Sua interação foi. O prêmio exponencial do HIYA próximo ao vencimento criou um amplificador econômico, e a ausência da verificação de msg.sender em CorkHook.beforeSwap deu ao atacante uma forma de acioná-lo com parâmetros arbitrários. Este caso ilustra uma classe de vulnerabilidades que auditorias de módulo único provavelmente deixarão passar: incompatibilidades de suposição entre módulos, onde o design econômico e o controle de acesso interagem para produzir um caminho explorável.
Saiba mais sobre a causa raiz e as etapas do ataque em detalhes.
Trust Wallet
Resumo
Em 25 de dezembro de 2025, a Trust Wallet sofreu um ataque à cadeia de suprimentos que comprometeu mais de 2.000 carteiras de usuários, resultando em $8,5 milhões em perdas. O atacante obteve a chave de API da Chrome Web Store da Trust Wallet e a utilizou para publicar uma extensão com backdoor (v2.68) por meio dos canais oficiais. A extensão maliciosa exfiltrou as frases-semente dos usuários para um servidor controlado pelo atacante. O atacante então drenou os fundos das carteiras comprometidas.
Motivo da Seleção
O atacante nunca tocou em um contrato inteligente. Ao comprometer uma única chave de API, publicou uma extensão maliciosa pelo canal de distribuição oficial da Trust Wallet, contornando tanto a revisão manual quanto o processo de lançamento padrão. Os usuários não tinham motivo para desconfiar da atualização. Este é o único ataque à cadeia de suprimentos de carteira no Top 10, e expõe uma categoria de risco que auditorias on-chain não conseguem cobrir: a segurança do pipeline de entrega de software entre o desenvolvedor e o usuário final.
Saiba mais sobre a causa raiz e as etapas do ataque em detalhes.
Bunni
Resumo
Em 2 de setembro de 2025, o Bunni V2 foi explorado em $8,4 milhões nos pools USDC/USDT na Ethereum e weETH/ETH na Unichain. O protocolo posteriormente declarou falência em 23 de outubro de 2025. A causa raiz foi um erro de arredondamento na atualização dos saldos idle do pool durante a remoção de liquidez, que fazia o contrato subestimar sua própria liquidez total.
O atacante executou um ataque em três etapas: primeiro, manipulando o preço do pool para esgotar o saldo disponível de USDC e amplificar o erro de arredondamento; em seguida, executando uma série de pequenas retiradas que acumularam a subestimação de liquidez; por fim, realizando swaps direcionais para arbitrar a diferença entre a liquidez registrada pelo protocolo e suas reservas reais.
Motivo da Seleção
O Bunni V2 havia passado por múltiplas auditorias de código, ainda assim um pequeno erro de arredondamento na contabilidade de saldos idle não foi detectado. O erro por si só era insignificante por transação, mas o atacante o amplificou por meio de retiradas pequenas e repetidas após deliberadamente distorcer o estado do pool, transformando uma perda de precisão fracionária em uma drenagem de $8,4M. O caso demonstra como erros de arredondamento que parecem seguros isoladamente podem se tornar exploráveis quando um atacante controla a sequência e as condições sob as quais eles se acumulam.
Saiba mais sobre a causa raiz e as etapas do ataque em detalhes.
1inch
Resumo
Em 5 de março de 2025, um resolver de terceiros integrado ao 1inch Fusion V1 foi explorado por mais de $5M devido à reconstrução insegura de calldata em _settleOrder(). Um interactionLength controlado pelo atacante corrompeu a montagem em memória do sufixo dinâmico usado para propagar a identidade do resolver e o contexto de execução, permitindo a injeção de dados de liquidação forjados. Como os contratos resolvers confiavam implicitamente no calldata encaminhado pelo contrato Settlement baseando-se apenas em msg.sender, o contexto forjado passou por todas as verificações de controle de acesso e levou à extração não autorizada de ativos.
Motivo da Seleção
Este exploit borra a fronteira entre vulnerabilidades em contratos inteligentes e exploração binária tradicional. Em vez de abusar de suposições econômicas ou lógica de negócio de alto nível, o ataque se baseia em aritmética de ponteiros, campos de comprimento sem verificação e suposições sobre o layout de memória ABI, padrões mais comumente vistos em exploits de software nativo como buffer overflows e integer underflows. Demonstra como a manipulação de calldata e memória de baixo nível pode reintroduzir primitivas clássicas de exploração em sistemas on-chain, especialmente quando combinada com cadeias de confiança implícitas entre contratos.
Saiba mais sobre a causa raiz e as etapas do ataque em detalhes.
Panoptic
Resumo
Em 25 de agosto de 2025, com a assistência da Cantina e da Seal911, a Panoptic conduziu uma operação de resgate whitehat, protegendo aproximadamente $400K em fundos em risco. A causa raiz foi uma falha na construção do s_positionsHash pelo contrato: o uso de XOR para agregar resultados de hash Keccak256. Embora uma única função de hash permaneça resistente a colisões, a linearidade matemática do XOR torna a impressão digital geral (a soma XOR dos hashes) insegura, permitindo que conjuntos de posições distintos produzam hashes idênticos.
Motivo da Seleção
A maioria dos incidentes nesta lista remonta a bugs aritméticos ou ausência de controle de acesso. A vulnerabilidade da Panoptic é diferente: é uma falha de design criptográfico no nível da estrutura de dados. O protocolo dependia do XOR para compor impressões digitais de posições, assumindo que o resultado herdaria a resistência a colisões dos hashes Keccak256 subjacentes. Não herda. A linearidade do XOR significa que um atacante pode construir conjuntos de posições distintos que produzem valores idênticos de s_positionsHash, contornando os invariantes de contabilidade. O resgate whitehat bem-sucedido evitou a perda, mas a falha subjacente é um lembrete útil de que a composição de hashes exige o mesmo cuidado que a própria função de hash.
Saiba mais sobre a causa raiz e as etapas do ataque em detalhes.
