Os atacantes passaram a sexta-feira esvaziando silenciosamente nós Lightning ligados ao BTCPay Server, o processador de pagamentos em bitcoin auto-hospedado, depois que o projeto confirmou que uma vulnerabilidade crítica no BTCPay Server estava sendo explorada ativamente. A fabricante de carteiras de hardware Foundation e o zine de bitcoin Citadel21 relataram nós drenados, algumas horas antes de o próprio alerta público do BTCPay ser divulgado. O incidente, revelado em 7 de agosto de 2026, obrigou comerciantes, corretoras e backends de carteiras que executam o software a correr atrás de uma correção enquanto os roubos ainda estavam em andamento.
Summary
Pontos principais
- O BTCPay Server confirmou uma vulnerabilidade crítica, explorada ativamente, e lançou a versão 2.4.2 para corrigi-la em 7 de agosto de 2026.
- A fabricante de carteiras de hardware Foundation e o zine de bitcoin Citadel21 tiveram nós Lightning esvaziados, com canais forçados a fechar e fundos drenados.
- O fundador Nicolas Dorier disse que o bug só foi encontrado porque um desenvolvedor, Craig Raw da Sparrow Wallet, perdeu fundos e analisou os logs — não por meio de auditorias assistidas por IA.
- O BTCPay é auto-hospedado, o que significa que não há um operador central para aplicar o patch em nome dos usuários; cada proprietário de servidor deve atualizar individualmente.
- Os usuários são orientados a atualizar macaroons e arquivos de credenciais após aplicar o patch, já que credenciais roubadas ainda podem conceder acesso mesmo depois da atualização.
Vulnerabilidade crítica explorada em nós Lightning do BTCPay Server
O problema central é simples, mas grave: uma falha no BTCPay Server permitia que atacantes acessassem e esvaziassem nós Lightning sem precisar violar separadamente a carteira quente do usuário. O BTCPay publicou um aviso urgente às 11h51 (horário da Costa Leste dos EUA) dizendo: “Há uma vulnerabilidade crítica sendo explorada ativamente no BTCPay Server, que pode resultar em perda de fundos.” O projeto orientou os comerciantes a atualizar imediatamente ou desligar seus servidores se não pudessem aplicar o patch na hora. Essa publicação teria ultrapassado 550.000 visualizações em cinco horas, um sinal de quão rápido o alarme se espalhou pela comunidade de pagamentos em bitcoin.
Visão geral do incidente e lançamento do patch
Dorier, fundador do BTCPay, publicou a versão 2.4.2 na mesma manhã com um alerta direto no topo das notas de versão: “Esta versão contém a correção de uma vulnerabilidade crítica que está sendo explorada ativamente. Você precisa atualizar o mais rápido possível.” Os integradores também foram orientados a atualizar o NBXplorer, o backend de rastreamento de carteiras do BTCPay, para a versão 2.6.10. A versão também limita a taxa de criação pública de faturas em solicitações de pagamento e marca nove métodos de controller em cinco arquivos como não roteáveis, fechando endpoints que estavam acessíveis via HTTP por acidente.
Usuários afetados e detalhes do impacto
Segundo Zach Herbert, CEO da Foundation (empresa produtora da carteira de hardware Passport), o seu nó já havia desaparecido antes mesmo de ver o alerta. “Nosso nó da Foundation foi drenado durante a noite por atacantes”, escreveu ele, esclarecendo depois que apenas o nó Lightning usado para processamento de pagamentos foi atingido — a carteira quente da empresa não foi tocada, mas “todos os canais foram fechados e os fundos foram esvaziados.” hodlonaut, o comentarista pseudônimo por trás do Citadel21, relatou o mesmo padrão, escrevendo que o nó Lightning do zine “acabou de ser esvaziado”, embora tenha observado que não havia fundos significativos em jogo. Pelo menos outro operador descreveu canais fechados e saldos drenados em respostas ao alerta do BTCPay. Nem Herbert nem hodlonaut divulgaram valores exatos, e nenhum balanço agregado de nós afetados ou de total de bitcoin perdido foi publicado.
Descoberta e natureza da vulnerabilidade
Essa falha não foi detectada por varreduras automatizadas — ela só veio à tona depois que alguém foi roubado. Esse detalhe é importante porque expõe uma lacuna entre como as ferramentas de segurança do bitcoin deveriam funcionar e como esse bug específico acabou sendo encontrado.
Descoberta liderada por desenvolvedor vs auditorias com IA
Dorier atribuiu a Craig Raw, o desenvolvedor por trás da Sparrow Wallet, o mérito de juntar as peças do que estava acontecendo depois que seus próprios fundos foram afetados. “Tivemos uma sorte extrema de que um dev foi impactado e pôde analisar os logs para entender o que estava acontecendo”, escreveu Dorier. “De alguma forma, isso não foi encontrado por varreduras de IA, mas por ele perder dinheiro.” A admissão é notável dado que o Bitcoin Red Team — um grupo voluntário que o BTCPay agradeceu pela divulgação — havia passado a semana anterior realizando auditorias assistidas por IA em todo o stack open source do bitcoin. Dorier confirmou que as varreduras do grupo não detectaram esse bug específico. “O relatório de IA que recebemos do red team não incluía este”, disse ele. “Mas esse bug era realmente sorrateiro, não me surpreende que uma varredura simples não o tenha encontrado ou tenha achado que era de baixo risco.”
Esclarecimento sobre diferenças entre bugs
O BTCPay não detalhou qual falha os atacantes exploraram, mas Dorier foi explícito ao dizer que não se trata da quebra de autenticação em duas etapas já listada no changelog do projeto. Depois que um usuário publicou uma explicação gerada por IA atribuindo o ataque a esse bug divulgado, Dorier corrigiu o registro: “Esse bug foi encontrado pelo Red team, este não é o bug crítico em questão.” A quebra de 2FA divulgada afetava o Greenfield, a API do BTCPay, e foi corrigida em 4 de agosto — ela permitia que contas protegidas por um app autenticador fossem acessadas apenas com e-mail e senha, embora a tela de login do navegador aplicasse corretamente o 2FA o tempo todo. Um relatório técnico completo sobre a vulnerabilidade explorada ativamente ainda está pendente. O colaborador principal Uncle Rockstar disse que a equipe está “trabalhando com o Bitcoin Red Team para processar totalmente os detalhes da vulnerabilidade e em breve publicará um post técnico detalhado.”
Desafios operacionais e etapas de remediação
Aplicar o patch no software é apenas metade do trabalho — e essa divisão de responsabilidades é onde este incidente revela uma fragilidade estrutural em como a infraestrutura de bitcoin auto-hospedada é protegida.
Responsabilidade de patch em software auto-hospedado
Como o BTCPay é auto-hospedado, não há um operador central que possa aplicar uma correção em todas as implantações de uma vez. Cada comerciante, corretora e carteira que executa o software precisa aplicar a atualização em sua própria máquina — e, neste caso, os roubos já estavam em andamento antes que a maioria dos usuários sequer visse o alerta. Esse é um trade-off definidor da infraestrutura auto-hospedada: ela remove um ponto único de falha para censura ou desligamento, mas também significa que um patch crítico só protege os operadores que agirem rápido o suficiente para instalá-lo.
Atualização de credenciais e riscos contínuos de segurança
Atualizar o software não fecha automaticamente a porta atrás de um atacante que já entrou. O BTCPay orientou os usuários a executar uma atualização completa dos macaroons e do arquivo macaroons.db — os arquivos de credenciais que permitem o acesso a um nó Lightning LND — bem como renovar as strings de autenticação para outros backends Lightning. Quem tivesse gerado uma carteira quente on-chain dentro do BTCPay foi orientado a mover esses fundos e recriar a carteira do zero. Kaloudis, representante da carteira ZEUS baseada em LND, expôs o risco de forma direta: “Não presuma que você está seguro depois de atualizar.” Macaroons roubados sobrevivem a uma atualização de software, o que significa que um atacante que copiou credenciais antes do patch mantém o acesso ao nó até que esses arquivos sejam destruídos e reemitidos — o que condiz com o que as vítimas descreveram: canais forçados a fechar e saldos esvaziados, em vez de o próprio servidor ser violado uma segunda vez.
Contexto das recentes falhas de segurança em infraestrutura de Bitcoin
Esse alerta não surgiu isoladamente. Ele chegou nove dias após o início de um dos períodos mais difíceis para a segurança da infraestrutura de bitcoin na memória recente, e esse timing levanta uma questão maior sobre se as ferramentas criadas para detectar esses bugs estão acompanhando o ritmo do software que está sendo lançado.
Incidentes paralelos em hardware e serviços de Bitcoin
Um bug de firmware da Coldcard de 2021, que roteava a geração de seeds por um randomizador de software fraco, drenou cerca de US$ 114 milhões em BTC desde 30 de julho, atingindo mais de 5.200 endereços, com algumas vítimas relatando a perda de economias de uma vida inteira. Depois, em 3 de agosto, a ponte de swaps Boltz interrompeu seu serviço por tempo indeterminado, dizendo que os atacantes “agora iteram mais rápido do que uma equipe do nosso tamanho consegue encontrar e corrigir.” A vulnerabilidade do BTCPay Server é a terceira falha de segurança significativa a atingir infraestrutura adjacente ao bitcoin em menos de duas semanas.
Limitações da auditoria do Bitcoin Red Team
O próprio Bitcoin Red Team se formou em resposta direta ao incidente da Coldcard, e sua produção inicial tem sido substancial: Calle, que ajuda a liderar o grupo, disse que 16 pesquisadores registraram 4.962 achados em 390 projetos em apenas 27,5 horas, incluindo 85 problemas críticos e 635 de alta gravidade. Ainda assim, as varreduras assistidas por IA do grupo não detectaram exatamente o bug que agora está sendo explorado contra usuários do BTCPay — uma lacuna que Dorier reconheceu diretamente. Essa falha ressalta um desafio mais amplo para o setor: ferramentas de segurança automatizadas podem gerar volume, mas bugs sorrateiros de lógica ainda podem exigir um humano, às vezes alguém que já perdeu dinheiro, para captar o que uma varredura deixa passar.
O próprio bitcoin não mostrou qualquer reação a nada disso. O ativo foi negociado perto de US$ 64.800 na tarde de sexta-feira, alta de 0,7% em 24 horas e de 2,6% na semana, segundo a CoinGecko — um lembrete de que falhas de segurança em nível de infraestrutura no ecossistema bitcoin não necessariamente movem o preço do ativo em torno do qual são construídas, mesmo quando as perdas são reais e não resolvidas.
Perguntas frequentes
Qual foi o principal problema com o BTCPay Server em 7 de agosto de 2026?
Uma vulnerabilidade crítica foi explorada ativamente, permitindo que atacantes drenassem nós Lightning de usuários, o que levou o BTCPay a emitir um patch urgente e orientar os operadores a atualizar imediatamente ou desligar seus servidores.
Quem foram algumas das vítimas específicas afetadas pela vulnerabilidade do BTCPay Server?
Vítimas notáveis incluíram a fabricante de carteiras de hardware Foundation, cujo nó de pagamentos ligado ao Passport foi drenado durante a noite, e o zine de bitcoin Citadel21, cujo nó Lightning foi esvaziado com seus canais forçados a fechar.
A vulnerabilidade explorada é a mesma que a quebra de autenticação em duas etapas divulgada anteriormente?
Não. O fundador do BTCPay, Nicolas Dorier, esclareceu que o bug explorado ativamente é diferente e não está relacionado à quebra de autenticação em duas etapas já divulgada no changelog do projeto e corrigida em 4 de agosto.
O que os usuários do BTCPay Server devem fazer após aplicar o patch?
Os usuários devem atualizar macaroons e arquivos de credenciais, já que credenciais roubadas podem sobreviver a uma atualização de software e continuar concedendo aos atacantes acesso não autorizado a nós Lightning mesmo após o patch.
{“@context”:”https://schema.org”,”@type”:”FAQPage”,”mainEntity”:[{“@type”:”Question”,”name”:”Qual foi o principal problema com o BTCPay Server em 7 de agosto de 2026?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”Uma vulnerabilidade crítica foi explorada ativamente, permitindo que atacantes drenassem nós Lightning de usuários, o que levou o BTCPay a emitir um patch urgente e orientar os operadores a atualizar imediatamente ou desligar seus servidores.”}},{“@type”:”Question”,”name”:”Quem foram algumas das vítimas específicas afetadas pela vulnerabilidade do BTCPay Server?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”Vítimas notáveis incluíram a fabricante de carteiras de hardware Foundation, cujo nó de pagamentos ligado ao Passport foi drenado durante a noite, e o zine de bitcoin Citadel21, cujo nó Lightning foi esvaziado com seus canais forçados a fechar.”}},{“@type”:”Question”,”name”:”A vulnerabilidade explorada é a mesma que a quebra de autenticação em duas etapas divulgada anteriormente?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”Não. O fundador do BTCPay, Nicolas Dorier, esclareceu que o bug explorado ativamente é diferente e não está relacionado à quebra de autenticação em duas etapas já divulgada no changelog do projeto e corrigida em 4 de agosto.”}},{“@type”:”Question”,”name”:”O que os usuários do BTCPay Server devem fazer após aplicar o patch?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”Os usuários devem atualizar macaroons e arquivos de credenciais, já que credenciais roubadas podem sobreviver a uma atualização de software e continuar concedendo aos atacantes acesso não autorizado a nós Lightning mesmo após o patch.”}}]}
Artigo produzido com a assistência de inteligência artificial e revisado pela equipe editorial.
