O fundo ou a autópsia: Bitget, Liquid e o pior mês de 2026
Setembro de 2026 foi o pior mês de hacks do ano. Dois ataques de dimensão semelhante, na Bitget e na Liquid, produziram autópsias opostas: um cheque e um relatório.
Setembro de 2026 entrou nas contas da cripto pela pior das razões. Entre o primeiro e o último dia do mês, duas empresas de análise forense chegaram quase ao mesmo número: a PeckShield registou cerca de 766,5 milhões de dólares roubados em 55 incidentes de relevo, e a CertiK contou 768,4 milhões em 97 incidentes. Qualquer das contas transforma setembro no mês mais caro do ano e empurra as perdas acumuladas de 2026 para perto dos 2,68 mil milhões de dólares, segundo a crypto.news.
Dois nomes explicam quase toda a fatura do mês: a corretora Bitget, com cerca de 387,5 milhões de dólares (uns 344 milhões de euros), e a Liquid Network, a sidechain de Bitcoin operada pela Blockstream, com perto de 4.000 BTC. Foram, segundo a Cryptopolitan, o primeiro e o segundo maiores ataques do ano.
O que torna este mês relevante para quem acompanha a cultura do post-mortem na cripto não é a soma, é o contraste. Dois ataques de dimensão parecida produziram duas respostas quase opostas. A Blockstream acabou por publicar uma autópsia técnica longa e detalhada, do género que a indústria costuma elogiar. A Bitget abriu o cofre, reembolsou os clientes e falou muito pouco de código. Um escreveu um relatório; o outro passou um cheque. E a escolha de cada um diz quase tudo sobre a diferença entre uma corretora e um protocolo.
Setembro de 2026: o mês mais caro de sempre
Para perceber a dimensão, convém recuar. No primeiro semestre de 2026, a TRM Labs tinha contado cerca de 972 milhões de dólares roubados em 207 incidentes, um recorde no número de ataques mas com um valor abaixo de metade do primeiro semestre de 2025. Setembro, sozinho, roçou os 770 milhões. A leitura é simples: o dinheiro não saiu do crime cripto, concentrou-se.
As duas empresas que publicaram balanços mensais divergem no detalhe mas não na conclusão. A PeckShield apontou 766,5 milhões de dólares; a CertiK, que usa outra metodologia e inclui mais casos pequenos, chegou a 768,4 milhões em 97 incidentes, e a cerca de 656 incidentes e 2,68 mil milhões no acumulado do ano. Além da Bitget e da Liquid, setembro trouxe perdas menores mas igualmente reveladoras: a Safe Wallet (7,8 milhões), a carteira DCENT (uns 6 milhões) e a casa de apostas Duelbits (cerca de 5,9 milhões), todas no balanço mensal das empresas forenses.
O padrão de fundo não é novo para quem acompanha esta série. A maior parte do valor deixou de sair de erros em contratos inteligentes e passou a sair de chaves comprometidas, software de terceiros e engenharia social. Foi exatamente isso que aconteceu nos dois grandes casos do mês, em lados opostos daquilo a que podemos chamar a fronteira da custódia.
Dois ataques, duas autópsias: a corretora e o protocolo
A Bitget e a Liquid são criaturas diferentes. A primeira é uma corretora centralizada (CEX): guarda as chaves dos clientes, tem um balanço, uma sede, executivos com nome e cara e, cada vez mais, um regulador. A segunda é um protocolo: a Liquid é uma sidechain federada de Bitcoin, operada por um consórcio de empresas a que se chama federação, sem balanço próprio para cobrir perdas e sem ninguém a quem, na prática, um lesado possa apresentar queixa.
Essa diferença de natureza molda a resposta ao ataque. Quando uma CEX é esvaziada, a pergunta imediata do cliente é se vai reaver o dinheiro. Quando um protocolo é explorado, não há cofre para abrir: a única coisa que a equipa pode oferecer é a verdade sobre o que correu mal, com o máximo de detalhe, para que o resto do ecossistema não repita o erro. Dito de outro modo, a CEX responde com capital e o protocolo responde com transparência. Setembro de 2026 ofereceu, por acaso, a experiência controlada quase perfeita: dois ataques de valor semelhante, um de cada lado dessa fronteira.
Liquid: a autópsia que a Blockstream levou semanas a entregar
O ataque à Liquid aconteceu a 6 de setembro. Durante dias, porém, não houve um relatório técnico oficial, e o vazio encheu-se de polémica. O atacante dizia-se white-hat e pedia uma recompensa; a Blockstream recusou pagar pela devolução daquilo que considerava roubo; e um investigador conhecido por Calle, colíder do Bitcoin Red Team, acusou a empresa de ter ignorado um aviso prévio, com uma frase que ficou: «custa-vos apenas 600 BTC ignorar um email do red team». O antigo diretor de segurança Samson Mow respondeu que «nenhum email foi ignorado». A HOGE Wire dissecou essa guerra de narrativas quando ela estava no auge.
O que mudou agora, e justifica voltar ao caso, é que a Blockstream publicou finalmente a sua avaliação oficial do incidente, a Liquid Network Security Incident Assessment. É um documento invulgarmente franco para os padrões da indústria e é a peça que faltava para fechar a autópsia. Vale a pena lê-lo com atenção, porque conta uma história que nenhum dos textos anteriores podia contar: a do bug que nasceu de uma correção.
A anatomia do bug: quando a correção se tornou o exploit
Segundo a própria Blockstream, houve dois bugs encadeados. O primeiro (a que o relatório chama Bug A) foi introduzido em abril de 2018: a chave da cache que o Elements usa para não revalidar provas de intervalo (rangeproofs) foi simplificada e passou a omitir o compromisso de ativo e o scriptPubKey. Transportada para a validação dos Confidential Assets em 2019, essa simplificação permitia, em teoria, que um resultado de validação guardado em cache fosse reutilizado num contexto onde já não era válido.
Um investigador externo reportou o Bug A a 2 de agosto de 2026. A Blockstream corrigiu-o nos seus nós no dia seguinte e validou a correção em testnet a 5 de agosto. O problema nasceu quando essa correção foi fundida no repositório público do Elements, a 1 de setembro: a emenda acrescentava os campos em falta à chave da cache, mas concatenava-os sem prefixos de comprimento. É o Bug B. Sem delimitadores, dois conjuntos de dados diferentes podiam, por alinhamento de bytes, produzir exatamente a mesma chave.
Foi essa a porta. A 6 de setembro, o atacante truncou uma rangeproof e ajustou o scriptPubKey até a chave coincidir, byte a byte, com uma entrada já marcada como válida na cache. O consenso aceitou uma transação cujo valor de saída não estava coberto pelas entradas e cunhou LBTC sem lastro. O mecanismo PAK, que autoriza os pedidos de peg-out, limitou-se a fazer o seu trabalho sobre um estado que o consenso já dera, por erro, como verdadeiro. Nas palavras do relatório, «o mecanismo PAK autenticou um pedido de assinatura real contra LBTC que o consenso tinha, incorretamente, já aceitado como real».
A frase mais dura da autópsia é também a mais honesta: «nenhum revisor, interno ou externo, identificou este risco antes da exploração». E a lição que a Blockstream tira, em discurso direto, é de engenharia: «quando existe mais do que uma solução para um problema crítico de consenso, a abordagem que oferece as garantias estruturais de segurança mais fortes passará a ser a opção por omissão». Por outras palavras, a emenda que criou o Bug B era a correção rápida; faltou escolher a correção robusta. A ironia é total, e foi o próprio Adam Back, presidente executivo da Blockstream, quem a resumira dias antes, ao Crypto Times: o exploit veio «de uma correção incorreta, para um bug encontrado por IA que também era um bug não crítico».
A cronologia oficial, ao minuto
A avaliação da Blockstream traz uma cronologia detalhada, que vale a pena fixar porque é ela que transforma uma acusação vaga (ignoraram o aviso) num facto verificável: a janela entre a correção pública e o ataque.
| Data (2026) | Evento |
|---|---|
| 25 abr 2018 | Bug A introduzido no Elements (chave de cache simplificada) |
| 2 ago | Investigador externo reporta o Bug A à Blockstream |
| 3 ago | Correção aplicada aos nós da federação |
| 1 set | Correção fundida no repositório público; o Bug B fica visível |
| 6 set, 13:53 UTC | Exploit no bloco 4.050.336: cerca de 4.000 LBTC sem lastro |
| 6 set, 14:29 UTC | 3.996,02 BTC saem via peg-out e passam pela SideSwap |
| 6 set, 18:26 UTC | Nós da ponte parados; rede suspensa |
| 7 set, 01:09 UTC | Correção de emergência aplicada |
| 7 set, 16:09 UTC | Atacante devolve 3.400 BTC (cerca de 85%) |
| 8 set, 19:06 UTC | Correção definitiva do Bug B fundida (PR #1600) |
| 9 set, 13:30 UTC | Elements v23.3.4 lançado para produção |
| 9 set, 21:05 UTC | Produção de blocos retomada na cadeia corrigida |
O que a autópsia faz bem, e o que fica por fechar
Pelos critérios da própria cultura do post-mortem, o documento da Blockstream acerta em quase tudo o que costumamos pedir: tem cronologia ao minuto, causa-raiz ao nível do commit, assume a falha de revisão sem procurar um culpado individual e termina com uma mudança concreta de processo. É, no vocabulário herdado da engenharia de fiabilidade, um post-mortem sem culpados exemplar.
Mas uma autópsia honesta não resolve tudo. Ficam três pontas soltas. A primeira é o dinheiro: o atacante devolveu 3.400 BTC a 7 de setembro, mas, segundo a The Hacker News, mantinha ainda cerca de 602 BTC (uns 46 milhões de euros), e a Blockstream recusou pagar qualquer recompensa por eles, classificando a retenção como roubo e não como divulgação responsável. A reserva da federação caiu de cerca de 4.205 para 197 BTC no pico do ataque, segundo a mesma avaliação oficial.
A segunda ponta é a garantia. Quem tinha LBTC não ficou sem nada porque Adam Back garantiu cobrir a paridade de um para um entre LBTC e BTC. Só que isso é uma promessa pessoal do presidente executivo, não um fundo segregado nem uma obrigação legal; vale enquanto a palavra valer. A terceira é a governação: a Blockstream diz que a federação e a empresa estão a rever um conjunto mais amplo de alterações de governação, segurança e operações, mas remete os detalhes para anúncios futuros. A autópsia fecha o capítulo técnico; o capítulo institucional continua em aberto.
Bitget: quando o cofre dispensa a autópsia
Do outro lado da fronteira está a Bitget. O ataque começou a 24 de setembro e seguiu um guião que se tornou típico. Segundo a presidente executiva, Gracy Chen, em declarações ao The Block, o atacante começou por fazer transferências de teste abaixo dos limiares de alerta, para sondar os controlos de risco, antes de disparar uma série de levantamentos grandes em várias redes. Quando os sistemas sinalizaram o problema, já tinham saído cerca de 361 milhões de USDT, além de ETH, XRP, USDC, ZEC, BNB, AVAX e TRX. O total chegou perto dos 387,5 milhões de dólares.
A causa, tal como na Bybit em 2025, não foi um erro no contrato nem uma chave adivinhada: foi uma falha num software de segurança de terceiros que deu ao atacante acesso ao ambiente das carteiras quentes e mornas da corretora. As carteiras frias ficaram intactas. A Bitget chamou a Mandiant e a SlowMist para a investigação e abriu um programa de recompensas de 5% sobre fundos congelados e 5% sobre fundos recuperados.
A resposta ao cliente, porém, foi imediata e simples: o fundo de proteção do utilizador, que a Bitget diz ter ultrapassado os 465 milhões de dólares, absorveu a totalidade da perda, e a corretora comprometeu-se a repô-lo acima dos 300 milhões em pouco tempo, meta que, segundo os balanços de fim de mês, cumpriu. Para o utilizador final, o episódio resumiu-se a isto: os levantamentos de BTC, ETH e USDT foram restaurados e o saldo manteve-se. É a mesma lógica dos fundos de seguro que sustentam o volume das grandes corretoras, um tema que a HOGE Wire já tinha explorado na rede de fundos SAFU por trás do volume.
O que a Bitget escolheu não publicar
Repare-se no que falta. A Bitget deu a dimensão da perda, a causa genérica (software de terceiros), a atribuição provável e o plano de reembolso. Não publicou nada que se pareça com a autópsia da Blockstream: não há commit, não há cronologia ao segundo da intrusão, não há explicação técnica de como esse software de terceiros foi comprometido nem de porque é que os controlos internos deixaram passar 361 milhões de USDT antes de os alarmes soarem.
E a verdade é que, do ponto de vista do cliente, não precisava. O padrão de referência em transparência continua a ser a Bybit, que em 2025 publicou relatórios forenses preliminares poucos dias depois do seu ataque recorde; a Bitget ficou aquém dessa fasquia técnica. Mas ambas fizeram a única coisa que, para uma CEX, verdadeiramente importa ao utilizador: tornaram a perda invisível no saldo. Quando há um balanço por trás, a autópsia é opcional; o reembolso não é.
Gracy Chen foi, de resto, pouco otimista quanto a reaver o que foi roubado. Em declarações recolhidas pela Cointelegraph, lembrou que, um ano depois do ataque à Bybit, só cerca de 3,5% dos fundos tinham sido congelados. A mensagem implícita é clara: o dinheiro provavelmente não volta, mas o cliente não vai sentir, porque o cofre paga.
A tese: o post-mortem é sempre um substituto
Postos lado a lado, os dois casos sugerem uma tese simples sobre a cultura do post-mortem: o relatório é sempre um substituto de algo que a entidade não tem. A corretora tem capital e falta-lhe, por natureza, o código aberto ao escrutínio; por isso substitui a transparência técnica por um fundo. O protocolo tem o código à vista de todos e falta-lhe um balanço; por isso substitui o reembolso por transparência. Nenhum dos dois é mais honesto por decreto; cada um paga na moeda que tem.
| Dimensão | Bitget (corretora) | Liquid / Blockstream (protocolo) |
|---|---|---|
| Tipo de entidade | CEX centralizada e custodiante | Sidechain federada de Bitcoin |
| Valor do ataque | ~387,5 M$ (~344 M€) | ~4.000 BTC (~300 M€) |
| Causa-raiz | Software de segurança de terceiros comprometido | Colisão de chave de cache (Bug A de 2018 e a correção Bug B) |
| Quem absorve a perda | Fundo de proteção (mais de 465 M$) | Promessa de paridade de Adam Back; 602 BTC por recuperar |
| Documento produzido | Comunicados e plano de reembolso | Autópsia técnica detalhada |
| Atribuição | Indícios de ligação à Coreia do Norte | White-hat autoproclamado, sem atribuição estatal |
| Recurso do lesado | Reembolso direto (e, na UE, o regulador) | O post-mortem é o único recurso |
A tabela expõe a assimetria que mais interessa a um leitor europeu, a da última linha. Para quem perdeu dinheiro, a diferença entre as duas colunas não é filosófica: é a diferença entre recuperar o saldo e ler um relatório muito bem escrito sobre a razão por que não o vai recuperar. É uma versão, à escala de um protocolo inteiro, da velha pergunta de quem fica com a conta quando uma posição é liquidada num perp DEX.
Coreia do Norte, mais uma vez (e as dúvidas da atribuição)
Há um fio que liga a Bitget à maioria dos grandes ataques do ano e que não liga a Liquid: a Coreia do Norte. No primeiro semestre de 2026, a TRM Labs atribuiu cerca de 643 milhões de dólares, ou dois terços do valor roubado, a atores norte-coreanos, sobretudo via comprometimento de chaves e engenharia social, e não via erros de contrato. O caso Bitget encaixa no molde: transferências de teste para sondar os sistemas, software de terceiros como ponto de entrada e a própria Gracy Chen a traçar o paralelo com a Bybit, também atribuída ao grupo Lazarus.
Convém, ainda assim, calibrar a confiança. A atribuição à Coreia do Norte tornou-se um reflexo quase automático sempre que há um grande roubo a uma corretora, e nem sempre o grau de certeza é o mesmo. No caso Bitget, os indícios citados publicamente passam por endereços de IP ligados a serviços de VPN associados a operações anteriores do regime e por semelhanças de padrão, não por uma confissão nem por uma acusação formal. Já a Liquid é o contraste perfeito: o atacante apresentou-se como white-hat, negociou on-chain, devolveu a maior parte do dinheiro e ninguém lhe colou um Estado. Mover quase 400 milhões de dólares em ativos roubados sem passar por uma corretora regulada exige, de resto, canais discretos, do mercado de balcão às pontes e aos misturadores.
A lição que ninguém aprende: o intervalo do patch
Se há um ponto em que a autópsia da Liquid fala a toda a indústria, é o do intervalo do patch, o chamado problema do n-day. A correção do Bug A tornou-se pública a 1 de setembro. O ataque foi a 6. Durante cinco dias, qualquer pessoa com acesso ao repositório do Elements podia ler a emenda, perceber que resolvia um problema de validação de consenso e, neste caso, descobrir que a própria emenda abria uma segunda porta. Uma correção publicada é, para um atacante, um mapa.
É um padrão que se repete com uma regularidade quase cómica. Em 2013, uma falha no gerador de números aleatórios do Android permitiu reconstruir chaves privadas de carteiras de Bitcoin a partir de dados públicos. Em 2026, a falha de entropia da Coldcard, adormecida desde 2021, drenou carteiras durante dias e tornou-se um dos maiores desastres de hardware do ano. A forma é sempre a mesma: um defeito latente durante anos, uma correção e uma janela entre essa correção e a imunização de toda a rede. A diferença da Liquid é que a janela não foi só de exposição; foi de introdução de um novo bug.
As boas práticas existem para fechar essa janela. A divulgação coordenada de vulnerabilidades pede que a correção só se torne pública depois de os operadores críticos estarem protegidos, e iniciativas como o Safe Harbor da Security Alliance oferecem um enquadramento (devolução em 72 horas, recompensa de 10% até um milhão de dólares) para que um verdadeiro white-hat não precise de reter fundos como alavanca. A federação da Liquid corria, segundo vários relatos, uma versão do Elements de abril, com meses de atraso. Nenhuma autópsia resolve o problema de quem não atualiza a tempo.
MiCA, CMVM e os dois lados da fronteira
Para o leitor português, a distância entre as duas colunas da tabela tem um nome regulatório. Uma corretora como a Bitget, quando serve clientes na União Europeia, cai (ou cairá) sob o regulamento MiCA como prestador de serviços de criptoativos, um CASP na sigla inglesa. Isso traz deveres de custódia, de segregação dos fundos dos clientes e um regime de responsabilidade, além de uma porta à qual bater: em Portugal, a CMVM supervisiona a conduta de mercado e o Banco de Portugal trata do registo e das regras das stablecoins, ao abrigo da Lei n.º 69/2025, em vigor desde 27 de dezembro de 2025. O período transitório dos antigos VASP portugueses terminou a 1 de julho de 2026.
A Liquid não tem nada disto. Uma sidechain federada não é um CASP, não custodia fundos de clientes no sentido legal e não presta um serviço registável, por isso a MiCA, a CMVM e o Banco de Portugal simplesmente não lhe chegam. Para o DeFi e para os protocolos verdadeiramente descentralizados, as regras europeias só são esperadas para 2027 ou 2028. Entretanto, o utilizador lesado por um protocolo não tem fundo de garantia, não tem queixa possível e não tem seguro; tem, no máximo, o post-mortem. É literalmente o seu único recurso, e é por isso que a qualidade dessa autópsia importa tanto. A aproximação do regulador europeu ao universo dos cofres e do crédito on-chain é um movimento que já começou, mas ainda vai a meio.
Há ainda um contraste de ritmo que a DORA, o regulamento europeu de resiliência operacional digital em vigor desde janeiro de 2025, torna evidente. Um CASP regulado tem relógios obrigatórios para reportar um incidente grave ao supervisor: uma notificação inicial em horas, um relatório intermédio em dias e um relatório final em cerca de um mês. Um protocolo não tem relógio nenhum. A Blockstream levou o tempo que entendeu a publicar a sua avaliação, e fê-lo porque quis, não porque a lei a obrigasse.
O que isto muda para quem guarda cripto em euros
Que lições práticas tira o investidor português do pior mês de 2026? A primeira é que a velha máxima «not your keys, not your coins» tem um reverso incómodo. A autocustódia elimina o risco de a corretora ser esvaziada, mas transfere para o utilizador o peso de atualizar firmware, guardar sementes com entropia a sério e ler autópsias como a da Coldcard. A custódia numa CEX credível troca esse peso por um risco de contraparte amortecido por um fundo, desde que o fundo exista mesmo e seja do tamanho anunciado.
Antes de confiar o saldo a uma plataforma, vale a pena fazer três perguntas concretas:
- O fundo de seguro existe mesmo, qual é a sua dimensão e cobre a totalidade dos depósitos ou só uma fração?
- A prova de reservas é auditável e recente, ou é apenas uma captura de ecrã num dia favorável?
- Em caso de incidente, a plataforma está sujeita à MiCA e a um regulador como a CMVM, ou opera fora do perímetro europeu?
A segunda lição é que nem todos os fundos e garantias são iguais. O fundo da Bitget pagou; a paridade da Liquid é uma promessa. A terceira é de leitura: num ano em que o dinheiro migrou do código para as chaves e para as pessoas, o documento a ler já não é só o relatório de auditoria, é o post-mortem, e a primeira pergunta a fazer-lhe é quem o escreveu e o que tinha essa pessoa a ganhar com cada frase. Para enquadrar tudo isto no clima de mercado do fim do ano, a leitura macro sobre uma cripto sob um Fed que aperta continua a valer.
Setembro de 2026 não inventou nada; apenas juntou, no mesmo mês, os dois arquétipos. De um lado, uma empresa que paga e fala pouco. Do outro, uma empresa que fala muito e não paga tudo. A cultura do post-mortem na cripto vive nesta tensão: o relatório mais honesto do mês foi também o da entidade que deixou 602 BTC por devolver, e o cliente mais protegido do mês foi o da entidade que nunca explicou, ao certo, o que lhe aconteceu.
Perguntas frequentes
Quanto é que a cripto perdeu em setembro de 2026?
Entre 766,5 milhões de dólares (contagem da PeckShield, 55 incidentes) e 768,4 milhões (contagem da CertiK, 97 incidentes), o que faz de setembro o pior mês do ano e empurra o acumulado de 2026 para perto dos 2,68 mil milhões. Os dois maiores casos foram a Bitget (cerca de 387,5 milhões de dólares) e a Liquid Network (uns 4.000 BTC).
Qual foi a causa do ataque à Liquid Network?
Segundo a avaliação oficial da Blockstream, uma colisão na chave de cache de validação de rangeproofs do Elements. Um bug latente de 2018 omitia campos nessa chave; a correção publicada a 1 de setembro de 2026 voltou a acrescentá-los, mas sem prefixos de comprimento, criando um segundo bug que permitiu cunhar cerca de 4.000 LBTC sem lastro a 6 de setembro.
Os clientes da Bitget perderam dinheiro no ataque de 387,5 milhões?
Não. A Bitget diz que o seu fundo de proteção do utilizador, acima dos 465 milhões de dólares, absorveu a totalidade da perda e que os saldos e levantamentos foram mantidos. A corretora comprometeu-se a repor o fundo acima dos 300 milhões em pouco tempo, segundo a presidente executiva, Gracy Chen.
Porque é que a Blockstream publicou uma autópsia e a Bitget não?
Porque são entidades diferentes. Um protocolo federado como a Liquid não tem balanço para reembolsar nem regulador a quem responder, por isso a transparência técnica é o seu único recurso. Uma corretora como a Bitget tem um fundo que torna a perda invisível no saldo do cliente, o que faz da autópsia detalhada algo opcional.
Um utilizador português tem recurso se um protocolo cripto for explorado?
Depende de quem guardava os fundos. Uma corretora que sirva clientes na UE é um CASP sujeito à MiCA, com deveres de custódia e supervisão da CMVM e do Banco de Portugal ao abrigo da Lei n.º 69/2025. Um protocolo descentralizado como a Liquid fica fora desse perímetro, e as regras europeias para o DeFi só são esperadas para 2027 ou 2028, pelo que, na prática, o post-mortem é o único recurso.
Marcus Okafor escreve sobre cultura cripto, segurança e mercados na HOGE Wire.