{"id":510,"date":"2026-09-12T04:42:42","date_gmt":"2026-09-12T04:42:42","guid":{"rendered":"https:\/\/hoge.gg\/pt\/white-hat-ou-roubo-hack-liquid-divulgacao-2026\/"},"modified":"2026-09-12T04:42:42","modified_gmt":"2026-09-12T04:42:42","slug":"white-hat-ou-roubo-hack-liquid-divulgacao-2026","status":"publish","type":"post","link":"https:\/\/hoge.gg\/pt\/white-hat-ou-roubo-hack-liquid-divulgacao-2026\/","title":{"rendered":"White-hat ou roubo? O hack da Liquid e a \u00e9tica da divulga\u00e7\u00e3o"},"content":{"rendered":"

Quando a Liquid Network, a sidechain de Bitcoin operada pela Blockstream, perdeu cerca de 4.000 BTC a 6 de setembro de 2026, o detalhe mais desconfort\u00e1vel n\u00e3o foi o tamanho do rombo, cerca de 265 milh\u00f5es de euros (aproximadamente 320 milh\u00f5es de d\u00f3lares) drenados num punhado de minutos. Foi a data da corre\u00e7\u00e3o. O bug que permitiu cunhar Bitcoin do nada j\u00e1 tinha um patch escrito e publicado no reposit\u00f3rio p\u00fablico do Elements dias antes de algu\u00e9m o explorar. A falha n\u00e3o estava escondida: estava no GitHub, com um t\u00edtulo de commit que a descrevia em linguagem simples.<\/p>

\u00c9 por isso que este n\u00e3o \u00e9, no fundo, mais um post-mortem de c\u00f3digo. \u00c9 um post-mortem de divulga\u00e7\u00e3o. Em poucos dias, o caso transformou-se numa disputa p\u00fablica entre figuras conhecidas do Bitcoin sobre quem sabia o qu\u00ea, quando, e o que conta como comportamento respons\u00e1vel. O atacante assina-se white-hat; a Blockstream chama-lhe roubo; e uma equipa de seguran\u00e7a diz ter avisado a empresa antes do ataque. Para uma ind\u00fastria que aperfei\u00e7oou a arte da aut\u00f3psia depois do desastre, a Liquid exp\u00f4s a parte que a cripto continua a fazer mal: o que acontece antes.<\/p>

Um bug com corre\u00e7\u00e3o p\u00fablica, e ningu\u00e9m a instalou<\/h2>

Comecemos pelo facto que reordena tudo o resto. A corre\u00e7\u00e3o para o bug explorado na Liquid n\u00e3o apareceu depois do ataque; apareceu antes. Segundo o registo do reposit\u00f3rio Elements, o commit que corrige a falha na cache de verifica\u00e7\u00e3o de range proofs (intitulado, sem ambiguidade, \u00abFix caching bug in rangeproof caching\u00bb, identificado como PR #1561) foi escrito a 3 de agosto de 2026 e fundido no ramo p\u00fablico principal a 2 de setembro, quatro dias antes da explora\u00e7\u00e3o de 6 de setembro, conforme reconstitu\u00eddo pela crypto.news<\/a> e vis\u00edvel na pr\u00f3pria p\u00e1gina de vers\u00f5es do Elements no GitHub<\/a>. Os n\u00f3s da federa\u00e7\u00e3o, entretanto, corriam a vers\u00e3o v23.3.3, lan\u00e7ada a 13 de abril de 2026. Estavam quase cinco meses atrasados.<\/p>

Este intervalo tem um nome na seguran\u00e7a inform\u00e1tica: patch-gap, a janela entre o momento em que uma corre\u00e7\u00e3o fica dispon\u00edvel e o momento em que os sistemas afetados a instalam de facto. E tem uma consequ\u00eancia bem documentada. Quando a equipa Project Zero da Google estudou o problema no Android, concluiu que uma vulnerabilidade n-day (j\u00e1 corrigida algures, mas ainda por aplicar noutro lado) pode ser t\u00e3o perigosa como uma zero-day, e por vezes mais, precisamente porque os detalhes t\u00e9cnicos, e \u00e0s vezes at\u00e9 uma prova de conceito, j\u00e1 foram publicados, como resumiu o BleepingComputer<\/a>. Uma corre\u00e7\u00e3o p\u00fablica de seguran\u00e7a n\u00e3o \u00e9 s\u00f3 um rem\u00e9dio. \u00c9 tamb\u00e9m um mapa.<\/p>

No caso da Liquid, esse mapa esteve \u00e0 vista de todos durante dias, com uma legenda a dizer exatamente onde escavar. Quem l\u00ea o Elements (e num software de c\u00f3digo aberto isso inclui defensores e atacantes) tinha um commit que anunciava um problema na cache de range proofs. Faltava apenas que os operadores da rede aplicassem a vers\u00e3o que j\u00e1 continha o rem\u00e9dio. N\u00e3o aplicaram.<\/p>

O que \u00e9 a Liquid e o que aconteceu a 6 de setembro<\/h2>

A Liquid \u00e9 uma sidechain federada de Bitcoin, constru\u00edda sobre o Elements e coordenada pela Blockstream em conjunto com um grupo de cerca de quinze membros (as chamadas functionaries, entre elas v\u00e1rias exchanges e empresas de Bitcoin) que operam os n\u00f3s que validam a rede e guardam as chaves da reserva. Quem quer us\u00e1-la faz um peg-in, tranca BTC na mainchain e recebe L-BTC em circula\u00e7\u00e3o na Liquid, uma ficha lastreada 1 para 1 pensada para liquida\u00e7\u00f5es mais r\u00e1pidas e transa\u00e7\u00f5es confidenciais; quem quer sair faz um peg-out e recupera o BTC. \u00c9, na pr\u00e1tica, um cofre coletivo de Bitcoin com regras pr\u00f3prias de contabilidade, e n\u00e3o uma rede sem confian\u00e7a como a mainchain.<\/p>

A 6 de setembro de 2026, por volta das 15h53 UTC (bloco 4.050.336 da Liquid), esse cofre foi esvaziado. A raiz, confirmada pela an\u00e1lise da CertiK<\/a> e pela pr\u00f3pria Blockstream, n\u00e3o foram chaves roubadas nem hardware comprometido: foi uma colis\u00e3o de chave de cache no Elements. Para poupar trabalho, o software guarda em cache o veredicto \u00abesta range proof \u00e9 v\u00e1lida\u00bb, para n\u00e3o recalcular a mesma prova duas vezes. S\u00f3 que a chave dessa cache era constru\u00edda de forma amb\u00edgua, a partir dos bytes da prova e do compromisso de valor, mas omitindo o gerador do ativo e o scriptPubKey, segundo o detalhe t\u00e9cnico reunido pela crypto.news<\/a>. O resultado: duas transa\u00e7\u00f5es diferentes podiam gerar a mesma chave de cache, e uma prova falsa passava a reutilizar um veredicto \u00abv\u00e1lido\u00bb que pertencia a outra. Com isso, o atacante cunhou L-BTC sem lastro e fez o peg-out de cerca de 4.000 dos aproximadamente 4.200 BTC da reserva, movendo-os atrav\u00e9s da SideSwap. A reserva caiu de cerca de 4.205 BTC para perto de 200, como noticiou o Crypto Times<\/a>. Tudo em cerca de 23 minutos.<\/p>

Elemento<\/th>Detalhe<\/th><\/tr><\/thead>
Data e bloco<\/td>6 set 2026, ~15h53 UTC, bloco 4.050.336<\/td><\/tr>
Causa raiz<\/td>Colis\u00e3o de chave de cache na verifica\u00e7\u00e3o de range proofs (Elements), n\u00e3o chaves roubadas<\/td><\/tr>
Montante<\/td>~3.998,5 L-BTC cunhados; ~4.000 BTC sa\u00eddos (~265 M\u20ac \/ ~320 M$)<\/td><\/tr>
Reserva<\/td>De ~4.205 BTC para ~200 BTC<\/td><\/tr>
Assinatura<\/td>Multisig 11 em 15 da federa\u00e7\u00e3o assinou um peg-out \u00abv\u00e1lido\u00bb<\/td><\/tr>
Sa\u00edda dos fundos<\/td>Atrav\u00e9s da SideSwap<\/td><\/tr>
Devolvido<\/td>3.400 BTC (85%) a 7 set; ~598,5 BTC por devolver<\/td><\/tr>
Corre\u00e7\u00e3o<\/td>Elements v23.3.4, publicada a 9 set<\/td><\/tr><\/tbody><\/table><\/figure>

Porque uma multisig de 11 em 15 assinou o assalto<\/h2>

Numa federa\u00e7\u00e3o, uma multisig de 11 em 15 devia ser uma barreira. Onze dos quinze membros tiveram de assinar o peg-out que tirou os 4.000 BTC. Assinaram. E \u00e9 aqui que est\u00e1 o mal-entendido mais comum sobre este caso: a multisig n\u00e3o falhou por ter sido enganada ou coagida; falhou porque n\u00e3o tinha como saber. Uma multisig valida assinaturas, n\u00e3o valida as regras de consenso da cadeia. Do ponto de vista dos signat\u00e1rios, aquele peg-out parecia uma sa\u00edda perfeitamente normal, lastreada por L-BTC que o software lhes garantia ser leg\u00edtimo. O bug estava uma camada abaixo, na verifica\u00e7\u00e3o que dizia \u00abesta prova \u00e9 v\u00e1lida\u00bb.<\/p>

O programador Mononaut, do mempool.space, apontou o sintoma mais revelador: os n\u00f3s da federa\u00e7\u00e3o aceitaram as transa\u00e7\u00f5es da explora\u00e7\u00e3o enquanto outros n\u00f3s, a correr c\u00f3digo diferente, as rejeitavam, segundo a crypto.news<\/a>. Por outras palavras, a rede esteve dividida entre quem j\u00e1 tinha o entendimento correto das regras e quem n\u00e3o tinha, e foram os guardi\u00f5es da reserva que ficaram do lado errado dessa linha.<\/p>

Isto contraria a narrativa dominante de 2026. Foi o ano em que a mensagem da ind\u00fastria passou a ser que as chaves batem o c\u00f3digo: mais de 1,3 mil milh\u00f5es de d\u00f3lares perdidos em oito meses, com a maior fatia a vir de chaves comprometidas e engenharia social, n\u00e3o de bugs de contrato, como documentou a Forbes<\/a> a partir dos dados da CertiK. Ronghui Gu, presidente executivo da CertiK, resumiu-o assim: \u00abUm protocolo pode passar numa auditoria de c\u00f3digo impec\u00e1vel e ainda assim perder milh\u00f5es por causa de uma chave de administra\u00e7\u00e3o comprometida.\u00bb A Liquid \u00e9 o contraexemplo perfeito: nem chave, nem administra\u00e7\u00e3o, nem contrato. Um bug de consenso puro, do tipo que se dizia estar em vias de extin\u00e7\u00e3o. E, mesmo assim, o problema profundo n\u00e3o foi o bug. Foi tudo o que o rodeou. Quem decide, afinal, quando e como se aplica uma corre\u00e7\u00e3o a uma infraestrutura de Bitcoin partilhada por tanta gente e governada por t\u00e3o poucos? \u00c9 a mesma pergunta inc\u00f3moda que atravessa a governa\u00e7\u00e3o sem voto do Bitcoin e do Ethereum<\/a>.<\/p>

O patch-gap: quando a corre\u00e7\u00e3o \u00e9 o mapa do assalto<\/h2>

Chegamos ao cora\u00e7\u00e3o do assunto. Em software propriet\u00e1rio, uma empresa pode corrigir uma falha em sil\u00eancio e distribuir a atualiza\u00e7\u00e3o antes de o mundo saber que ela existiu. Em c\u00f3digo aberto, n\u00e3o h\u00e1 sil\u00eancio poss\u00edvel: a corre\u00e7\u00e3o \u00e9 um evento p\u00fablico. E quando essa corre\u00e7\u00e3o \u00e9 fundida no ramo principal com um t\u00edtulo que descreve o problema, sem uma vers\u00e3o empacotada e instalada nos sistemas cr\u00edticos ao mesmo tempo, o que se cria n\u00e3o \u00e9 seguran\u00e7a. \u00c9 uma contagem decrescente.<\/p>

Data<\/th>Acontecimento<\/th><\/tr><\/thead>
3 ago 2026<\/td>Corre\u00e7\u00e3o escrita (commit \u00abFix caching bug in rangeproof caching\u00bb, PR #1561)<\/td><\/tr>
2 set 2026<\/td>Corre\u00e7\u00e3o fundida no ramo p\u00fablico principal do Elements<\/td><\/tr>
6 set 2026<\/td>Explora\u00e7\u00e3o (bloco 4.050.336), cerca de 4 dias depois de a corre\u00e7\u00e3o ser p\u00fablica<\/td><\/tr>
N\u00f3s da federa\u00e7\u00e3o<\/td>A correr v23.3.3 (13 abr 2026), quase 5 meses de atraso<\/td><\/tr>
7 set 2026<\/td>Rede parada; 3.400 BTC (85%) devolvidos \u00e0s 16h09 UTC<\/td><\/tr>
9 set 2026<\/td>Elements v23.3.4 publicada<\/td><\/tr>
10 set 2026<\/td>Blocos retomados (peg-outs ainda desativados)<\/td><\/tr>
11 set 2026<\/td>Blockstream recusa pagar pelos ~598,5 BTC restantes<\/td><\/tr><\/tbody><\/table><\/figure>

O padr\u00e3o tem nome duplo. H\u00e1 o patch-gap simples (a corre\u00e7\u00e3o existe, mas o utilizador ainda n\u00e3o a aplicou) e h\u00e1 o patch-gap a montante, mais trai\u00e7oeiro, em que o fornecedor de origem j\u00e1 tem o rem\u00e9dio mas os projetos que dependem dele ainda n\u00e3o o integraram. A Liquid viveu exatamente o segundo: o Elements a montante tinha a corre\u00e7\u00e3o; a federa\u00e7\u00e3o a jusante corria uma vers\u00e3o de abril. \u00c9 o mesmo desenho que a Project Zero descreveu no Android, onde os fabricantes podem demorar meses a fazer chegar uma corre\u00e7\u00e3o j\u00e1 dispon\u00edvel.<\/p>

A resposta da comunidade de seguran\u00e7a a este dilema tem sido gerir a divulga\u00e7\u00e3o, n\u00e3o fingir que ela n\u00e3o acontece. A pr\u00f3pria Project Zero, depois de anos a lutar com o problema, passou em 2025 a anunciar cedo a exist\u00eancia de uma falha comunicada a um fornecedor, mas a manter privados os detalhes t\u00e9cnicos e a prova de conceito at\u00e9 ao fim do prazo, como explicou o CyberScoop<\/a>. A l\u00f3gica \u00e9 simples: separar o \u00abexiste um problema aqui\u00bb do \u00abaqui est\u00e1 exatamente como o explorar\u00bb. No Elements, os dois vieram no mesmo commit.<\/p>

H\u00e1 uma ironia adicional espec\u00edfica da Liquid. Numa rede permissionless como a mainchain do Bitcoin, ningu\u00e9m consegue obrigar milhares de n\u00f3s an\u00f3nimos a atualizar em coordena\u00e7\u00e3o, e o patch-gap \u00e9, at\u00e9 certo ponto, inevit\u00e1vel. A Liquid n\u00e3o \u00e9 isso: \u00e9 uma federa\u00e7\u00e3o de cerca de quinze membros identificados, com contactos conhecidos e obriga\u00e7\u00f5es contratuais entre si. Era precisamente o tipo de rede em que uma atualiza\u00e7\u00e3o coordenada e privada, antes de a corre\u00e7\u00e3o se tornar p\u00fablica, seria poss\u00edvel. A janela existiu n\u00e3o porque fosse imposs\u00edvel fech\u00e1-la, mas porque ningu\u00e9m a fechou a tempo.<\/p>

White-hat ou roubo? A fronteira que a cripto nunca fixou<\/h2>

Enquanto os 4.000 BTC sa\u00edam, o atacante fez algo que se tornou um ritual da cripto: deixou uma mensagem on-chain. \u00abPlease fix the bug first. The chain is under risk at latest commit right now. Make sure every node is patched. Then we will transfer the money back safely after confirming the fix\u00bb, escreveu, ou seja, corrijam primeiro o bug, a cadeia est\u00e1 em risco no commit mais recente, garantam que todos os n\u00f3s est\u00e3o atualizados, e depois devolveremos o dinheiro em seguran\u00e7a, como reportou a CoinDesk<\/a>. \u00c9 a pose do white-hat: eu n\u00e3o sou um ladr\u00e3o, sou o vosso teste de intrus\u00e3o n\u00e3o solicitado.<\/p>

A Blockstream n\u00e3o aceitou o enquadramento. Ao recusar pagar qualquer recompensa pelos cerca de 598,5 BTC ainda retidos, a empresa foi taxativa, segundo o The Block<\/a>: \u00abTirar ativos sem autoriza\u00e7\u00e3o e reter a sua devolu\u00e7\u00e3o \u00e9 um crime, n\u00e3o divulga\u00e7\u00e3o respons\u00e1vel. N\u00e3o \u00e9 atividade white-hat. \u00c9 roubo.\u00bb Charles Guillemet, diretor de tecnologia da Ledger, foi na mesma dire\u00e7\u00e3o, questionando o r\u00f3tulo de white-hat com o argumento de que um investigador genu\u00edno divulga a falha antes de mover somas enormes de garantia, n\u00e3o depois.<\/p>

O problema \u00e9 que a cripto nunca fixou bem esta fronteira, e a diferen\u00e7a entre her\u00f3i e vil\u00e3o pode resumir-se a quem devolve o dinheiro e com que rapidez. A tentativa mais s\u00e9ria de a codificar \u00e9 o Safe Harbor da Security Alliance (SEAL): uma oferta p\u00fablica e juridicamente vinculativa que d\u00e1 imunidade a quem devolver os fundos em at\u00e9 72 horas, com uma recompensa de 10% limitada a um milh\u00e3o de d\u00f3lares e verifica\u00e7\u00e3o de identidade, e que j\u00e1 cobre dezenas de milhares de milh\u00f5es em protocolos, como descreve a pr\u00f3pria SEAL<\/a>. O modelo de refer\u00eancia continua a ser a Euler, cujo atacante devolveu quase tudo em 2023 depois de negociar on-chain e escrever \u00abNo intention of keeping what is not ours\u00bb, sem inten\u00e7\u00e3o de ficar com o que n\u00e3o \u00e9 nosso, como noticiou o The Block<\/a>. A diferen\u00e7a face \u00e0 Liquid \u00e9 subtil mas decisiva: na Euler n\u00e3o havia um patch p\u00fablico ignorado, e a devolu\u00e7\u00e3o n\u00e3o vinha embrulhada numa exig\u00eancia. O debate sobre onde acaba a leg\u00edtima defesa da rede e come\u00e7a o crime \u00e9, no fundo, o mesmo que a HOGE Wire explorou a prop\u00f3sito do drama das DAO e do vil\u00e3o que falta<\/a>.<\/p>

600 BTC para ignorar um email: a disputa da divulga\u00e7\u00e3o<\/h2>

Se o caso ficasse pela mec\u00e2nica, seria um post-mortem t\u00e9cnico. O que o tornou um caso de cultura foi a segunda frente, aberta poucos dias depois. Calle, col\u00edder do Bitcoin Red Team, um grupo de investiga\u00e7\u00e3o de seguran\u00e7a, veio a p\u00fablico afirmar que tinha avisado a Blockstream sobre a vulnerabilidade antes do ataque. O seu coment\u00e1rio, dirigido \u00e0s explica\u00e7\u00f5es da empresa, foi cortante: \u00abAfinal, s\u00f3 custa 600 BTC ignorar um email da red team\u00bb, atirou, segundo a news.bitcoin.com<\/a>. Calle acrescentou que a Blockstream tinha mencionado os patches \u00abde forma seletiva e imprecisa, sem um hist\u00f3rico completo e muito claro de reconhecimento\u00bb.<\/p>

A Blockstream contesta. Samson Mow, antigo diretor de seguran\u00e7a da empresa, respondeu que \u00abnenhum email foi ignorado\u00bb e sugeriu que as insinua\u00e7\u00f5es diminu\u00edam a seriedade do pr\u00f3prio Red Team. Calle, por seu lado, disse que daria tempo \u00e0 Blockstream para restaurar as opera\u00e7\u00f5es e publicar o seu post-mortem antes de divulgar o relato completo do processo de divulga\u00e7\u00e3o, deixando no ar a exist\u00eancia de vers\u00f5es conflituantes sobre a mesma cronologia.<\/p>

Retire-se o ru\u00eddo e fica uma pergunta de responsabilidade que a cripto raramente enfrenta: quando uma equipa externa avisa, de quem \u00e9 o dever de agir, e em que prazo? Num software mantido por poucos e usado por muitos, receber um aviso e n\u00e3o empacotar e distribuir a corre\u00e7\u00e3o a tempo \u00e9 uma falha operacional t\u00e3o grave como o bug original. \u00c9 a mesma tens\u00e3o que percorre a profissionaliza\u00e7\u00e3o da governa\u00e7\u00e3o cripto, onde gerir uma infraestrutura comum se tornou um emprego<\/a> com deveres, e n\u00e3o apenas um passatempo de volunt\u00e1rios.<\/p>

A divulga\u00e7\u00e3o coordenada que a cripto importou pela metade<\/h2>

Fora da cripto, este problema n\u00e3o \u00e9 novo, e h\u00e1 d\u00e9cadas de pr\u00e1tica acumulada em como o resolver. Chama-se divulga\u00e7\u00e3o coordenada de vulnerabilidades (CVD). A ideia \u00e9 dar ao fornecedor uma janela para corrigir antes de os detalhes se tornarem p\u00fablicos, com regras claras: prazos, prote\u00e7\u00e3o legal para quem reporta de boa-f\u00e9, e a promessa de n\u00e3o deixar corre\u00e7\u00f5es em sil\u00eancio. Em julho de 2026, a ag\u00eancia norte-americana CISA publicou orienta\u00e7\u00f5es que recomendam precisamente linguagem de safe harbor para investigadores, evitar acordos de confidencialidade cegos e corre\u00e7\u00f5es silenciosas, e coordenar a publica\u00e7\u00e3o ap\u00f3s a remedia\u00e7\u00e3o, tipicamente num prazo de 90 dias, como resumiu a Help Net Security<\/a>. Do lado legal, a pol\u00edtica do Departamento de Justi\u00e7a dos EUA desde 2022 desencoraja processar investiga\u00e7\u00e3o de boa-f\u00e9, e a diretiva NIS2 da UE incentiva a CVD ao n\u00edvel dos Estados-membros.<\/p>

A cripto importou este mundo pela metade. Copiou a aut\u00f3psia (o post-mortem detalhado, com cronologia ao minuto e causa raiz, publicado depois do desastre) e saltou a sala de emerg\u00eancia (o processo disciplinado de divulga\u00e7\u00e3o que devia impedir o desastre, ou pelo menos encurtar a janela). Temos rekt.news, temos dashboards de transpar\u00eancia, temos investigadores forenses de reputa\u00e7\u00e3o. N\u00e3o temos um padr\u00e3o partilhado sobre como se comunica uma falha, quem tem de agir, em quanto tempo, e o que se torna p\u00fablico quando. O caso Liquid \u00e9 o que acontece quando a parte de tr\u00e1s do manual est\u00e1 bem escrita e a parte da frente n\u00e3o existe.<\/p>

A intelig\u00eancia artificial acelera os dois lados<\/h2>

H\u00e1 um fio que liga a Liquid ao outro grande caso de 2026, o da carteira f\u00edsica Coldcard, e esse fio \u00e9 a intelig\u00eancia artificial. Sobre a origem do bug, o fundador da Blockstream, Adam Back, ofereceu uma explica\u00e7\u00e3o que \u00e9 quase uma boneca russa: a falha cr\u00edtica ter\u00e1 sido introduzida \u00abdevido a uma corre\u00e7\u00e3o de bug incorreta, para um bug encontrado por IA que tamb\u00e9m era um bug n\u00e3o cr\u00edtico\u00bb, segundo o Crypto Times<\/a>. Ou seja: a IA encontrou um problema pequeno, a corre\u00e7\u00e3o desse problema pequeno criou um problema enorme, e a corre\u00e7\u00e3o do problema enorme ficou dias exposta antes de algu\u00e9m a instalar.<\/p>

Do lado da Coldcard, Rodolfo Novak, cofundador da Coinkite, tinha avisado semanas antes que \u00aba revis\u00e3o de c\u00f3digo assistida por IA consegue agora encontrar bugs latentes a uma velocidade que ultrapassa at\u00e9 os especialistas mais experientes da ind\u00fastria\u00bb, como citou a Bitcoin Magazine<\/a>. As duas afirma\u00e7\u00f5es, juntas, descrevem um problema desconfort\u00e1vel para a era do patch-gap: se a IA acelera a descoberta de falhas nos dois lados, ent\u00e3o a janela entre uma corre\u00e7\u00e3o p\u00fablica e a sua explora\u00e7\u00e3o encolhe. O commit deixa de ser um mapa que um atacante humano leva dias a decifrar e passa a ser algo que uma ferramenta automatizada transforma em exploit em horas. A resposta n\u00e3o pode continuar a ser a velocidade humana de abril.<\/p>

O peg, o resgate e a conta por pagar<\/h2>

Nem tudo correu mal. Menos de um dia depois, a 7 de setembro \u00e0s 16h09 UTC, o atacante devolveu 3.400 BTC, cerca de 85% do total, deixando por devolver aproximadamente 598,5 BTC, \u00e0 volta de 40 milh\u00f5es de euros (perto de 47 milh\u00f5es de d\u00f3lares). A Blockstream tra\u00e7ou a linha: \u00abN\u00e3o pagaremos pela devolu\u00e7\u00e3o de propriedade roubada\u00bb, declarou, recusando tamb\u00e9m servir de precedente para que software de c\u00f3digo aberto feito para o bem do Bitcoin sujeite os seus programadores a pagar um resgate, nas palavras reproduzidas pelo The Block<\/a>.<\/p>

Quanto ao lastro, o cofundador Adam Back garantiu que a paridade 1 para 1 entre L-BTC e BTC seria coberta, o que na pr\u00e1tica significa que a Blockstream absorve o buraco. Durante os dias seguintes, o L-BTC ficou temporariamente sub-colateralizado, com um r\u00e1cio de cobertura na casa dos 85%, exatamente o tipo de problema de reserva que tamb\u00e9m assombra as stablecoins e o seu rendimento<\/a>: uma ficha s\u00f3 vale a paridade que algu\u00e9m garante. A empresa lan\u00e7ou o Elements v23.3.4 a 9 de setembro, os blocos foram retomados a 10 de setembro (com os peg-outs ainda desativados por precau\u00e7\u00e3o) e comprometeu-se a trabalhar com autoridades e peritos forenses para recuperar o resto. Quem no fim suporta a perda \u00e9 a Blockstream, uma disciplina de balan\u00e7o que ecoa a nova era das tesourarias cripto<\/a>, onde j\u00e1 n\u00e3o se compra (nem se cobre) a qualquer pre\u00e7o sem regras.<\/p>

Essa cobertura resolve o problema imediato dos utilizadores, mas levanta outro. Um lastro que depende de uma empresa privada aceitar absorver 40 milh\u00f5es de euros de preju\u00edzo \u00e9, por defini\u00e7\u00e3o, um ponto de confian\u00e7a. Funcionou desta vez porque a Blockstream quis e p\u00f4de; a pergunta que fica para a Liquid, e para qualquer sidechain federada, \u00e9 o que acontece no dia em que o buraco for grande demais para o balan\u00e7o de quem o tem de tapar. \u00c9 a diferen\u00e7a entre uma rede que n\u00e3o precisa de confiar em ningu\u00e9m e uma que precisa de confiar em algu\u00e9m solvente.<\/p>

Corrigido no reposit\u00f3rio, explorado na rede: o padr\u00e3o de 2026<\/h2>

Visto de longe, 2026 tem um padr\u00e3o: a falha existe algures antes de explodir noutro lado, e a diferen\u00e7a entre um desastre e um susto est\u00e1 quase toda na resposta. Vale a pena colocar a Liquid ao lado dos casos que definiram os anos anteriores.<\/p>

Caso<\/th>Tipo de falha<\/th>Vetor conhecido antes?<\/th>Enquadramento<\/th>Quem suportou a perda<\/th><\/tr><\/thead>
Liquid (2026)<\/td>Bug de consenso (cache)<\/td>Sim, corre\u00e7\u00e3o p\u00fablica 4 dias antes<\/td>Disputado: white-hat vs roubo<\/td>Blockstream (cobre o peg)<\/td><\/tr>
Euler (2023)<\/td>Bug de contrato<\/td>N\u00e3o<\/td>Devolu\u00e7\u00e3o negociada, ~100%<\/td>Recuperado<\/td><\/tr>
Wormhole (2022)<\/td>Verifica\u00e7\u00e3o de assinatura<\/td>N\u00e3o<\/td>Reposi\u00e7\u00e3o por terceiro<\/td>Jump Crypto rep\u00f4s ~320 M$<\/td><\/tr>
Bybit (2025)<\/td>Compromisso de UI\/supply-chain<\/td>N\u00e3o<\/td>Transpar\u00eancia radical<\/td>Bybit (solvente)<\/td><\/tr>
Coldcard (2026)<\/td>RNG fraco no firmware<\/td>Latente desde 2021<\/td>Sem r\u00e9u \u00fanico<\/td>Utilizadores<\/td><\/tr><\/tbody><\/table><\/figure>

A compara\u00e7\u00e3o mais desconfort\u00e1vel \u00e9 com a Wormhole, que em 2022 perdeu tamb\u00e9m cerca de 320 milh\u00f5es de d\u00f3lares numa falha de verifica\u00e7\u00e3o de assinatura. A diferen\u00e7a \u00e9 que a Jump Crypto rep\u00f4s o valor total em cerca de um dia, como noticiou a Fortune<\/a>, transformando uma cat\u00e1strofe potencial num epis\u00f3dio de contabilidade. A Bybit, em 2025, respondeu ao maior roubo de sempre com transpar\u00eancia radical e um programa de recompensas para rastrear os fundos, como reportou a TechCrunch<\/a>. E a Coldcard mostrou o pior cen\u00e1rio: um bug latente desde 2021, sem r\u00e9u \u00fanico e sem tesouraria que cobrisse os utilizadores. A Liquid encaixa algures no meio, com um tra\u00e7o s\u00f3 seu: foi a \u00fanica em que a corre\u00e7\u00e3o j\u00e1 era p\u00fablica quando o ataque aconteceu.<\/p>

O que a MiCA e a CMVM alcan\u00e7am (e o que n\u00e3o)<\/h2>

E a regula\u00e7\u00e3o, onde entra? Para um leitor portugu\u00eas, a resposta \u00e9 frustrante mas clarificadora. A MiCA regula os prestadores de servi\u00e7os de criptoativos (os CASP) e os emitentes, n\u00e3o o software de consenso de uma sidechain. A Blockstream n\u00e3o \u00e9 um CASP e o Elements n\u00e3o \u00e9 um produto financeiro; v\u00e1rias das functionaries da federa\u00e7\u00e3o, essas sim, s\u00e3o exchanges que podem estar abrangidas pela MiCA nas suas pr\u00f3prias jurisdi\u00e7\u00f5es, mas nenhuma delas \u00abopera\u00bb sozinha o bug que era partilhado por todas. O regime alcan\u00e7a as bordas, n\u00e3o o centro.<\/p>

H\u00e1 um instrumento que se aproxima do tema: o regulamento DORA, em vigor desde janeiro de 2025, obriga os CASP e outras entidades financeiras a reportar incidentes graves de TIC num rel\u00f3gio apertado (notifica\u00e7\u00e3o inicial em poucas horas, relat\u00f3rio interm\u00e9dio em 72 horas, relat\u00f3rio final em um m\u00eas), como detalha a documenta\u00e7\u00e3o europeia sobre a DORA<\/a>. Mas a DORA governa como uma entidade regulada reporta um incidente que a afeta, n\u00e3o como se coordena a divulga\u00e7\u00e3o de uma falha num software de c\u00f3digo aberto que ningu\u00e9m individualmente controla, e n\u00e3o fixa qualquer norma de auditoria de c\u00f3digo nem de divulga\u00e7\u00e3o coordenada. Nenhum regulador, nem a CMVM, nem o Banco de Portugal, nem a ESMA ao n\u00edvel europeu, certifica investigadores de seguran\u00e7a ou define um padr\u00e3o probat\u00f3rio de divulga\u00e7\u00e3o para infraestrutura cripto, como se pode confirmar na p\u00e1gina da CMVM sobre fintech e criptoativos<\/a>.<\/p>

Na pr\u00e1tica, para uma v\u00edtima portuguesa, a via n\u00e3o seria a CMVM mas o C\u00f3digo Penal e a Lei do Cibercrime, atrav\u00e9s da Pol\u00edcia Judici\u00e1ria, com todas as dificuldades de perseguir um atacante an\u00f3nimo atrav\u00e9s de fronteiras. O post-mortem, mais uma vez, \u00e9 o \u00fanico tribunal com jurisdi\u00e7\u00e3o garantida.<\/p>

Como ler o post-mortem que a\u00ed vem<\/h2>

A Blockstream prometeu um post-mortem, e o Bitcoin Red Team prometeu o seu pr\u00f3prio relato do processo de divulga\u00e7\u00e3o. Quando chegarem, vale a pena l\u00ea-los com uma grelha espec\u00edfica, porque \u00e9 na cronologia da divulga\u00e7\u00e3o, e n\u00e3o na descri\u00e7\u00e3o do bug, que este caso se joga.<\/p>

  • Quando \u00e9 que a corre\u00e7\u00e3o foi escrita, quando foi fundida no ramo p\u00fablico, e quando (se alguma vez) foi empacotada numa vers\u00e3o instalada nos n\u00f3s da federa\u00e7\u00e3o?<\/li>
  • Houve um aviso externo? Em que data chegou, a quem, e que a\u00e7\u00e3o concreta se seguiu nas horas seguintes?<\/li>
  • Porque \u00e9 que os n\u00f3s cr\u00edticos corriam uma vers\u00e3o de abril quando a corre\u00e7\u00e3o estava dispon\u00edvel desde o in\u00edcio de setembro?<\/li>
  • Que processo de divulga\u00e7\u00e3o coordenada passa a existir a partir de agora, com que prazos e que prote\u00e7\u00e3o para quem reporta de boa-f\u00e9?<\/li><\/ul>

    Um bom post-mortem responde a todas estas perguntas mesmo quando as respostas envergonham quem o escreve. Um mau post-mortem descreve o bug ao mil\u00edmetro e deixa a cronologia da divulga\u00e7\u00e3o na sombra. A cripto j\u00e1 domina a primeira metade desse exerc\u00edcio. O caso Liquid \u00e9 o convite (mais um) para dominar a segunda: tratar a divulga\u00e7\u00e3o com o mesmo rigor forense com que j\u00e1 trata a aut\u00f3psia. Porque, como este setembro deixou claro, uma falha pode estar corrigida no papel e continuar a valer 320 milh\u00f5es para quem chegar primeiro.<\/p>

    Perguntas frequentes<\/h2>

    O que \u00e9 a Liquid Network e quem a controla?<\/h3>

    A Liquid \u00e9 uma sidechain federada de Bitcoin, constru\u00edda sobre o software Elements e coordenada pela Blockstream em conjunto com cerca de quinze membros, v\u00e1rias delas exchanges, que operam os n\u00f3s e guardam a reserva. Os utilizadores trancam BTC na mainchain e recebem L-BTC lastreado 1 para 1 na Liquid, pensado para liquida\u00e7\u00f5es r\u00e1pidas e transa\u00e7\u00f5es confidenciais. N\u00e3o \u00e9 uma rede sem confian\u00e7a como a mainchain do Bitcoin: depende da honestidade e da seguran\u00e7a operacional dessa federa\u00e7\u00e3o.<\/p>

    Quanto foi roubado no hack da Liquid de setembro de 2026?<\/h3>

    Sa\u00edram da reserva da federa\u00e7\u00e3o cerca de 4.000 dos aproximadamente 4.200 BTC lastreados, algo como 265 milh\u00f5es de euros (perto de 320 milh\u00f5es de d\u00f3lares) ao c\u00e2mbio da altura. O atacante devolveu 3.400 BTC (85%) no dia seguinte e ficou com cerca de 598,5 BTC, \u00e0 volta de 40 milh\u00f5es de euros, que a Blockstream se recusou a pagar como recompensa.<\/p>

    O ataque \u00e0 Liquid foi um roubo de chaves privadas?<\/h3>

    N\u00e3o. Ao contr\u00e1rio da maioria dos grandes casos de 2026, n\u00e3o houve chaves roubadas nem hardware comprometido. A falha foi um bug de consenso no Elements, uma colis\u00e3o de chave de cache na verifica\u00e7\u00e3o de range proofs que permitiu reutilizar um veredicto \u00abv\u00e1lido\u00bb e cunhar L-BTC sem lastro. A multisig de 11 em 15 assinou um peg-out que lhe parecia perfeitamente normal.<\/p>

    O que \u00e9 o patch-gap e porque \u00e9 que importa neste caso?<\/h3>

    O patch-gap \u00e9 o intervalo entre o momento em que uma corre\u00e7\u00e3o de seguran\u00e7a fica dispon\u00edvel e o momento em que os sistemas afetados a instalam. No caso da Liquid, a corre\u00e7\u00e3o estava p\u00fablica no reposit\u00f3rio Elements quatro dias antes do ataque, mas os n\u00f3s da federa\u00e7\u00e3o corriam uma vers\u00e3o de abril. Em software de c\u00f3digo aberto, uma corre\u00e7\u00e3o publicada funciona como um mapa da vulnerabilidade para quem ainda n\u00e3o atualizou.<\/p>

    O atacante da Liquid foi um white-hat?<\/h3>

    \u00c9 exatamente isso que est\u00e1 em disputa. O atacante deixou uma mensagem on-chain a dizer-se investigador de seguran\u00e7a e a pedir que a rede fosse corrigida antes de devolver os fundos, mas a Blockstream classificou a reten\u00e7\u00e3o dos restantes 598 BTC como roubo, n\u00e3o como divulga\u00e7\u00e3o respons\u00e1vel. A fronteira depende de detalhes como a inten\u00e7\u00e3o, o momento da divulga\u00e7\u00e3o e o facto de os fundos terem sido movidos primeiro.<\/p>