Às 2h14 da madrugada (UTC) do dia 31 de julho de 2026, uma única entidade começou a varrer carteiras de Bitcoin. Em 25 minutos, 594 BTC — cerca de US$ 38 milhões na época — foram drenados de aproximadamente 500 endereços gerados por carteiras de hardware Coldcard. O ataque não usou phishing, malware ou acesso físico. O invasor explorou uma falha silenciosa no firmware do dispositivo que tornava as chaves privadas dos usuários previsíveis para quem conhecesse a vulnerabilidade. Esse foi apenas o primeiro ato de um roubo que, em menos de uma semana, atingiria US$ 89 milhões e exporia a fragilidade de um dos pilares da segurança em cripto: a geração de números aleatórios.

A anatomia da falha: como um "erro de compilação" anulou a segurança

Em 2021, a Coinkite, fabricante da Coldcard, realizou uma mudança aparentemente inofensiva no código do firmware. Conforme detalhado em um relatório técnico publicado pela Block Bitcoin Engineering em 30 de julho de 2026, a empresa migrou as operações de curva elíptica para a biblioteca libsecp256k1 do Bitcoin Core. Durante essa integração, um erro de configuração no código fez com que a função ngu.random.bytes, responsável por gerar a semente (seed) da carteira, não utilizasse o gerador de números aleatórios de hardware (STM32 RNG). Em vez disso, ela passou a recorrer a um gerador determinístico de fallback do MicroPython, chamado Yasmarang. O erro, segundo o relatório, ocorreu porque uma macro de verificação (MICROPY_HW_ENABLE_RNG) estava configurada como zero, instruindo o sistema a ignorar o hardware seguro.

A implicação prática desse erro é devastadora. Para os modelos mais antigos, Mk2 e Mk3, com firmware entre as versões 4.0.1 (março de 2021) e 4.1.9, a geração de chaves se tornou completamente determinística. Na prática, isso significava que se um atacante conhecesse o identificador único (UID) do dispositivo, o estado do temporizador e o histórico de chamadas da função, ele poderia reproduzir a semente gerada offline e, consequentemente, tomar controle dos fundos. Para os modelos mais recentes — Mk4, Q e Mk5 — a situação era um pouco menos catastrófica, mas ainda grave. Esses dispositivos incluem um elemento seguro que adiciona entropia, mas o erro no firmware limitava essa entropia a apenas 32 bits após um processo de hash, reduzindo o espaço de possibilidades de 2^128 para apenas 2^32 (aproximadamente 4,3 bilhões de combinações). A Coinkite estimou que os modelos Mk2/Mk3 ofereciam apenas 40 bits de entropia efetiva, e os mais novos cerca de 72 bits, em vez dos 128 bits esperados para uma segurança adequada.

O ataque em cadeia: das ondas de 594 BTC ao risco de US$ 130 milhões

O primeiro ataque, em 31 de julho, foi rápido e automatizado. A Galaxy Research, que monitora a blockchain, rastreou a onda inicial e observou que os fundos foram enviados para quatro endereços controlados pelo invasor. A firma alertou publicamente no X (antigo Twitter) que a exploração estava em andamento e aconselhou usuários com carteiras de assinatura única a moverem seus fundos imediatamente. Em 1º de agosto, uma segunda e uma terceira onda de ataques ocorreram. A terceira onda, relatada pela Galaxy Research, drenou 207,73 BTC de 1.912 endereços entre a tarde de sexta-feira e a manhã de sábado, trazendo o total observado para 1.367,05 BTC (aproximadamente US$ 88,6 milhões) de 4.585 endereços.

Os ataques continuaram a evoluir. Relatórios posteriores da Galaxy Research, compilados até 4 de agosto, confirmaram que 1.596 BTC haviam sido roubados de cerca de 7.300 endereços, além de 14 incidentes menores. Uma possível quarta onda de ataques foi identificada, e os analistas estimaram que o prejuízo total poderia atingir 2.055 BTC, ou quase US$ 130 milhões. Um detalhe chamou a atenção dos investigadores: em ondas posteriores, o invasor passou a mirar em carteiras com saldos menores e alterou os métodos de coleta na blockchain. Apesar da escalada, aproximadamente 90% dos fundos roubados permaneceram imóveis após o ataque, o que sugere que o invasor pode estar esperando a poeira baixar ou buscando métodos mais complexos de lavagem.

A resposta da Coinkite e o guia de sobrevivência para usuários afetados

Em resposta à crise, a Coinkite publicou um aviso de segurança atualizado em 1º de agosto de 2026 e lançou versões corrigidas do firmware. A empresa disponibilizou as versões 4.2.0 ou superior para Mk2/Mk3, 5.6.0 ou superior para Mk4/Mk5, e 1.5.0Q ou superior para o modelo Q. A orientação principal era clara: os usuários não deveriam gerar novas sementes até que o firmware atualizado estivesse instalado. A Coinkite também afirmou ter destruído o inventário de dispositivos vulneráveis.

Para os usuários que tinham sementes geradas no firmware problemático, a empresa detalhou dois cenários de exceção. Se o usuário tivesse adicionado 50 ou mais jogadas justas e independentes de dados privados durante a geração da semente, essa entrada manual forneceria pelo menos 128 bits (ou 256 bits para 99 jogadas ou mais) de entropia, tornando a semente não vulnerável apenas pelo problema do RNG. Da mesma forma, o uso de uma frase-senha (passphrase) BIP-39 forte e única adicionava uma barreira de segurança extra, embora a migração permanecesse recomendada. A Coinkite forneceu orientações detalhadas de migração para dispositivos únicos ou múltiplos, enfatizando a importância de realizar transações de teste e manter backups antigos até que a migração fosse confirmada.

As lições forenses: entropia, confiança e a ilusão da autocustódia perfeita

Este incidente levanta questões fundamentais sobre a natureza da segurança em cripto. A autocustódia — o ato de ser seu próprio banco — é vendida como o ápice da soberania financeira digital. No entanto, ela depende de uma cadeia de confiança que começa no código do fabricante. Se um único erro em uma macro de compilação pode anular anos de design de hardware seguro, a responsabilidade do usuário se torna quase impossível de gerir. A falha não estava na criptografia em si (SHA-256, secp256k1), mas na camada de software que alimentava esses algoritmos com dados previsíveis.

A resposta coordenada da indústria — com a Galaxy Research rastreando os fundos e compartilhando cerca de 600 endereços do invasor com autoridades federais, firmas de compliance e investigadores cibernéticos — mostra que a blockchain oferece transparência para o rastreamento. No entanto, a recuperação dos fundos permanece um desafio monumental, especialmente com 90% do valor ainda parado. A falha na Coldcard se junta a uma série de ataques que expõem as vulnerabilidades em pontos de falha únicos, como extensões de navegador comprometidas ou dispositivos físicos falsificados.

O que fazer agora: o próximo passo para quem tem uma Coldcard

Se você possui uma carteira Coldcard, o primeiro passo é verificar a versão do seu firmware. Modelos Mk2/Mk3 com firmware entre 4.0.1 e 4.1.9 são os mais críticos. Mesmo que você tenha um modelo Mk4, Q ou Mk5, a atualização para as versões corrigidas (5.6.0 ou 1.5.0Q, respectivamente) é obrigatória antes de gerar qualquer nova semente. A recomendação da Coinkite é migrar seus fundos para uma semente gerada no firmware atualizado, seguindo suas instruções de migração detalhadas, que incluem testes com pequenas quantias antes de mover todo o saldo. A frágil segurança da autocustódia exige vigilância constante: não basta ter a melhor cadeia do cofre se a fechadura foi instalada com defeito.