BTCPay Server lançou a versão 2.4.2 em regime de emergência para conter uma vulnerabilidade crítica que já estava sendo explorada ativamente e permitia o roubo de fundos em nós da rede Lightning, qualquer instalação anterior ao patch continuava exposta enquanto o ataque ocorria.
A seguir:
- Como a falha funcionava e por que nós Lightning foram os alvos
- Os passos exatos recomendados para proteger sua instalação
- O contexto de ataques à infraestrutura Bitcoin que dá dimensão ao caso
A vulnerabilidade residia na autenticação básica da API Greenfield. Contas protegidas por TOTP, o segundo fator baseado em senha descartável, podiam ter esse mecanismo contornado por um atacante remoto não autenticado.
Com isso, o invasor conseguia acessar os arquivos .macaroon dos nós Lightning, as credenciais que autorizam operações no nó, e utilizá-los para mover fundos sem qualquer interação da vítima.
Carteiras on-chain padrão não foram afetadas pela brecha. O vetor de ataque era restrito ao fluxo de autenticação da API combinado com a presença de um nó Lightning vinculado à instância do BTCPay Server.
Comerciantes e operadores que processam pagamentos Lightning com versões anteriores à 2.4.2 estavam diretamente no caminho do exploit enquanto ele ocorria.
A equipe do BTCPay Server confirmou que a falha já estava sendo ativamente explorada no momento do disclosure, o que motivou o caráter emergencial do lançamento. O projeto publicou orientações detalhadas no blog oficial para guiar administradores na resposta imediata.
Como aplicar o patch e o que fazer se não for possível
O caminho direto para a correção passa pelo Painel de Administração: acesse Servidor, depois Manutenção e clique em Atualizar. Após o processo, verifique o rodapé da interface: se a versão exibida for 2.4.2, a atualização foi concluída com êxito.
Para quem não puder aplicar o update imediatamente, a recomendação é desligar o BTCPay Server até que a janela de manutenção esteja disponível. Manter a instância rodando com versões vulneráveis equivale a deixar os arquivos de credenciais do nó acessíveis a atacantes externos.
Além da atualização do software principal, o projeto instrui os administradores a regenerar os arquivos macaroons e macaroons.db, que podem ter sido comprometidos antes da aplicação do patch. Atualizar o NBXplorer para a versão 2.6.10 também faz parte do conjunto de ações recomendadas.
Por último, o BTCPay Server orienta a migrar de autenticação básica para chaves de API com escopo definido, prática que limita o raio de dano em casos de credencial exposta.
Por que o ataque funcionou e o que ele revela sobre a segurança de comerciantes
O modelo de autenticação básica da API Greenfield foi projetado para facilitar integrações, mas a combinação com TOTP criou uma brecha no fluxo de verificação.
Quando um atacante enviava requisições via autenticação básica, o sistema não exigia o segundo fator, abrindo caminho para acesso às credenciais do nó sem passar pela camada adicional de proteção.
O uso de macaroons como mecanismo de autorização no nó Lightning é padrão na implementação LND. Quem detém esses arquivos pode emitir comandos ao nó com o nível de permissão que o macaroon carrega, incluindo saques.
A exploração, portanto, não precisava de engenharia social nem de malware no dispositivo da vítima: bastava acessar o arquivo remotamente pela API comprometida.
O caso expõe um risco específico do lado do comerciante: operadores que aceitam Lightning em produção precisam de um nó sempre conectado, o que amplia a superfície de ataque em comparação com uma carteira cold storage.
A versão 2.4.4, divulgada pelo BTCPay Server como atualização de segurança, também foi publicada no mesmo ciclo, indicando que a equipe está em modo de resposta acelerada.
Um padrão de ataques à infraestrutura Bitcoin
Este incidente não é isolado. A infraestrutura de pagamento em Bitcoin passou por uma sequência de pressão de segurança que coloca operadores e usuários em alerta contínuo.
A mudança na política de segurança do Bitcoin Core motivada por bugs encontrados por IA mostra que as ferramentas de varredura automática de vulnerabilidades estão acelerando a descoberta de falhas em toda a cadeia de software Bitcoin, forçando projetos a encurtar os ciclos de resposta.
Ferramentas de IA capazes de analisar código em escala têm sido apontadas como fator que eleva a pressão sobre equipes de desenvolvimento de projetos open source.
O BTCPay Server é mantido por uma equipe pequena de contribuidores voluntários e profissionais, o que torna cada janela entre a descoberta e o patch um intervalo de risco real para milhares de comerciantes ao redor do mundo que dependem da plataforma para processar pagamentos em Bitcoin.
A série de falhas críticas no PHP que expuseram projetos cripto seguiu a mesma lógica de ataque a dependências de infraestrutura amplamente usadas. No BTCPay, o vetor foi a própria API de integração, projetada para abrir o sistema a terceiros e, por isso, especialmente sensível a erros de autenticação.
Operadores que ainda não aplicaram o update têm uma janela de risco ativa. A recomendação permanece: atualizar para a versão 2.4.2 ou superior imediatamente, regenerar as credenciais do nó e substituir autenticação básica por chaves de API com escopo restrito.
Perguntas frequentes
Minha carteira Bitcoin comum está em risco por causa dessa falha?
Não. A vulnerabilidade afeta exclusivamente nós Lightning conectados a instâncias do BTCPay Server em versões anteriores à 2.4.2. Carteiras on-chain padrão não foram impactadas pela brecha, nem usuários que não operam o BTCPay Server.
Se eu já fui afetado antes de aplicar o patch, perco os fundos permanentemente?
Fundos movidos por um atacante via macaroon comprometido não são automaticamente recuperáveis, pois transações Lightning liquidadas são irreversíveis. Por isso o projeto recomenda regenerar os arquivos macaroon mesmo após o update, para revogar credenciais que possam ter sido copiadas antes da correção.
Qual versão exata devo ter instalada para estar protegido?
A versão 2.4.2 fecha a vulnerabilidade descrita. O BTCPay Server também lançou a 2.4.4 no mesmo ciclo de resposta de segurança. Atualizar para a versão mais recente disponível e verificar o número no rodapé da interface é o procedimento recomendado pelo projeto.
