Porque é que as pontes cripto continuam a ser atacadas em 2026: chaves de validadores, mensagens falsificadas e tokens wrapped sem cobertura
As pontes cross-chain resolvem um problema básico no setor cripto: os ativos e as informações criados numa blockchain normalmente não podem ser transferidos diretamente para outra. Uma ponte cria essa ligação ao bloquear, libertar, emitir ou destruir ativos de acordo com mensagens recebidas de outra rede. Essa conveniência também gera um risco de segurança concentrado. Um atacante nem sempre precisa de comprometer a Ethereum, a Arbitrum, uma cadeia Cosmos ou outra blockchain subjacente. Pode ser suficiente comprometer o sistema mais pequeno que informa a ponte sobre o que aconteceu noutra rede. Os incidentes registados durante 2026 mostram que o ponto mais fraco pode ser uma chave de validador, um serviço off-chain que prepara mensagens, um componente de verificação de provas ou um contrato que emite ativos wrapped. O resultado costuma ser semelhante: a ponte aceita um evento que nunca deveria ter sido autorizado e liberta valor real com base nessa informação. Casos recentes envolvendo AFX Trade, Alephium, Hyperbridge e a ligação da Axelar à Secret Network mostram porque é que a segurança das pontes continua a depender tanto dos controlos operacionais e da validação de mensagens como do próprio código dos smart contracts.
Porque é que as pontes cross-chain continuam a ser alvos valiosos em 2026
Uma ponte funciona, na prática, entre sistemas de contabilidade separados. Se um utilizador envia um ativo da Chain A para a Chain B, o ativo original pode ficar bloqueado num contrato na Chain A enquanto uma representação correspondente é emitida na Chain B. Quando o utilizador regressa, a versão wrapped é destruída e o ativo original é libertado. Outros modelos usam pools de liquidez, emissão nativa ou sistemas especializados de mensagens, mas todos têm de responder à mesma questão: como pode uma blockchain aceitar de forma segura informações sobre um evento ocorrido noutra rede? As blockchains são eficazes a verificar o seu próprio estado. Não sabem automaticamente se um depósito, uma destruição de tokens ou um levantamento realmente aconteceu noutra rede.
Isso torna as pontes especialmente atrativas para atacantes, porque uma única falha bem-sucedida pode dar acesso a reservas agregadas, e não apenas à carteira de um utilizador. Uma ponte pode manter stablecoins, Ether, ativos respaldados por Bitcoin e outros tokens em nome de milhares de utilizadores. O valor concentrado em custódia pode, portanto, tornar-se muito superior ao valor económico que protege um único validador, servidor ou chave administrativa. Mesmo quando os smart contracts foram auditados, um atacante pode procurar vulnerabilidades fora do próprio contrato: infraestrutura de validadores, sistemas de implementação, ligações RPC, relayers, permissões de atualização, contas cloud ou o software utilizado para construir mensagens cross-chain.
Esse padrão continuou visível ao longo de 2026. Em 22 de julho, a ponte própria da AFX Trade foi drenada em aproximadamente 24,15 milhões de dólares em USDC depois de terem sido comprometidas chaves de assinatura de validadores em número suficiente para atingir o limite exigido para levantamentos. Em 27 de agosto, a SKALE informou que fornecedores de infraestrutura que operavam nós validadores tinham sido comprometidos antes de um ataque à sua IMA Bridge no lado da Ethereum. Estes incidentes não exigiram que o atacante derrotasse o mecanismo de consenso das blockchains subjacentes. O alvo foram os sistemas de confiança mais pequenos colocados entre as redes, nos quais o controlo de um número limitado de máquinas ou credenciais podia transformar-se em autoridade sobre reservas muito maiores.
O problema de confiança por detrás das transferências cross-chain
A palavra “ponte” pode fazer com que as transferências cross-chain pareçam uma simples movimentação de uma rede para outra, mas os ativos geralmente não viajam literalmente entre blockchains. Em vez disso, um sistema prova ou confirma que algo aconteceu na rede de origem, e outro sistema altera os saldos na rede de destino em resposta. Dependendo da arquitetura, essa prova pode vir de um grupo de validadores, de um conjunto de guardians, de um mecanismo light client, de uma prova criptográfica ou de outro processo de verificação. Os utilizadores dependem, portanto, não apenas da segurança das duas blockchains, mas também da integridade do mecanismo que as liga.
Esta distinção é importante porque uma transação pode ser criptograficamente válida e, ainda assim, ser economicamente fraudulenta. Imagine que uma ponte exige cinco assinaturas aprovadas antes de libertar USDC. Se um atacante obtiver cinco chaves de assinatura legítimas, o levantamento final pode conter assinaturas perfeitamente válidas. O contrato não tem uma forma independente de perceber que essas assinaturas foram produzidas por um atacante. Do seu ponto de vista, os validadores necessários aprovaram o pedido. A criptografia funciona exatamente como previsto, mas a premissa de segurança por detrás das assinaturas já falhou.
Um problema semelhante surge quando os signatários legítimos recebem informações incorretas. Os validadores podem assinar honestamente uma mensagem porque a infraestrutura que lhes fornece dados reporta um depósito ou uma destruição de tokens que nunca aconteceu. Esta é uma das razões pelas quais a segurança de uma ponte não pode ser reduzida à simples questão de saber se as chaves privadas foram roubadas. Os programadores também precisam de considerar de onde os validadores recebem os dados, se várias fontes independentes confirmam o mesmo evento, como mensagens invulgares são detetadas e o que acontece quando surge repentinamente um levantamento de grande dimensão. A ponte é tão fiável quanto todo o percurso entre o evento original na blockchain e a libertação final dos fundos.
Chaves de validadores e mensagens falsificadas: como os ataques contornam as verificações normais
As chaves de validadores são particularmente perigosas quando várias delas estão armazenadas em ambientes semelhantes ou controladas pela mesma organização. Um sistema de assinaturas por limiar pode parecer descentralizado porque exige cinco, sete ou dez assinaturas, mas a proteção real depende de essas credenciais poderem falhar de forma verdadeiramente independente. Se várias chaves estiverem alojadas em servidores hot semelhantes, partilharem as mesmas ferramentas de administração ou puderem ser alcançadas através da mesma rede interna, comprometer um único ambiente operacional pode dar ao atacante assinaturas suficientes para atingir o quórum exigido. O número de chaves importa menos quando todas estão expostas ao mesmo vetor de ataque.
O incidente da AFX Trade em julho de 2026 demonstra claramente este problema. A análise de segurança do caso concluiu que cinco assinaturas de validadores hot eram suficientes para aprovar um levantamento de aproximadamente 24,15 milhões de USDC. O contrato da ponte reconheceu o quórum necessário e processou o pedido após o período de disputa. A ponte nativa da Arbitrum não foi o componente que falhou; a ponte afetada era operada pela AFX. Esta distinção é importante porque os utilizadores muitas vezes veem ativos a mover-se entre duas redes conhecidas e assumem que a segurança da transferência é diretamente herdada dessas blockchains. Na realidade, uma ponte separada pode introduzir o seu próprio conjunto de validadores, as suas próprias premissas de custódia e as suas próprias fragilidades administrativas.
O roubo de chaves é apenas uma das formas de produzir uma mensagem aparentemente válida. Uma ponte também pode ser levada a aceitar informação falsa sem que nenhuma chave privada de signatário seja roubada. Um atacante pode manipular os dados fornecidos aos validadores, explorar um erro de verificação, criar uma prova que um contrato aceite incorretamente ou aproveitar uma ambiguidade entre a forma como dois componentes de software interpretam a mesma transação. Estes ataques são particularmente difíceis de diagnosticar rapidamente porque a mensagem final pode conter assinaturas genuínas ou passar pelas funções de verificação esperadas. Os investigadores precisam então de recuar pelo fluxo de relayers, dados RPC, geração de provas e construção de mensagens para determinar onde o estado falso entrou pela primeira vez no processo.
O que mostram os incidentes de 2026
O incidente da ponte Alephium em 30 de maio de 2026 é um exemplo útil porque, à primeira vista, o ataque poderia sugerir o roubo de credenciais dos guardians. Mais tarde, a Alephium afirmou que as chaves dos guardians não tinham sido comprometidas. Segundo o seu post-mortem, o atacante combinou uma validação em falta num processo off-chain de re-observation com um ataque de tipo eclipse contra full nodes da ponte. Isso levou guardians legítimos a assinar mensagens que eram criptograficamente genuínas, mas que nunca deveriam ter sido autorizadas. Cerca de 305 mil dólares em colateral foram retirados de contratos TokenBridge na Ethereum e na BNB Chain, enquanto aproximadamente 13,76 milhões de wALPH sem cobertura foram emitidos na Ethereum.
A Hyperbridge sofreu um tipo diferente de falha de verificação em 13 de abril de 2026. O seu post-mortem afirma que um atacante explorou uma vulnerabilidade crítica no verificador Merkle Mountain Range e falsificou uma prova que o sistema acabou por aceitar. O atacante conseguiu então drenar o contrato Token Gateway. Este caso não dependeu de reunir chaves de validadores roubadas em número suficiente. O problema estava no componente responsável por decidir se uma prova cross-chain era válida, que chegou à resposta errada. A Hyperbridge suspendeu o gateway afetado e posteriormente contratou uma auditoria independente ao sistema de verificação e liquidação, mostrando porque é que as análises de segurança das pontes precisam de abranger muito mais do que apenas os contratos de tokens mais visíveis.
Estes casos mostram porque a expressão “mensagem falsificada” pode descrever falhas muito diferentes. Um ataque pode envolver chaves roubadas que assinam efetivamente um levantamento malicioso. Outro pode fornecer dados falsos a signatários honestos. Um terceiro pode explorar um verificador para que evidências fabricadas sejam aceites sem qualquer comprometimento de validadores. Do ponto de vista do utilizador, os três cenários podem terminar com o desaparecimento de ativos de um contrato de reservas. Do ponto de vista da segurança, porém, exigem defesas diferentes. O armazenamento protegido por hardware não corrige um verificador de provas defeituoso, enquanto um verificador perfeito não protege um sistema cujas credenciais de administrador ou de validador foram roubadas. A segurança eficaz de uma ponte exige, portanto, vários controlos independentes em vez de um único ponto de confiança.
Tokens wrapped sem cobertura e o problema da liquidez
Os tokens wrapped acrescentam outra camada de risco porque o seu valor de mercado depende da premissa de que podem ser resgatados por algo real. Se um wrapped ETH representar um direito sobre um ETH mantido noutra parte do sistema, o equilíbrio só é preservado enquanto a quantidade emitida corresponder aos ativos que lhe servem de cobertura. Quando uma vulnerabilidade numa ponte permite que um atacante emita tokens wrapped adicionais sem depositar o colateral correspondente, esses novos tokens podem parecer inicialmente idênticos às unidades legitimamente garantidas. Podem ser transferidos, trocados ou fornecidos a outros serviços DeFi antes de o mercado perceber que o total de direitos emitidos já ultrapassa as reservas disponíveis.
O incidente de junho de 2026 envolvendo a ligação da Axelar à Secret Network oferece um exemplo concreto. A análise de segurança concluiu que um contrato de ponte modificado aceitava depósitos IBC sem validar corretamente o canal de origem esperado. Um atacante podia criar uma cadeia separada baseada em Cosmos, enviar pacotes de depósito manipulados e fazer com que ativos wrapped fossem emitidos na Secret Network sem os depósitos legítimos correspondentes. Esses ativos sem cobertura eram depois encaminhados através da ligação válida da Axelar e resgatados por tokens reais mantidos em custódia. Foram retirados aproximadamente 4,67 milhões de dólares, e a insuficiência das reservas não foi descoberta de imediato; segundo os relatos do incidente, o problema tornou-se evidente dias depois, quando uma transferência cross-chain normal já não pôde ser concluída porque as reservas tinham sido esgotadas.
Este tipo de falha é especialmente prejudicial porque pode espalhar-se para além da própria ponte. Quando um ativo wrapped sem cobertura entra numa exchange descentralizada, num mercado de empréstimos ou num pool de liquidez, outros utilizadores podem, sem saber, trocar ativos reais por direitos que deixaram de estar totalmente garantidos. Os smart contracts automatizados normalmente não sabem porque foram emitidos tokens adicionais. Apenas leem saldos e seguem as regras programadas. Uma falha de segurança numa única ponte pode, assim, transferir perdas para fornecedores de liquidez, traders ou serviços DeFi ligados. Quando a ponte afetada é finalmente suspensa, o atacante pode já ter convertido os direitos falsos em stablecoins ou noutros ativos com elevada liquidez.
Como uma arquitetura de ponte mais segura pode reduzir os danos
A primeira linha de defesa consiste em reduzir o nível de autoridade que qualquer credencial ou sistema isolado pode exercer. As chaves de validadores devem ser distribuídas por ambientes realmente independentes, em vez de serem apenas representadas por endereços diferentes. Atualizações administrativas podem ser protegidas por aprovação multisig, timelocks e permissões estritamente limitadas. Levantamentos grandes ou invulgares podem enfrentar períodos de contestação mais longos, enquanto limites de velocidade podem restringir a quantidade de valor que sai de uma ponte num curto período. Nenhum destes controlos garante, por si só, que um ataque será evitado, mas pode impedir que uma única conta comprometida ou uma única mensagem inesperada esvazie imediatamente todas as reservas.
A verificação de mensagens também precisa de controlos independentes em várias fases. Uma ponte deve confirmar a rede de origem, o contrato, o ativo, o montante, o destino e a sequência da mensagem, em vez de tratar uma assinatura válida como prova de que todos os campos estão corretos. Sistemas que dependem de observadores off-chain precisam de considerar o que acontece quando esses observadores recebem respostas RPC manipuladas ou perdem uma visão correta da rede de origem. O fornecimento de tokens wrapped deve ser comparado continuamente com as reservas que lhes dão cobertura, para que um aumento sem explicação possa acionar um alerta ou uma suspensão automática. A monitorização é mais útil quando verifica invariantes económicos, como a correspondência entre os direitos emitidos e o colateral disponível, em vez de procurar apenas transações que falharam.
A principal lição de 2026 é que os ataques a pontes já não podem ser explicados adequadamente dizendo apenas que “o smart contract foi atacado”. Em vários incidentes relevantes, a fraqueza decisiva estava noutro ponto: credenciais de validadores, infraestrutura que fornecia dados aos guardians, validação do canal de origem ou verificação de provas. Uma arquitetura segura deve, por isso, partir do princípio de que componentes individuais podem falhar e impedir que uma única falha se transforme num direito irrestrito sobre as reservas da ponte. Os utilizadores que avaliam uma ponte devem olhar para além da velocidade das transações e das redes suportadas e considerar quem controla os signatários, como as mensagens são verificadas, se os ativos wrapped podem ser comparados de forma independente com as reservas, com que rapidez uma atividade anormal pode ser travada e que processo de recuperação existe caso esses controlos falhem.
