Os hacks de 2026 já não atacam o contrato, mas sim o perímetro

Nos quatro maiores roubos de DeFi de 2026, o contrato inteligente auditado não falhou uma única vez. Caíram a configuração de uma ponte, os nodos que alimentavam um verificador, os agentes de IA com permissões de transferência e a cadeia de ferramentas do desenvolvedor. O código que custodia o dinheiro — aquele que é auditado, publicado e revisado linha por linha — resistiu; o que cedeu foi o perímetro que o rodeia: a infraestrutura. Abril de 2026 foi o pior mês da história do DeFi, com 606 milhões de dólares roubados, e quase todo esse dinheiro saiu pela porta de serviço, não pela fechadura blindada da entrada. Este artigo defende uma tese: em 2026, o locus do ataque deslocou-se para fora do contrato. Argumentamos isso com os incidentes públicos do ano, explicamos por que o perímetro é estruturalmente mais frágil que o código auditado e encerramos com o que isso muda para protocolos e usuários. Não é um manual de como atacar nada — é a leitura do padrão e da defesa.

Por que o contrato inteligente deixou de ser o objetivo?

Durante anos, a imagem mental do hack de DeFi foi a do exploit de contrato: uma falha de reentrancy, uma manipulação de oráculo, uma função de retirada mal protegida. O atacante lia o código público, encontrava a brecha matemática e esvaziava o pool em um bloco. A indústria respondeu com a maquinaria que hoje define um protocolo sério: auditorias múltiplas, verificação formal, bug bounties de sete dígitos (Aave paga até 1 milhão de dólares na Immunefi por uma falha crítica) e bibliotecas padrão revisadas por milhares de olhos. O contrato tornou-se a parte mais cara de atacar em todo o sistema.

E precisamente por isso deixou de ser o objetivo rentável. A lógica é a de qualquer atacante racional: não se entra pela porta blindada quando a janela do banheiro está aberta. Um contrato auditado é um código quase imutável, público, escrutinado por defensores que passam anos fechando essa classe específica de falhas. O perímetro que o rodeia — o editor do desenvolvedor, o pipeline de implantação, os nodos RPC (os servidores que fornecem o estado da rede às aplicações) que alimentam uma ponte, os agentes de IA com permissões para mover fundos — não possui nem um décimo desse escrutínio. Muda diariamente, é mantido por pessoas com pressa e quase ninguém o audita com o rigor aplicado a uma função de Solidity.

Os dados confirmam isso. Segundo a TRM Labs, 76% de todo o valor roubado em cripto em 2026 foi concentrado pelo Lazarus Group da Coreia do Norte em apenas duas operações. Nenhuma das duas foi um exploit de lógica de contrato: uma atacou a configuração de uma ponte, a outra envolveu meses de engenharia social contra operadores humanos. O dinheiro grande de 2026 não entrou pelo código. Entrou por todo o resto.

Quais são os quatro vetores de perímetro de 2026?

A tese não se sustenta com um caso isolado, mas com o padrão. Quatro incidentes públicos de 2026, cada um atacando uma camada diferente do perímetro, desenham o mesmo deslocamento. Em nenhum falhou a lógica do contrato; nos quatro, falhou a infraestrutura que o envolve.

Convém ler a tabela como um mapa, não como uma lista de eventos. Cada linha é uma camada da pilha que um protocolo precisa para funcionar, mas que não aparece em seu relatório de auditoria. O contrato é a única peça que esses relatórios cobrem — e é a única que resistiu nos quatro casos.

Como a Kelp DAO caiu sem tocar em um contrato?

Em 18 de abril de 2026, a Kelp DAO perdeu 292 milhões de dólares através de sua ponte sobre a LayerZero. Não houve bug em Solidity. A ponte operava com uma configuração DVN (a rede de verificadores que aprova as mensagens entre cadeias) em modo "1 de 1": um único verificador validava as mensagens cross-chain, sem redundância. O atacante envenenou os nodos RPC que esse verificador consultava para ler o estado da cadeia de origem e, em paralelo, lançou um DDoS (saturação de tráfego) contra essa infraestrutura. Com o verificador lendo um estado manipulado, fabricou uma mensagem falsa que ordenou à ponte liberar 116.500 rsETH na Ethereum sem que existisse o burn correspondente na origem.

O que é devastador no caso é que o aviso já existia. A LayerZero havia sinalizado o risco da configuração 1-de-1 antes do hack; cerca de 47% das aplicações sobre a LayerZero usavam esse mesmo padrão. A Kelp custodiava bilhões e nunca reforçou a segurança além da configuração padrão. O contrato da ponte fez exatamente o que estava programado para fazer — o problema era a infraestrutura que decidia quais mensagens eram legítimas. A onda de choque atingiu mais de vinte protocolos conectados e disparou mais de 10 bilhões de dólares em saídas da Aave, embora os contratos da Aave também não tenham sido explorados: simplesmente ficaram com colateral em disputa. Analisamos isso em detalhes em como roubaram 292 milhões da Kelp DAO sem tocar em um contrato.

Por que um agente de IA com permissões é uma bomba?

A Step Finance, um gestor de portfólios de DeFi na Solana, foi drenada em janeiro de 2026 e acabou encerrando as atividades em 24 de fevereiro. O valor gira em torno de 27 milhões de dólares (261.854 SOL em uma única transação; alguns relatórios elevam para 40 milhões contando o colapso de 97% do seu token). O vetor inicial foi humano e clássico: comprometer os dispositivos dos executivos do projeto para obter suas chaves. Mas o amplificador foi novo.

A Step Finance havia integrado agentes de IA com permissão para executar transferências grandes de SOL sem aprovação humana. Uma vez dentro, os atacantes não precisaram mover o dinheiro manualmente: usaram os próprios agentes do protocolo — com suas permissões excessivas e sem isolamento — como alavanca para retirar os fundos. A falha não foi o contrato nem o modelo de IA em si, mas a automação com permissões: uma identidade de máquina capaz de mover valor sem um humano no processo transforma um comprometimento de credenciais em uma drenagem instantânea. É o mesmo princípio que, na segurança tradicional, torna perigoso um serviço com privilégios de administrador que ninguém revisa.

O caso semelhante é o da Resolv USR (25 milhões de dólares): uma injeção de prompts em um agente de IA com acesso à nuvem, atacando a camada de ferramentas — MCP, Supabase, chaves gerenciadas no AWS KMS — em vez do contrato. Dois incidentes, dois pontos diferentes da mesma camada nova: a infraestrutura de IA que os protocolos estão conectando às suas operações mais rápido do que conseguem protegê-la. O detalhe da injeção de prompts está em 25 milhões roubados mediante injeção de prompts no MCP.

Como o atacante entra pela cadeia de ferramentas do dev?

O quarto vetor é o mais insidioso porque atua antes mesmo do contrato existir. Em 18 de maio de 2026, o grupo TeamPCP (rastreado como UNC6780) publicou uma versão envenenada da Nx Console, a extensão oficial do VS Code para o monorepo Nx, com 2,2 milhões de instalações. Ficou disponível no Marketplace oficial por menos de 20 minutos — o suficiente para que a atualização automática a enviasse para um número desconhecido de máquinas. O payload, batizado de Mini Shai-Hulud, roubava tokens de CI/CD, autopropagava-se como um verme de npm e varria caminhos de wallets no disco. O GitHub confirmou a exfiltração de cerca de 3.800 de seus repositórios internos.

A inovação assustadora não foi quebrar uma defesa, mas cooptá-la: o verme gerava atestações de procedência SLSA Build Level 3 autênticas para os pacotes maliciosos. Ou seja, a assinatura criptográfica que a indústria construiu após o caso SolarWinds para certificar que um pacote vinha de um pipeline confiável estava correta — só que o pipeline já estava sequestrado. Para um desenvolvedor Web3, isso é crítico: em sua máquina convivem a chave que assina uma implantação de contrato e a seed de uma wallet de tesouraria. Não há departamento de fraude que reverta a transação: se a extensão vaza essa chave e o atacante assina, os fundos se foram. O que revela o incidente é o que conteve o dano — segundo o GitHub, os repositórios de clientes não foram afetados porque o acesso comprometido estava segregado. A disciplina de permissões, não o contrato, foi a última linha de defesa.

Por que o perímetro é mais frágil que o contrato?

A pergunta-chave não é por que os atacantes se moveram para o perímetro, mas por que o perímetro permite isso. A resposta está em uma assimetria estrutural entre duas classes de superfície.

O contrato inteligente possui quatro propriedades que o fortalecem: é público (qualquer um pode auditá-lo), é quase imutável (não muda após a implantação), possui um perímetro delimitado (o conjunto de funções é finito e conhecido) e concentra toda a atenção defensiva do setor. A infraestrutura que o rodeia é exatamente o oposto nas quatro:

• Muda diariamente. Um contrato é auditado uma vez e permanece fixo. A toolchain do desenvolvedor, os nodos RPC, as dependências de npm e a configuração dos agentes sofrem mutações constantes. Cada atualização é uma nova janela, e ninguém reaudita o sistema inteiro a cada mudança.
• É opaca e dispersa. O código do contrato está em um explorador de blocos para o mundo ver. A configuração do DVN de uma ponte, as permissões de um agente de IA ou os tokens que vivem em um pipeline de CI/CD não são publicados nem escrutinados. O padrão vulnerável da Kelp estava lá há meses, avisado, sem que ninguém o alterasse.
• Herda confiança de terceiros. O protocolo não controla o VS Code Marketplace, nem o registro do npm, nem os nodos RPC de um provedor, nem o pipeline da nuvem. Ele confia neles. O TeamPCP não atacou o contrato: atacou o elo de confiança — uma extensão assinada — que o desenvolvedor aceita como legítima.
• Quase ninguém a audita com o mesmo rigor. Existem bug bounties de um milhão de dólares por uma falha de contrato e verificação formal de cada função. Não existe o equivalente para "sua ponte está bem configurada?" ou "o que seu agente de IA pode mover sem um humano presente?". O orçamento de segurança foi gasto na parte que já estava robusta.

A consequência é direta: o custo marginal de encontrar uma falha no perímetro é muito menor do que o de quebrar um contrato auditado, e o prêmio é idêntico — os mesmos fundos. Um atacante racional, e o Lazarus é um deles, vai onde a relação esforço-recompensa é melhor. Em 2026, isso é a infraestrutura.

Isso significa que os exploits de contrato desapareceram?

Não, e a nuance importa para não cair na manchete fácil. As falhas de lógica de contrato — reentrancy, manipulação de oráculos, erros de arredondamento — continuam ocorrendo e continuarão ocorrendo, especialmente em protocolos jovens, não auditados ou com código copiado pela metade. A anatomia dessas falhas não mudou e convém conhecê-la; revisamos isso em a anatomia de uma vulnerabilidade cripto.

O que a tese afirma é algo mais preciso: o dinheiro grande de 2026 deslocou-se para o perímetro. Dos 606 milhões roubados em abril — 3,7 vezes o total de todo o primeiro trimestre —, dois ataques do Lazarus concentraram cerca de 95%, e nenhum foi um exploit de contrato. Quando o código se tornou tão robusto que esvaziar um protocolo sério pela via matemática é caríssimo, os grandes operadores migram para a via barata. Os exploits de contrato não morreram; foram relegados às presas fáceis, enquanto as presas gordas caem pelo perímetro. É uma redistribuição do risco, não uma substituição.

O que muda para os protocolos?

Se o ataque não entra mais pelo contrato, auditar apenas o contrato é defender uma porta blindada com a janela aberta. A defesa desloca-se com o ataque. Para um protocolo, isso implica tratar o perímetro com o mesmo rigor que o código:

1. Auditar a configuração, não apenas o código. O padrão de uma ponte, o modo do DVN, os provedores de RPC e sua redundância fazem parte da superfície de ataque. A Kelp tinha o contrato correto e a ponte em "1 de 1": a auditoria que importava era a da configuração, e não foi feita.
2. Permissões mínimas nos agentes de IA. Nenhuma identidade de máquina deveria poder mover valor sem um humano no processo ou sem limites estritos. Um agente com permissão de transferência ilimitada é, na prática, uma chave privada com vontade própria. A lição da Step Finance é exatamente essa.
3. Segregar credenciais por raio de explosão. O token que constrói não deve ser o que publica; a chave que testa não deve ser a que implanta em produção. No caso TeamPCP, os repositórios de clientes do GitHub foram salvos precisamente porque o acesso comprometido não os alcançava: a segregação conteve o dano.
4. Reforçar a toolchain do desenvolvedor. Atualizações manuais e revisadas em máquinas que tocam em chaves, ceticismo diante da procedência assinada (já não basta como garantia), e nunca deixar seeds de produção ao alcance da sessão de um editor.
5. Não ignorar os avisos que já possui. A LayerZero avisou a Kelp. O padrão vulnerável estava documentado. A defesa do perímetro começa por agir sobre o risco conhecido antes de buscar o desconhecido.

A diferença fundamental sobre quem executa o ataque tratamos à parte: se você se pergunta se a IA já é o atacante autônomo que esvazia protocolos, a resposta e os dados estão em o alarme da OpenZeppelin sobre a IA "super-humana". Aquele artigo fala sobre quem ataca; este, sobre qual parte é atacada. São complementares: em 1 de junho de 2026, o atacante continua sendo humano e o alvo moveu-se para o perímetro.

Quais sinais um usuário deveria observar?

O usuário de DeFi não audita pontes nem configura agentes, mas sua exposição depende de decisões de perímetro que ele pode avaliar antes de depositar. Quatro sinais práticos:

• Risco de ponte herdado. Qualquer token "wrapped" ou bridgeado herda o risco da infraestrutura da ponte, não do contrato que o emite. Se você possui ativos cross-chain, convém saber qual ponte os respalda e em qual configuração. Para comparar as arquiteturas de verificação das grandes pontes antes de mover fundos, o comparador de LayerZero, Wormhole e Axelar ajuda a ver as diferenças de relance.
• Concentração em um único provedor. Ter toda a exposição cross-chain sob um único provedor de ponte é replicar o ponto único de falha que afundou a Kelp. Diversificar reduz o raio de explosão também para o usuário.
• Colateral com respaldo em disputa. Se você usa um ativo bridgeado como colateral em lending, sua posição depende de que esse respaldo continue sendo válido. Quando a ponte que o emite sofre um incidente, o Health Factor pode se deteriorar sem que você faça nada.
• Maturidade do perímetro, não apenas das auditorias. Um selo de auditoria cobre o contrato. Perguntar se o protocolo publica sua configuração de pontes, como gerencia as permissões de suas automações e como segrega credenciais diz mais sobre seu risco real em 2026 do que o número de auditorias do contrato.

A lição transversal é incômoda, mas clara: em 2026, ler apenas o relatório de auditoria do contrato é ler a parte que já está resolvida. O risco vive na margem não auditada. O contrato é analisado uma vez e é público; o perímetro muda a cada dia e quase ninguém o vigia — e é aí que, golpe a golpe, o dinheiro grande está caindo. Monitorar suas posições e a saúde do seu portfólio serve precisamente para detectar cedo quando um incidente de perímetro começa a contaminar os ativos que você toca.

Fontes e links: TRM Labs (atribuição e % roubado 2026) · BeInCrypto (606 M$ em abril, 3,7x Q1) · CoinDesk (encerramento da Step Finance) · Halborn (análise Step Finance) · CISA (alerta TeamPCP / Nx Console) · Chainalysis (atribuição Lazarus)