Operadores de Bitcoin Lightning com um kernel Linux vulnerável continuam expostos a uma falha crítica, mesmo após atualizarem o LND. As versões v0.20.7-beta e v0.21.6-beta, lançadas em 30 de outubro, desativam por padrão os listeners MPTCP. Com isso, as atualizações fecham a rota demonstrada para explorar a CVE-2026-98432 pelo LND, mas não corrigem o kernel.

A mudança também não protege outros serviços instalados na mesma máquina. Contudo, um único serviço com um listener MPTCP exposto pode manter disponível a rota de ataque já demonstrada. Por isso, os operadores precisam tratar a vulnerabilidade no host, em vez de limitar a resposta ao software do nó de pagamentos.

Falha no Linux ainda ameaça nós do Bitcoin Lightning

A vulnerabilidade envolve o uso de memória liberada durante o processamento de conexões TCP IPv4 no Linux. Em sistemas afetados, um invasor pode explorar a falha para executar código no host. A Ubuntu atribuiu à vulnerabilidade uma pontuação crítica de 9,8 no CVSS 3.1.

As notas para operadores do LND explicam a relação entre a falha e o MPTCP. Desde o Go 1.24, listeners MPTCP ficam ativos por padrão no Linux. Assim, o LND 0.21.x passou a expor o recurso nas portas de pares, gRPC e REST. Essas interfaces atendem às conexões entre nós e às aplicações integradas ao LND.

Exploração demonstrada depende de MPTCP

O alerta da equipe de segurança do Go informa que a exploração demonstrada exige um listener MPTCP exposto. Entretanto, o bug do kernel possui alcance mais amplo e pode permitir ataques semelhantes contra sistemas sem esses listeners. Até agora, o comunicado não confirmou uma exploração que dispense o MPTCP.

Da mesma forma, o Go considera frágil desativar o MPTCP separadamente em cada programa. Basta um listener exposto para manter o host vulnerável à rota de ataque comprovada. Adicionalmente, configurações explícitas de socket podem substituir o padrão definido pelo Go.

Os avisos descrevem uma exploração demonstrada no Linux, mas não relatam ataques contra nós LND ou roubo de Bitcoin. Também não há indicação de que invasores tenham usado a falha contra operadores da rede. Embora a vulnerabilidade tenha afetado validadores de Solana, o problema não se limita a um único protocolo. Já as correções anunciadas em 6 de novembro para o Core Lightning tratavam falhas separadas em canais e comandos remotos.

Correção completa exige atualização do kernel

O rastreador de segurança da Ubuntu recebeu consulta em 9 de novembro e registrava atualização em 7 de novembro. Na consulta, o pacote padrão linux do Ubuntu 24.04 LTS ainda aparecia como vulnerável. Enquanto isso, o trabalho seguia na versão 6.8.0-149.149, e o Ubuntu 22.04 LTS mantinha o mesmo status para 5.15.0-203.213.

Em aviso de 2 de novembro, a Canonical informou que os patches estavam no repositório -proposed. Naquele momento, a opção atendia usuários capazes de executar os próprios testes de aceitação. Portanto, os testes de qualificação continuavam antes da distribuição mais ampla das correções.

Cada pacote de kernel possui um status próprio

Uma nota semanal da Ubuntu indicou que algumas versões, incluindo a 24.04, avançaram para o repositório -updates. Ainda assim, o comunicado não identificou todas as variantes de kernel. Por essa razão, cada operador deve verificar a atualização disponível para o pacote específico instalado no host.

O rastreador mostra essa diferença ao listar como corrigido o pacote padrão linux do Ubuntu 26.10, na versão 7.3.0-10.10. Por outro lado, kernels de nuvem, habilitação de hardware e outras variantes possuem registros separados. Logo, a correção de um pacote não define automaticamente a situação dos demais.

Os mantenedores do LND recomendam atualizar o aplicativo, desativar o MPTCP no host e instalar um kernel corrigido quando ele estiver disponível. Primeiro, a orientação usa o comando sudo sysctl -w net.mptcp.enabled=0 e uma configuração persistente. Depois, o operador deve verificar todos os espaços de nomes de rede relevantes. Como a definição funciona por espaço de nomes, implantações Docker exigem atenção específica à rede dos contêineres.

Quem não puder atualizar o LND imediatamente pode iniciar o binário atual com GODEBUG=multipathtcp=0. Dessa forma, o operador desativa os listeners MPTCP que o Go habilita por padrão. Ainda assim, os mantenedores recomendam não reativar o recurso antes da correção do kernel.

A Canonical orienta verificar o kernel em execução com o comando uname -r. Após instalar a atualização de segurança, o operador precisa reiniciar o sistema. Por último, deve confirmar se o host iniciou com a versão corrigida do kernel. Assim, atualizar o LND e instalar o pacote do sistema permanecem etapas distintas da proteção.

	Receba nossas últimas notícias em primeira mão.   Adicione-nos como sua fonte preferida no Google    e toque em “Favorito” para priorizar nossas atualizações.