PRNextUma vulnerabilidade do kernel não pode ser corrigida em package.json. Após o alerta CVE-2026-98432, verificamos duas instâncias Ubuntu VPS e aplicamos a mitigação direcionada. Aqui está a nossa abordagem, os comandos úteis e os limites que importam.
O objetivo é reduzir a exposição enquanto se espera por um kernel corrigido e, em seguida, verificar se os serviços permanecem acessíveis. Este artigo documenta uma intervenção real; adapte a configuração ao seu próprio servidor.
Em 3 novembro, instalamos a correção oficial Ubuntu em ambas as instâncias VPS. Eles agora estão executando o kernel 7.0.0-43-generic após reinicializar e verificar o novo acesso SSH, sites HTTPS e os aplicativos testados. Esses pacotes vêm de -proposed: isso não significa que Ubuntu tenha concluído a qualificação geral ou distribuição através dos canais estáveis. Uma dependência externa permanece indisponível; a recuperação completa do aplicativo ainda precisa ser verificada.
As seções a seguir preservam o relato de nossa mitigação de 30 outubro. O acompanhamento de 3 novembro detalha a instalação direcionada, verificações após a reinicialização e a distinção entre os quatro dias desde nossa mitigação até a instalação da correção e os dezenove dias desde que a entrada de Ubuntu foi publicada.
Leia o acompanhamento de 3 novembro e ambos os resultados do VPS
Esses comandos identificam o kernel em execução, distribuição, duas configurações de rede e soquetes MPTCP de escuta. Eles não alteram a configuração. Se a sua versão do ss não tiver suporte para MPTCP, um erro não significa que o servidor esteja protegido.
Compare os resultados com o rastreador de segurança da sua distribuição. Uma versão do kernel copiada de uma postagem nas redes sociais não é suficiente: as distribuições podem fazer backport de correções em seus próprios pacotes. Um pacote instalado também não é necessariamente o kernel atualmente em execução.
uname -r
cat /etc/os-release
sysctl net.mptcp.enabled net.ipv4.tcp_migrate_req
sudo ss -M -l -n -pEm 30 outubro, auditamos nossas duas instâncias VPS Ubuntu e aplicamos medidas temporárias direcionadas. Adicionamos um filtro dedicado para pacotes TCP IPv4 que transportam opções de IP e desabilitamos a criação de soquetes MPTCP nos namespaces de rede relevantes.
Um serviço Caddy teve uma reinicialização controlada para recriar seus soquetes com a configuração ajustada. Os cinco containers existentes mantiveram seus processos e horários de início. Em seguida, verificamos novas conexões SSH e recebemos respostas HTTPS 200 de todos os sete sites testados.
Não atualizamos o sistema operacional nem reinicializamos nenhum dos VPS. Estes resultados descrevem as nossas verificações após a intervenção; não provam que todas as vias de exploração possíveis estão bloqueadas.
Esta é a estrutura do nosso filtro, usando um exemplo de nome de tabela. A primeira regra limita o registro; o segundo descarta todos os pacotes correspondentes mesmo depois que esse limite é atingido. As opções IP diferem das opções TCP comuns, como MSS ou SACK.
Trate isso como um exemplo para revisar e integrar ao seu firewall existente, com acesso de recuperação e reversão com escopo pronto. Não substitua toda a sua configuração. Verifique quaisquer requisitos especiais de rede, incluindo opções de IP usadas para rotulagem de segurança.
Este filtro tem como alvo IPv4. Descrevemo-lo como redução da exposição, sem garantia de que cubra completamente a vulnerabilidade.
table inet cve_2026_98432 {
chain prerouting {
type filter hook prerouting priority -310; policy accept;
ip protocol tcp ip hdrlength > 5 limit rate 5/minute burst 5 packets log prefix "CVE98432 IPopts " level warn
ip protocol tcp ip hdrlength > 5 counter drop
}
}Se os seus serviços não precisarem de MPTCP, esta configuração impedirá novos soquetes MPTCP no namespace de rede atual. Não fecha soquetes que já estão abertos. Verifique os soquetes novamente e planeje reinicializações apenas para os serviços afetados.
Para manter essa configuração na inicialização, adicione net.mptcp.enabled = 0 a um arquivo sysctl.d dedicado após verificar as configurações existentes. A persistência deve então ser testada durante uma reinicialização planejada.
sudo sysctl -w net.mptcp.enabled=0Vá 1.24 habilitado MPTCP por padrão para ListenConfig em sistemas suportados. Portanto, um proxy reverso escrito em Go merece ser verificado mesmo quando seu aplicativo usa Node.js.
A configuração abaixo altera esse padrão quando fornecido no ambiente de serviço. Preserve quaisquer outros valores GODEBUG e recrie os soquetes do processo afetado. Usamos para Caddy; isso não substitui uma correção do kernel.
GODEBUG=multipathtcp=0A configuração MPTCP pertence a cada namespace de rede. Um valor zero no host, portanto, não estabelece que todos os contêineres tenham a mesma configuração.
Verificamos os namespaces existentes e adicionamos uma verificação periódica de novos. Um teste usando um namespace criado após a ativação confirmou que ele foi tratado. Essa verificação é periódica, portanto, há um atraso antes de ser aplicada, um dos motivos pelos quais também continuamos filtrando a entrada do host.
Alguns soquetes de contêineres internos abertos anteriormente podem permanecer. Distinguimos esses soquetes dos ouvintes públicos, em vez de tratar uma configuração do sistema como evidência de que todos os soquetes haviam desaparecido.
Verificamos se o filtro estava carregado, inspecionamos seus contadores e revisamos as configurações e os ouvintes do MPTCP. Um pacote de diagnóstico não explorado confirmou que a regra de descarte foi alcançada. Não executamos código de exploração.
Também abrimos uma nova conexão SSH e verificamos os sites externamente. As regras de firewall existentes foram preservadas. Os mecanismos de persistência foram configurados e recarregados, mas não os testamos após uma reinicialização completa do VPS.
Um contador crescente estabelece que um pacote correspondeu a uma regra. Não prova nem uma tentativa de intrusão nem uma proteção completa: as nossas próprias verificações de diagnóstico também podem aumentá-la.
A correção oficial da sua distribuição continua sendo a prioridade. Quando estiver disponível para o seu sistema, planeje sua instalação e a reinicialização necessária e, em seguida, verifique o kernel em execução real com uname -r. Decida se deseja remover as medidas temporárias com base no status oficial e nos requisitos dos seus serviços.
Este trabalho diz respeito à infraestrutura Linux que hospeda suas aplicações. Uma atualização de npm para PRNext não pode corrigir um kernel VPS. Auto-hospedagem também significa seguir esta camada do sistema e verificar as alterações em relação aos serviços reais.
CVE-2026-98432: por que a espera é importante, Ubuntu correções propostas e a diferença entre mitigação, um pacote disponível e um kernel em execução corrigido.
PRNextImplante um aplicativo Next.js em um VPS Linux com um servidor de produção, systemd, um proxy reverso e verificações antes de alternar o tráfego.
PRNextCompare um servidor Node em um VPS, contêineres, exportação estática e plataformas gerenciadas para hospedar Next.js de acordo com as necessidades reais da sua aplicação.
PRNext