O patch que tentou corrigir uma falha e acabou causando o hackeio de 4.000 BTC
Um patch de 2026 criado para corrigir um erro de 2018 abriu, de fato, a porta para o roubo de 4.000 BTC na Liquid: a correção foi a falha.
Steven Roose, ex-engenheiro da equipe da Liquid na Blockstream e atual CEO da Second, publicou uma análise técnica que reconstrói, transação por transação, como um atacante conseguiu inflar quase 4.000 bitcoin (BTC) na rede Liquid no dia 6 de setembro passado.
Sua conclusão central contraria a leitura mais aceita do incidente: a criptografia das transações confidenciais da Liquid nunca falhou. O que falhou foi uma decisão de engenharia tomada oito anos antes, e a tentativa mal-sucedida de corrigi-la apenas dias antes do roubo.
O achado tem uma particularidade desconfortável para qualquer equipe que mantenha infraestrutura crítica: o código que deveria fechar a vulnerabilidade foi, na prática, o que a abriu. Isso desloca o foco do debate, que até agora se concentrou na negociação com os atacantes e na devolução parcial de fundos após o roubo de 4.000 bitcoin inicialmente reportado, para uma pergunta mais incômoda sobre como correções de segurança são gerenciadas sob pressão de tempo em sistemas que custodiem bilhões de dólares.
Vale a pena parar no mecanismo, porque não se trata de um erro exótico nem depende de quebrar qualquer prova criptográfica. É um problema de projeto de um cache, algo que qualquer sistema de verificação de assinaturas ou provas usa para evitar repetir cálculos custosos. E é justamente aí, na otimização de desempenho, que entrou o erro que permitiu imprimir dinheiro, segundo reconstrói a análise de Roose.
$BTC #newscrypto
Um patch de 2026 criado para corrigir um erro de 2018 abriu, de fato, a porta para o roubo de 4.000 BTC na Liquid: a correção foi a falha.
Steven Roose, ex-engenheiro da equipe da Liquid na Blockstream e atual CEO da Second, publicou uma análise técnica que reconstrói, transação por transação, como um atacante conseguiu inflar quase 4.000 bitcoin (BTC) na rede Liquid no dia 6 de setembro passado.
Sua conclusão central contraria a leitura mais aceita do incidente: a criptografia das transações confidenciais da Liquid nunca falhou. O que falhou foi uma decisão de engenharia tomada oito anos antes, e a tentativa mal-sucedida de corrigi-la apenas dias antes do roubo.
O achado tem uma particularidade desconfortável para qualquer equipe que mantenha infraestrutura crítica: o código que deveria fechar a vulnerabilidade foi, na prática, o que a abriu. Isso desloca o foco do debate, que até agora se concentrou na negociação com os atacantes e na devolução parcial de fundos após o roubo de 4.000 bitcoin inicialmente reportado, para uma pergunta mais incômoda sobre como correções de segurança são gerenciadas sob pressão de tempo em sistemas que custodiem bilhões de dólares.
Vale a pena parar no mecanismo, porque não se trata de um erro exótico nem depende de quebrar qualquer prova criptográfica. É um problema de projeto de um cache, algo que qualquer sistema de verificação de assinaturas ou provas usa para evitar repetir cálculos custosos. E é justamente aí, na otimização de desempenho, que entrou o erro que permitiu imprimir dinheiro, segundo reconstrói a análise de Roose.
$BTC #newscrypto
