Conclusão à primeira vista: para os nós de comerciantes do BTCPay, recomenda-se atualizar o mais rápido possível para a versão 2.4.4 e retirar as rotas do LND que você mesmo reexpôs manualmente — a equipe oficial já viu que robôs estão varrendo a janela de reinício para chamadas de API de troca de senha.

Segundo o blog oficial do BTCPay Server (aprox. 2026-09-08): a implantação padrão via Docker já desativou a API externa do LND; mas ainda há quem a reexponha manualmente. O robô chama repetidamente `/lnd-rest/btc/v1/changepassword`. Enquanto a carteira ainda estiver bloqueada, essa rota pode funcionar sem macaroon; versões antigas ainda usaram senhas padrão compartilhadas. Após reiniciar o LND, existe uma pequena janela entre o momento em que o unlocker interno se conecta e antes que esteja tudo seguro; se um atacante enviar antes uma senha conhecida, ele pode alterar a senha e depois exigir/obter o macaroon de admin, controlando o nó. Duas melhorias na 2.4.4: use uma senha aleatória e exclusiva para novas carteiras (a senha padrão antiga é migrada automaticamente), e na camada de proxy reverso bloqueie as rotas de configuração/ desbloqueio do wallet não autenticado. A documentação oficial afirma: não foi reportado sucesso no sequestro dos nós por essa rodada de detecção.

Revisão independente: CryptoSlate (2026-09-13) reitera com o mesmo entendimento — o alvo são nós que reexponham manualmente a rota; a 2.4.4 (lançada por volta de 07/09) trata esse caminho; e a mudança de controle de rotas mesclada por volta de 11/09 exige que o acesso remoto seja explicitamente habilitado, mantendo padrão fechado as interfaces externas do LND/ Core Lightning. Verifique também quaisquer proxies/reverse proxies personalizados.

Figura é um diagrama/gerado por IA, não é uma captura de console oficial.
Dados até: blog do BTCPay (aprox. 2026-09-08); CryptoSlate (2026-09-13).
Apenas para compartilhamento de informações, não constitui recomendação de investimento.
#Lightning #bitcoin