A GalaChain corrigiu duas falhas exploradas em 18 de agosto. Na ocasião, um invasor drenou cerca de 2 bilhões de GALA, avaliados em aproximadamente US$ 3 milhões. O ataque também atingiu dezenas de outros tokens distribuídos entre nove carteiras.

Segundo a empresa, o invasor reutilizou assinaturas históricas de transações que haviam falhado. Em 14 de setembro, o relatório pós-incidente descreveu uma operação preparada antes da primeira transferência não autorizada. Durante o ataque, a companhia interrompeu sua ponte entre redes e, posteriormente, corrigiu os dois mecanismos vulneráveis.

Assinaturas antigas permitiram transferências indevidas

Inicialmente, o invasor reuniu 74 assinaturas reutilizáveis de transações malsucedidas registradas até 55 dias antes do ataque. Além disso, ele demonstrou conhecimento detalhado sobre as contas afetadas. Entre 59 combinações de conta e token visadas, 56 perderam o saldo exato na primeira tentativa.

Em seguida, as quatro maiores posições em GALA saíram em ordem decrescente durante um intervalo de apenas 18 segundos. Portanto, o padrão indica que o agente mapeou os saldos antes de executar o ataque. A GalaChain registrou 1.066 envios, com intervalo mediano de 4,5 segundos, enquanto 73,9% chegaram com um bloco de diferença.

A brecha nas assinaturas surgiu da forma como a rede verificava dados tipados no padrão EIP-712. Antes da correção, o verificador aceitava definições de tipo enviadas na solicitação, em vez de derivá-las da operação chamada. Assim, uma assinatura para determinados campos podia acompanhar outro método, que utilizava dados adicionais sem autorização explícita do titular.

Um exemplo on-chain mostra uma chamada TransferToken que movimentou cerca de 1,64 bilhão de GALA. Entretanto, a estrutura EIP-712 apresentada na verificação descrevia uma operação AddLiquidity. Por isso, o destino, a quantidade e a instância usada na transferência ficaram fora da estrutura assinada.

Gala afirma que chaves privadas permaneceram seguras

A assinatura mantinha validade criptográfica, mas o sistema não confirmava a autorização do titular para o efeito econômico da execução. A Gala afirmou que não encontrou indícios de comprometimento de chaves privadas, frases-semente ou senhas dos usuários afetados. Ainda assim, a conclusão depende de evidências internas que a empresa não divulgou.

Por sua vez, uma segunda falha ampliou o conjunto de assinaturas disponível para o invasor. Até então, a GalaChain atribuía chaves únicas às transações para bloquear o reenvio de uma mesma carga assinada. Quando uma operação falhava, porém, o sistema podia reverter essa chave com as alterações de estado malsucedidas.

Como resultado, a assinatura permanecia visível no livro-razão público, enquanto a chave de repetição continuava disponível. Conforme a empresa, 57 das 60 transações históricas ligadas ao ataque continham ao menos uma operação interna com falha. Embora permanecessem registradas, nenhuma dessas transações chegou ao fim com sucesso integral.

Auditorias não detectaram a combinação das brechas

A lógica vulnerável passou por revisões externas de segurança antes do ataque. Segundo a companhia, a CertiK examinou o mecanismo em uma análise de autorização no fim de 2025. Porém, uma revisão do SDK feita pela Hashlock em janeiro também não identificou o problema no escopo das assinaturas.

A companhia não publicou os relatórios dessas auditorias. Dessa maneira, não é possível determinar os testes realizados ou a profundidade da análise sobre a interação entre os mecanismos. Ao mesmo tempo, a própria proteção contra repetição surgiu após uma descoberta anterior da CertiK.

Depois do incidente, a GalaChain passou a derivar as informações de tipo diretamente da operação executada. Agora, identificadores vinculam cada assinatura ao canal, ao contrato e ao método autorizados. Adicionalmente, prazos de expiração limitam a validade das cargas assinadas.

Com a correção, o mecanismo preserva a chave única mesmo quando a operação de negócio falha. Desse modo, uma solicitação histórica não permanece disponível para outra tentativa. A companhia detalhou as mudanças no relatório pós-incidente da Gala.

Automação ampliou o desafio da resposta humana

A primeira transferência não autorizada confirmada ocorreu às 02h21min54s UTC. Cerca de duas horas e 47 minutos depois, às 05h09min19s UTC, a Gala interrompeu a ponte. Logo depois, às 05h22, a empresa começou a remover funções do endereço recebedor.

Após a pausa, a ponte rejeitou tentativas de retirada dos recursos. Mesmo assim, a cronologia expõe a diferença entre envios automatizados e decisões humanas de detecção, investigação e resposta. Desde então, a rede adotou limites por identidade, monitoramento comportamental e revisão adicional para retiradas acima de determinados valores.

A Gala também classificou o invasor como usuário de ferramentas assistidas por inteligência artificial. Contudo, essa avaliação depende de evidências internas que a empresa não tornou públicas. Paralelamente, a companhia apresentou uma denúncia ao Internet Crime Complaint Center do FBI.

A empresa também enviou pedidos de preservação e congelamento às plataformas envolvidas. Enquanto rastreia os recursos em quatro redes, a Gala mantém as medidas adicionais de segurança. Assim, o caso destaca a importância de auditorias conjuntas sobre assinaturas, proteção contra repetição e execução de transações.

	Receba nossas últimas notícias em primeira mão.  Adicione-nos como sua fonte preferida no Google  e toque em “Favorito” para priorizar nossas atualizações.