CVE-2026-98432: quando esperar por uma correção do kernel se torna uma preocupação

#Por que a espera é importante

Um aplicativo continua respondendo. Seus certificados são válidos. As implantações foram bem-sucedidas. Nenhum desses resultados estabelece que uma falha no kernel que recebe conexões de rede foi corrigida. Um serviço pode parecer totalmente normal enquanto a resposta de segurança permanece inacabada.

Para um administrador, cada dia adicional significa manter uma decisão provisória, acompanhar anúncios e preparar uma intervenção. Esse período é a nossa preocupação. Não apoia nem uma acusação infundada de negligência nem permite que uma medida temporária se torne permanente devido à negligência.

#Existe uma solução, mas seu canal de distribuição é importante

O anúncio Ubuntu publicado em 2 novembro descreve correções no bolso de testes proposto para diversas versões suportadas. Para Ubuntu 26.04 LTS e o pacote Linux, ele nomeia a versão 7.0.0-43.43.. O anúncio diz que a publicação em -updates seguirá os testes, sem fornecer uma data firme.

Isso muda a forma como a situação deve ser descrita. Dizer que não existe solução seria impreciso. Dizer que todo Ubuntu VPS já está corrigido seria igualmente impreciso. Um pacote sendo testado, sua disponibilidade através dos canais habituais de atualização e seu uso real em uma máquina são fatos separados.

Anúncio de Ubuntu publicado em 2 novembro

#-a proposta ainda requer uma decisão de produção

A Canonical descreve o acesso antecipado aos kernels propostos como uma opção para equipes capazes de realizar seus próprios testes de aceitação. Este canal permite que esse trabalho comece mais cedo. Não estabelece que o processo de qualificação mais amplo esteja completo.

Em um VPS que atende aplicações reais, a decisão também envolve reinicialização, drivers, rede e recuperação. Habilitar amplamente um repositório e atualizar sem revisar os pacotes selecionados pode expandir a intervenção além da correção pretendida. Este artigo, portanto, não fornece um comando geral para mudar uma máquina de produção para proposta.

A questão útil não é simplesmente se uma solução está disponível. É importante saber qual canal fornece isso, para qual distribuição e tipo de kernel e com qual validação.

acesso antecipado aos kernels propostos

#Ambas as instâncias VPS estão executando o kernel corrigido

O TinyDigit VPS mudou de 7.0.0-38-genérico para 7.0.0-43-genérico. O PRNext VPS mudou de 7.0.0-28 genérico para 7.0.0-43 genérico. Em cada servidor, instalamos quatro pacotes de kernel Ubuntu na versão 7.0.0-43.43 e, em seguida, verificamos o kernel em execução real após a reinicialização.

A instalação foi limitada a esses pacotes, sem proposta de atualização de distribuição ou habilitação global. Os kernels anteriores permanecem disponíveis como substitutos de inicialização. A filtragem de rede temporária e as configurações de MPTCP também são mantidas durante esse acompanhamento.

Após as reinicializações, abrimos uma nova conexão SSH para cada servidor e verificamos as respostas HTTPS dos endpoints PRNext e TinyDigit testados. Os cinco contêineres originais do aplicativo estão presentes e prontos; seus cinco aliases nativos também respondem por HTTPS.

Uma dependência externa permanece indisponível; a recuperação completa do aplicativo ainda precisa ser verificada.

#Verifique o kernel que está realmente rodando

O pacote do kernel instalado no disco pode ser diferente do kernel atualmente em execução. Após uma intervenção, a verificação precisa cobrir o sistema em execução, o novo acesso SSH, HTTPS e os aplicativos que ele hospeda. Uma saída bem-sucedida do gerenciador de pacotes não é suficiente para encerrar o trabalho.

Esses comandos não modificam o servidor. Eles fornecem um ponto de partida para comparação com o rastreador oficial da distribuição. Um número de versão por si só, sem a identidade do pacote e as correções suportadas pela distribuição, não pode estabelecer o resultado.

uname -r
cat /etc/os-release

#A mitigação não é um reparo do kernel

Nosso guia original registra as medidas temporárias aplicadas em 30 outubro e as verificações realizadas posteriormente. Continua sendo um relato histórico, em vez de uma evidência do estado atual de cada instância VPS.

Desativar o MPTCP não repara a falha subjacente. O rastreador de Ubuntu também descreve limites para a filtragem de opções direcionadas de IPv4. Uma regra carregada, um contador de pacotes ou um site acessível não garantem proteção contra todos os caminhos de exploração.

guia original

#O que uma atualização de segurança útil deve lhe dizer

É razoável esperar um relato claro do que foi consertado, do que ainda está sendo testado e do que ainda precisa ser feito nas próprias máquinas. É igualmente importante reconhecer o custo de implementar uma atualização de kernel sem validação suficiente. Urgência e estabilidade pertencem à mesma decisão.

A nossa posição é simples: uma medida provisória deve permanecer visível no trabalho que ainda precisa ser feito. O endpoint deve ser uma versão corrigida em execução com serviços verificados, em vez de apenas um anúncio tranquilizador. Uma atualização de npm para PRNext não pode executar essa tarefa do sistema Linux.