O projeto BTCPay Server publicou em 2 de novembro de 2026 um alerta de incidente de segurança: desde 1º de novembro, administradores relataram roubo de bitcoin e litecoin de hot wallets em servidores que rodavam a versão 2.4.1 ou anterior. Instâncias já atualizadas para a 2.4.2 ou superior não tiveram impacto, segundo o comunicado.
O ponto que mais pegou os administradores de surpresa está na orientação oficial: para quem estava em versão vulnerável, atualizar não basta. O comunicado do BTCPay Server recomenda criar carteira nova, migrar fundos e subir o servidor do zero.
Qual versão está rodando no seu painel
A versão aparece no rodapé do painel do BTCPay. A correção da falha original saiu na 2.4.2, em 7 de agosto de 2026, e depois vieram outras atualizações de segurança, como a 2.4.4 e a 2.4.5. O projeto recomenda instalar a release mais recente disponível, e não parar na 2.4.2.
De acordo com o TechCripto, relatórios independentes associam o ataque às credenciais de administração do nó Lightning, que dão controle total sobre os fundos quando caem em mãos erradas. O comunicado oficial fala em credenciais Lightning de forma genérica e não detalha o vetor. Também não se sabe quando a exploração começou.
Servidor próprio com hot wallet na 2.4.1 ou anterior
É o perfil de maior risco. Se as chaves de gasto estão no próprio servidor, assuma que podem ter sido copiadas, mesmo que o saldo pareça intacto. O roteiro do projeto, em ordem:
- Gere uma carteira nova, com seed nova, em um dispositivo confiável que nunca teve acesso ao servidor antigo.
- Transfira o saldo restante da hot wallet antiga para a carteira nova.
- Desligue o servidor antigo, sem apagá-lo, preservando logs e histórico de transações para auditoria.
- Crie uma máquina virtual nova com a versão mais recente do BTCPay e conecte a carteira nova. Não restaure o servidor antigo inteiro a partir de backup.
- Revogue e substitua todas as credenciais que o servidor antigo alcançava: painel da hospedagem, chaves SSH, senhas da aplicação, chaves de API e credenciais Lightning.
Hardware wallet ou carteira só de observação
Lojas que conectam ao BTCPay uma carteira cujas chaves ficam fora do servidor, como uma hardware wallet usada apenas para receber, não foram afetadas pelo roubo, de acordo com o projeto. O servidor guarda só a chave pública, que permite gerar endereços, mas não gastar.
Isso não dispensa a atualização. Um servidor desatualizado continua exposto a falhas corrigidas nas versões seguintes, como a 2.4.4 e a 2.4.5. Atualize para a release mais recente e revise os acessos ao painel.
Instância em provedor de hospedagem
Quem usa BTCPay hospedado por terceiros também está no grupo afetado se a instância estava na 2.4.1 ou anterior. Alguns provedores, como a LunaNode, desligaram instâncias por precaução, segundo o comunicado.
- Entre em contato com o provedor para migrar para uma VM nova, em vez de esperar a religação da antiga.
- Pergunte quais logs foram preservados e por quanto tempo.
- Troque a senha da conta no provedor e ative autenticação em dois fatores.
Lightning, chaves e segredos: o que tratar como comprometido
Para quem registrou roubo ou qualquer sinal de acesso indevido, a orientação é tratar a máquina inteira e todos os segredos que ela continha como comprometidos. Isso inclui arquivos de configuração com tokens de integração (lojas WooCommerce, Shopify ou APIs próprias) e credenciais do nó Lightning.
Preciso fechar meus canais Lightning?
O comunicado não traz instrução específica sobre canais. Se as credenciais de administração do nó podem ter vazado, o caminho mais seguro é mover os fundos para um nó novo, com credenciais novas, e só depois decidir o que fazer com os canais antigos.
Para quem está montando a defesa da operação do zero, reunimos práticas gerais no texto sobre soluções de segurança para blockchain.
Roteiro de decisão para administradores
Se você roda BTCPay e não sabe em qual versão estava em 1º de novembro, trate a instância como vulnerável e siga o roteiro completo de migração. Se você já estava na 2.4.2 ou acima e as chaves ficam fora do servidor, atualize para a última release e revise acessos. Se você teve perda confirmada, preserve os registros antes de qualquer mudança, porque eles serão a base de qualquer investigação.
