Auditados, Testados e Ainda Quebrados: Hacks de Contratos Inteligentes de 2025

2025 foi um ano de exploits de contratos inteligentes. Protocolos que passaram múltiplas auditorias, protocolos que foram testados em batalha durante anos, protocolos construídos por equipas com profunda experiência em segurança. Todos foram vítimas de ataques que revelaram algo desconfortável: estamos a melhorar na identificação de bugs tradicionais, mas ainda estamos a perder falhas fundamentais na forma como os protocolos pensam sobre economia, matemática e design de sistema.

Esta retrospetiva examina os incidentes tecnicamente mais interessantes do ano, ordenados pelo que nos ensinam sobre segurança de contratos inteligentes. Vamos explorar como violações de invariantes económicas permitiram aos atacantes criar tokens infinitos, como erros de precisão na matemática AMM transformaram pequenos erros de arredondamento em exploits de milhões de dólares, e como falhas nos limites do sistema expuseram vulnerabilidades que nenhuma auditoria de componente único poderia detetar.

Os Destaques: Falhas Profundas de Protocolo

Estes hacks revelam problemas fundamentais no design de protocolos, falhas que vão além de simples erros e tocam em pressupostos centrais sobre como os sistemas DeFi devem funcionar.

Yearn Finance: Exploits de Infraestrutura Legada ($9,3M total)

Dezembro de 2025

A Yearn Finance sofreu dois exploits relacionados em dezembro de 2025, ambos visando infraestrutura legada que permaneceu on-chain após atualizações do protocolo.

Primeiro exploit: Violação de Invariante Económica ($9M) — 1 de dezembro

O pool stableswap yETH legado da Yearn Finance foi drenado numa única transação. O atacante encontrou uma falha na lógica de cálculo de participações que permitiu criar um número quase infinito de tokens yETH. Cerca de 1.000 ETH (no valor de aproximadamente $3 milhões) foram enviados para o Tornado Cash.

O atacante encontrou um caso limite nas fórmulas stableswap onde os cálculos de participações podiam ser manipulados. A vulnerabilidade existia na própria lógica contabilística. Quando o protocolo calculava participações para depósitos ou levantamentos, a matemática podia ser manipulada para criar participações do nada.

Segundo exploit: Risco de Contrato Legado ($300K) — 17 de dezembro

Após o primeiro exploit, os contratos V1 da Yearn foram visados. Quando os protocolos são atualizados, os contratos antigos não desaparecem. Permanecem on-chain, potencialmente com valor. No caso da Yearn, os contratos V1 ainda tinham fundos bloqueados, e esses fundos tornaram-se um alvo depois do primeiro exploit ter chamado a atenção para a infraestrutura legada da Yearn.

Porque é importante (perspetiva de auditor e organizacional):

O primeiro exploit mostra uma lacuna importante na metodologia de auditoria. Ferramentas de análise estática não verificam invariantes económicas. Fuzzers testam caminhos de código, não modelos económicos. Os processos de auditoria precisam de verificar claramente que a lógica contabilística mantém as invariantes pretendidas em todas as sequências de operação.

O segundo exploit destaca que contratos legados representam risco contínuo. O primeiro exploit pode ter chamado a atenção para a infraestrutura legada da Yearn, levando ao segundo. Os protocolos precisam de planos claros para desativar contratos antigos, migrar o valor restante e monitorizar interações inesperadas.

Mitigação: Implementar testes de invariantes que afirmem que as relações participação-valor se mantêm em todas as operações. Usar fuzzing diferencial para comparar cálculos contabilísticos com implementações de referência. Ter estratégias de descontinuação claras para contratos legados com monitorização contínua.

A classe de vulnerabilidade: Violação de invariante económica e risco de contrato legado.

Análise aprofundada: Yearn Finance DeFi Project Hacked for $9M | PeckShield Alert | Yearn Finance V1 Exploit

Balancer: Exploração de Erro de Arredondamento ($70–128M)

3 de novembro de 2025

Pequenos erros de arredondamento nos cálculos de pool estável da Balancer foram amplificados através de trocas em lote de alta frequência, resultando numa drenagem de $70–128 milhões em múltiplas chains. Os atacantes executaram centenas ou milhares de trocas, com cada troca amplificando o erro de arredondamento anterior até que esses pequenos erros se acumulassem numa extração massiva de valor.

Como funcionou:

Os pools estáveis da Balancer usam fórmulas complicadas para manter a estabilidade de preço. Estas fórmulas envolvem arredondamento em múltiplas etapas. Em operação normal, os erros de arredondamento são pequenos. Mas os atacantes encontraram uma forma de estruturar trocas em lote que beneficiavam consistentemente da direção de arredondamento, extraindo valor através de operações repetidas.

Porque é importante (perspetiva de designer de protocolo):

A matemática AMM precisa de estar correta sob condições adversárias. Cada decisão de arredondamento torna-se um vetor de ataque potencial ao lidar com grande capital e a capacidade de executar muitas transações rapidamente. Os designers precisam de pensar de forma adversária: o que acontece se um atacante executar esta operação mil vezes?

O que as auditorias perderam: Os processos de auditoria padrão testaram trocas individuais, não sequências de centenas ou milhares. Os erros de arredondamento foram medidos como menos de 1 wei por troca e tratados como negligenciáveis. Nenhuma invariante foi afirmada sobre N operações repetidas. Fuzzers sem modelação de sequência com estado não conseguiram descobrir isto.

Mitigação: Afirmar invariantes que se mantêm em operações repetidas. Testar com tamanhos de lote adversários. Usar verificação formal para provar que os limites de erro de arredondamento permanecem aceitáveis sob qualquer sequência de operações.

A classe de vulnerabilidade: Erro de precisão matemática em fórmulas AMM.

Análise aprofundada: Balancer DeFi Protocol Suffers Massive Exploit | Balancer Hack Explained with Multi-Chain Details

GMX: Falha de Limite de Sistema ($42M)

9 de julho de 2025

A GMX, um protocolo de negociação de perpétuos que gere milhares de milhões em volume de negociação, foi explorada por $42 milhões. O exploit não veio de um bug na lógica de negociação central. Emergiu nos limites entre componentes: onde os oráculos encontram cálculos de margem, onde a lógica de liquidação interage com infraestrutura de ponte.

Como funcionou:

A vulnerabilidade existia na forma como estes componentes interagiam, não em nenhum componente individual. Quando os oráculos atualizam preços, os requisitos de margem mudam, e a lógica de liquidação responde. O atacante provavelmente encontrou uma forma de manipular estas interações, talvez cronometrando atualizações de oráculos com cálculos de margem. Cerca de $9,6 milhões foram transferidos por ponte para Ethereum imediatamente após o exploit, sugerindo planeamento cuidadoso.

Porque é importante (perspetiva de arquitetura de sistema):

Componentes individuais bem auditados ainda podem falhar quando integrados. A vulnerabilidade não existe em nenhum contrato único. Existe no espaço entre componentes, na forma como comunicam e interagem. À medida que os protocolos se tornam mais complicados e componíveis, a superfície de ataque cresce nos limites dos componentes.

O que as auditorias perderam: Os processos de auditoria tradicionais normalmente focam-se fortemente em componentes isoladamente. Os testes de integração existem, mas podem não cobrir cenários adversários onde um atacante pode cronometrar operações através dos limites dos componentes.

Mitigação: Implementar testes de integração que simulam o comportamento completo do sistema. Usar frameworks de simulação adversária que possam modelar interações entre componentes. Testar ataques de temporização onde as operações são sequenciadas para explorar interações de componentes.

A classe de vulnerabilidade: Falha de integração de sistema.

Análise aprofundada: GMX Exploit Coverage

Cork Protocol: Gestão de Derivados de Staking Líquido ($12M)

28 de maio de 2025

O Cork Protocol perdeu cerca de 3.761 wstETH (no valor de aproximadamente $12 milhões) devido a uma vulnerabilidade na forma como geria derivados de staking líquido. Derivados de staking líquido como stETH, wstETH e osETH introduzem mudanças de estado ocultas. A taxa de câmbio entre wstETH e ETH muda ao longo do tempo à medida que as recompensas de staking se acumulam.

Como funcionou:

O exploit envolveu uma incompatibilidade entre a forma como o Cork Protocol modelou a acumulação de valor do wstETH e como realmente funciona. O protocolo provavelmente assumiu uma relação estática 1:1 que não se mantém. Um atacante podia depositar wstETH quando a taxa de câmbio é favorável, esperar que acumule valor, depois levantar mais do que deveria ser capaz de.

Porque é importante (perspetiva organizacional):

Isto destaca uma lacuna de conhecimento organizacional. Muitas equipas de desenvolvimento tratam todos os tokens ERC-20 da mesma forma, mas os derivados de staking líquido funcionam de forma diferente. Isto não é apenas um problema de código. É um problema de gestão de conhecimento. As equipas precisam de processos para identificar e documentar comportamentos específicos de tokens antes da integração.

Mitigação: Usar sempre as funções de taxa de câmbio do token (por exemplo, wstETH.getStETHByWstETH()). Nunca assumir uma relação 1:1. Contabilizar a acumulação de valor ao longo do tempo em quaisquer cálculos envolvendo LSDs.

A classe de vulnerabilidade: Incompreensão da mecânica de tokens.

Análise aprofundada: Cork Protocol Hacked for $12M, Smart Contracts Paused

Casos Limite Interessantes

Estes hacks revelam lições mais restritas mas ainda instrutivas sobre classes específicas de vulnerabilidade.

Bunni: Acumulação de Erro de Precisão ($2,4–8,3M)

2 de setembro de 2025

Bunni, um protocolo de liquidez concentrada, foi explorado através de um bug de precisão/arredondamento no seu sistema de contabilidade LP. A perda exata varia por fonte ($2,4M inicialmente reportados, análise posterior sugere até $8,3M).

Como funcionou:

O atacante encontrou uma forma de fazer depósitos e levantamentos repetidos que exploravam o arredondamento a seu favor. Cada operação extraía uma quantidade minúscula, mas ao longo de muitas operações, essas quantidades minúsculas somavam-se a milhões.

Porque é importante (perspetiva de metodologia de teste):

A maioria dos conjuntos de testes modelam operações únicas, não sequências de operações. Um teste pode verificar que um único depósito calcula participações corretamente, mas não irá detetar erros de precisão que só aparecem após dezenas de operações. Fuzzers que não modelam sequências com estado perdem estas questões.

Mitigação: Usar bibliotecas matemáticas estabelecidas (por exemplo, PRBMath, ABDKMath). Testar sequências de operações, não apenas operações únicas. Considerar usar maior precisão internamente mesmo que as interfaces externas usem precisão padrão.

A classe de vulnerabilidade: Erro de precisão/arredondamento na contabilidade LP.

Análise aprofundada: Bunni V2 Exploit: $8.3M Drained

Garden Finance: Padrão de Ataque Multi-Chain ($5,5M)

30 de outubro de 2025

A Garden Finance foi explorada por $5,5 milhões ou mais em múltiplas chains. O atacante explorou numa chain, depois usou pontes cross-chain para mover ativos roubados para outras chains, trocando-os através de diferentes DEXs para obscurecer o rasto.

Porque é importante (perspetiva de modelação de ameaças):

Implementações multi-chain criam novas superfícies de ataque. Os modelos de ameaça precisam de contabilizar vetores de ataque cross-chain. Os atacantes podem explorar o seu protocolo numa chain, depois usar infraestrutura cross-chain para escapar ou obscurecer os seus rastos.

Mitigação: Desenhar modelos de ameaça que incluam vetores de ataque cross-chain. Compreender como as pontes funcionam e os seus pressupostos de segurança. Considerar implementar monitorização e alertas cross-chain.

A classe de vulnerabilidade: Padrão de ataque multi-chain.

Análise aprofundada: Garden Finance Breach Coverage

Nemo Protocol: Quando Linguagens "Seguras" Não São Suficientes ($2,4M)

8 de setembro de 2025

O Nemo Protocol em Sui foi explorado por $2,4M. O atacante transferiu USDC roubado via Circle do Arbitrum para Ethereum. O exploit aconteceu apesar das características de segurança do Move.

Porque é importante (perspetiva de ferramentas):

O sistema de tipos do Move previne certos bugs, mas não aborda uma classe inteira de vulnerabilidades ao nível do protocolo. Se a lógica económica do seu protocolo tem falhas, se o seu controlo de acesso é fraco, se a sua integração de oráculo é vulnerável, o sistema de tipos do Move não ajuda.

A classe de vulnerabilidade: Erro de lógica económica em ecossistema não-EVM.

Análise aprofundada: Nemo Protocol Exploit Details

O Resto: Falhas Operacionais

Vários outros hacks em 2025 representam falhas operacionais diretas em vez de vulnerabilidades técnicas novas:

• Unleash Protocol ($3,9M, 30 de dezembro): Drenagem não autorizada, provavelmente permissões comprometidas
• ArcadiaFi ($2,5M, 15 de julho): Abuso de allowance/aprovação na chain Base
• NewGoldProtocol ($2M, 18 de setembro): Exploit de token, fundos encaminhados através do Tornado Cash
• SuperRare ($730K, 28 de julho): Exploit de plataforma NFT
• USPD ($1M, 5 de dezembro): Exploit de aprovação de token
• 402bridge ($17K, 28 de outubro): Pequeno exploit de ponte

Estes incidentes seguem padrões bem conhecidos: chaves de administrador comprometidas, aprovações excessivas de tokens e falhas de controlo de acesso. As soluções são conhecidas: usar multisig para funções de administrador, implementar controlos de acesso adequados, monitorizar aprovações excessivas.

Resumo

Ao observar os hacks de 2025, emergem vários padrões. A correção económica importa tanto quanto a segurança do código. A criação infinita da Yearn e os erros de arredondamento da Balancer mostram que os protocolos precisam de verificação formal dos seus modelos económicos, não apenas auditorias de código. Os limites do sistema escondem complexidade. O exploit da GMX demonstra que componentes bem auditados ainda podem falhar quando integrados. Os testes de integração e a simulação adversária são essenciais.

A precisão e o arredondamento permanecem perigosos. O exploit da Bunni é um lembrete de que as vulnerabilidades aritméticas de ponto fixo persistem. Testar sequências de operação, não apenas operações únicas. O cross-chain cria novas superfícies de ataque. A Garden Finance e o Nemo Protocol mostram que as implementações multi-chain requerem modelos de segurança que contabilizem vetores de ataque cross-chain. A segurança da linguagem não elimina bugs económicos. O Nemo Protocol demonstra que linguagens type-safe previnem certos bugs mas não abordam erros de lógica económica. Os contratos legados são riscos contínuos. Os exploits de dezembro da Yearn mostram que contratos descontinuados permanecem vulneráveis, e um exploit pode chamar a atenção para infraestrutura legada. Ter estratégias de descontinuação claras e monitorização contínua.

Gostou deste artigo? Clique em seguir para se manter atualizado.

Audited, Tested, and Still Broken: Smart Contract Hacks of 2025 foi originalmente publicado em Coinmonks no Medium, onde as pessoas continuam a conversa destacando e respondendo a esta história.