Em criptomoedas, existe uma fórmula quase sagrada: "Não confie, verifique." Qualquer usuário pode executar seu próprio nó, checar as regras da rede por si mesmo e não depender nem da equipe de desenvolvimento nem de qualquer autoridade central.
Mas essa fórmula tem uma limitação séria. Por mais cuidadosamente que eu audite o código, não vou detectar uma vulnerabilidade que exija um verdadeiro hacker para ser encontrada — simplesmente não tenho a expertise. Então sou forçado a confiar, de qualquer forma: confiar nas pessoas que checam tudo em meu nome e me dizem o que encontraram.
Em 5 de maio de 2026, os desenvolvedores do Bitcoin Core divulgaram a vulnerabilidade CVE-2024-52911. Ela afetava versões do Bitcoin Core a partir da 0.14.0 e foi corrigida na 29.0. O bug permitia que um minerador causasse um crash remoto nos nós de outras pessoas.
Mas o detalhe mais impressionante aqui é por quanto tempo esse bug foi conhecido. Cory Fields o reportou em privado aos desenvolvedores em 2 de novembro de 2024. Em 6 de novembro de 2024, Pieter Wuille cometeu uma correção oculta. Em 3 de dezembro de 2024, o patch apareceu no repositório oficial sem nenhum anúncio público e foi descrito meramente como "atualizações menores." Em 12 de abril de 2025, o Bitcoin Core 29.0 foi lançado com a correção incluída. A divulgação pública veio apenas em 5 de maio de 2026, depois que o último branch vulnerável, 28.x, atingiu o fim de suporte.
Por um ano e meio, o cliente Bitcoin mais amplamente confiável rodou com uma vulnerabilidade que os desenvolvedores conheciam — enquanto os operadores de nós que executavam esse software não sabiam. E isto não é um incidente isolado; é um padrão recorrente em criptomoeda. Desenvolvedores de diferentes projetos cripto têm feito isso há anos.
Quero percorrer outros exemplos dessa mesma prática e, por fim, responder à pergunta: quão seguro é, realmente, manter suas economias em criptomoedas?
Bitcoin: Como um bug de DoS se revelou um bug de inflação
Em setembro de 2018, o Bitcoin Core lançou às pressas a versão 0.16.3. Os usuários foram informados de que ela corrigia uma vulnerabilidade de negação de serviço.
Dois dias depois, descobriu-se que isso era apenas metade da história. A mesma falha nas versões 0.15.x e 0.16.x poderia permitir que um minerador inflasse a oferta de bitcoin — efetivamente gastando a mesma saída duas vezes dentro de um único bloco e embolsando BTC extras. Os desenvolvedores reconheceram que inicialmente haviam divulgado apenas o componente menos perigoso, o DoS, retendo deliberadamente a descrição completa da ameaça de inflação para dar tempo a mineradores, empresas e outros participantes críticos de atualizar.
No pior cenário, isso teria sido um ataque não a uma carteira individual, mas à promessa central do Bitcoin: oferta fixa. Se a regra dos 21 milhões pode ser quebrada por um bug no cliente, toda a mitologia econômica do Bitcoin desmorona.
A vulnerabilidade nunca foi explorada. Mas a CVE-2018-17144 ilustra perfeitamente o dilema ético. Por um lado, a divulgação imediata e completa poderia ter entregado aos atacantes um roteiro pronto. Por outro, os usuários não foram efetivamente informados da gravidade da atualização.
Zcash: Moedas falsificadas invisíveis
A história da Zcash foi ainda mais inquietante, porque esta é uma moeda focada em privacidade onde nem tudo é visível na blockchain. Em 2018, a equipe descobriu uma vulnerabilidade na criptografia subjacente às suas provas de conhecimento zero. Antes de ser corrigida, um atacante poderia ter criado ZEC falsos de uma forma que ninguém conseguiria detectar. Com uma cadeia transparente, um bug de inflação é pelo menos teoricamente visível por análise de saldos; um sistema de privacidade torna esse tipo de verificação muito mais difícil.
A Zcash corrigiu o problema na atualização Sapling, ativada em 28 de outubro de 2018, e só divulgou publicamente meses depois. Na divulgação oficial, a equipe escreveu claramente: "há onze meses descobrimos uma vulnerabilidade" — e reconheceu que, antes da correção, um atacante poderia ter cunhado Zcash falsificado sem detecção.
O argumento pela silêncio aqui é fácil de entender. Divulgar essa falha antes de ela ser corrigida teria sido entregar a alguém uma receita para destruir a Zcash. Mas o outro lado é igualmente claro: por quase um ano, os usuários detinham um ativo no qual a falsificação invisível era teoricamente possível — e eles não tinham ideia.
Isto aponta para um paradoxo real:
- Quanto mais séria a vulnerabilidade, mais forte o argumento pela secretização.
- Mas quanto maior a secretização, mais isso mina a ideia de verificabilidade. (Qual é o ponto de "verificar tudo" se eu não tenho as habilidades para entender o que estou vendo, e os auditores qualificados não me dizem o que encontraram?)
Monero: A verdade escondida por trás de um DoS inexistente
Em 2017, o Monero enfrentou uma ameaça similar. A equipe descobriu um bug crítico no CryptoNote, o protocolo base que alimenta o Monero e várias outras moedas de privacidade. A vulnerabilidade permitia a criação de um número ilimitado de moedas de uma forma que teria sido invisível para qualquer observador que não soubesse exatamente o que procurar.
O patch no Monero foi introduzido de forma encoberta. Além disso, o lançamento foi explicado publicamente como proteção contra um ataque de negação de serviço no RingCT — um ataque que, segundo a própria equipe admitiu posteriormente, na verdade nunca existiu. Foi uma história de cobertura, construída para levar exchanges e pools de mineração a atualizar sem revelar o real risco inflacionário.
Para o Monero, a história terminou bem: a equipe relatou ter verificado a blockchain e não encontrado sinais de exploração. Mas a vulnerabilidade ia além do Monero. Depois que o Monero atualizou, a equipe começou a notificar outros projetos baseados em CryptoNote. Mas um deles, o Bytecoin, foi em breve atacado, e 693 milhões de moedas adicionais foram criadas nele.
Isto abre outra camada do problema de manter vulnerabilidades em segredo. Quando o código é compartilhado entre dezenas de projetos, anunciar uma ameaça descoberta em um lugar pode se tornar uma dica para atacantes que miram outro projeto. Desenvolvedores têm que decidir não apenas quando alertar seus próprios usuários, mas quais projetos concorrentes avisar e em que ordem — sabendo que um concorrente que recebe a informação primeiro pode potencialmente usá-la contra um que ainda não recebeu.
Monero novamente: O bug que permitia a atacantes queimar o dinheiro de outras pessoas
Em 2018, o Monero enfrentou um incidente diferente, menos fundamental — mas altamente instrutivo — conhecido como o burning bug. Ele não permitia que alguém imprimisse XMR do nada nem quebrasse o cronograma de oferta. Mas permitia que um atacante causasse prejuízo financeiro real a exchanges, comerciantes e outros serviços. O bug tornava possível enviar fundos de modo que algumas das saídas recebidas se tornassem impossíveis de gastar.
Um serviço de swap como o rabbit.io poderia ter sido vulnerável a tal ataque.
Veja como funcionam os swaps de criptomoeda no rabbit.io:
- um usuário envia criptomoeda, por exemplo XMR, para o endereço de depósito exibido no formulário do pedido;
- nosso sistema automatizado detecta o pagamento recebido e envia a criptomoeda solicitada para o endereço de pagamento especificado pelo usuário.
Nosso serviço não existia na época, mas se existisse, o ataque poderia ter sido assim:
- um atacante cria um pedido para trocar XMR por BTC;
- o atacante envia XMR e recebe BTC;
- ficamos sem o BTC e sem o XMR porque as saídas de XMR recebidas são inutilizáveis;
- o atacante não ganha nada diretamente, mas destrói os negócios que aceitam XMR.
A equipe do Monero preparou um patch silencioso e notificou diretamente as exchanges e comerciantes de XMR que conseguiram alcançar. No post-mortem, os desenvolvedores reconheceram honestamente que essa abordagem inevitavelmente deixou de fora organizações com as quais não tinham contato e criou a impressão de acesso privilegiado à informação.
Esta é a realidade prática da divulgação seletiva: alguns participantes do mercado sempre ficarão sabendo de um risco antes de outros. Essa assimetria é, por si só, um problema de segurança.
Stellar: Um bug oculto que já havia sido explorado
A história da Stellar difere da maioria das outras porque o bug não estava apenas silenciosamente presente, desconhecido por todos exceto os desenvolvedores. Ele já havia sido usado.
Em 2017, um atacante explorou uma falha de concorrência no protocolo Stellar e criou 2,25 bilhões de XLM — aproximadamente US$10 milhões na época, e cerca de um quarto de todos os tokens em circulação. Segundo a Messari, o XLM recém-criado foi transferido para exchanges e presumivelmente vendido.
A Stellar Development Foundation posteriormente queimou uma quantidade equivalente de XLM de suas próprias reservas para evitar a diluição da oferta. Mas não fez nenhum anúncio público — até que a Messari trouxe o incidente à tona em 2019, dois anos depois dos fatos. Em resposta, representantes da Stellar disseram que haviam mencionado o bug nas notas de atualização do protocolo. Tecnicamente, isso não é silêncio completo. Mas uma entrada discreta nas notas técnicas que o mercado só conheceu após uma investigação da Messari dois anos depois é, na prática, silêncio.
Este caso é particularmente desconfortável para a indústria. Não se pode dizer: "Mantivemos a vulnerabilidade em segredo para que ninguém pudesse explorá-la." Alguém já a havia explorado. O silêncio não protegeu os usuários de um ataque — protegia os desenvolvedores do escrutínio.
Ethereum Geth: Como um patch silencioso dividiu a rede
No Geth, o cliente Ethereum mais usado, a prática de patchs silenciosos foi essencialmente formalizada. A documentação da equipe afirma explicitamente que, para vulnerabilidades que ameaçam a saúde da mainnet Ethereum, ela se reserva o direito de lançar correções silenciosamente em novas releases sem divulgar as vulnerabilidades. O raciocínio é simples: operadores de nós podem ficar semanas ou meses sem atualizar, e se você explicar exatamente qual bug uma release corrige, alguém pode tentar explorá-lo mais rápido do que a maioria dos nós pode ser atualizada.
Mas em agosto de 2021, essa lógica se voltou contra eles. O Geth corrigiu a CVE-2021-39137, liberando a correção em 24 de agosto sem divulgar detalhes. Alguém, no entanto, descobriu o que havia sido consertado — e em 27 de agosto, a vulnerabilidade foi explorada, fazendo com que uma porção de nós Geth mais antigos bifurcasse da cadeia principal.
Este é o outro lado da lâmina do segredo. Diga demais, e você pode acelerar um ataque. Diga de menos, e alguns operadores não entenderão que a atualização é urgente. A rede pode acabar exatamente com o que tentava evitar: exploração ativa da vulnerabilidade.
Polygon: US$24 bilhões em risco, perdas reais incorridas
Em dezembro de 2021, a Polygon enfrentou o mesmo dilema. Pesquisadores de segurança reportaram uma vulnerabilidade crítica no contrato gênese PoS da Polygon — uma que poderia permitir a um atacante drenar aproximadamente US$24 bilhões em tokens MATIC. A equipe decidiu proceder em sigilo: como disseram depois, "dada a natureza desta atualização, ela precisava ser executada sem atrair muita atenção." Validadores e operadores de nós completos foram notificados, e a rede atualizou rapidamente.
Mas mesmo uma resposta rápida não foi suficiente para fechar totalmente a janela. Antes que a atualização entrasse em vigor, um atacante conseguiu roubar 801.601 MATIC — pouco menos de US$2 milhões. Os desenvolvedores confirmaram que a Polygon Foundation cobriria a perda. Os pesquisadores que reportaram a vulnerabilidade foram remunerados em aproximadamente US$3,46 milhões em recompensas de bug bounty.
A equipe não tentou enterrar o problema, mas os usuários souberam da escala completa do que quase aconteceu apenas depois que tudo acabou. Duas razões guiaram a abordagem: primeiro, a prioridade era agir, não deliberar; segundo, antes de o problema ser resolvido, cada pessoa adicional que soubesse dele seria alguém que poderia potencialmente abusar desse conhecimento.
Talvez este seja o compromisso razoável: não divulgar um ataque antes que ele seja corrigido, mas também não transformar a correção em um segredo que dure meses ou anos.
Os desenvolvedores estão protegendo os usuários ou enganando-os?
Às vezes o sigilo realmente salva a rede. Sem um conserto silencioso, a Zcash poderia ter sofrido inflação invisível. Sem um patch encoberto, o Monero poderia ter enfrentado falsificação indetectável. Sem a ação rápida e fechada da Polygon, o dano potencial àquela rede teria sido incomparavelmente maior.
Mas o sigilo não é de graça. Ele cria camadas de insiders e outsiders. Dá vantagem a quem a equipe consegue avisar em privado. Reduz a urgência dos operadores de nós para atualizar quando uma release parece manutenção rotineira. E mina uma das bases psicológicas mais importantes do uso de criptomoedas — a sensação de que as regras do jogo são igualmente conhecidas por todos ao mesmo tempo.
Essa sensação, ao que parece, é uma ilusão. Cada uma dessas histórias segue o mesmo arco: um patch silencioso, um longo silêncio e então a admissão de que, o tempo todo, a segurança da rede repousava na confiança em um pequeno grupo de pessoas que sabiam mais do que todo mundo.
