Intersect, uma organização baseada em membros do Cardano, solicitou aos operadores de pools de staking que apliquem as correções e reiniciem seus block producers e servidores relay assim que as correções estiverem disponíveis para uma vulnerabilidade crítica no kernel Linux.
Em sua atualização de 30 de out., a Intersect informou aos operadores que verifiquem os kernels em ambos os tipos de servidor e instalem o kernel corrigido da sua distribuição assim que for publicado. A vulnerabilidade, CVE-2026-98432, possui um pontuação CVSS 3.1 de 9,8, ou crítica, do kernel.org.
A falha afeta o tratamento do kernel das conexões TCP IPv4 entrantes. Ela pode causar o acesso do kernel à memória após ela ter sido liberada. Boletim de segurança da Red Hat afirma que um atacante remoto sem credenciais poderia explorar a condição de corrida para executar código; sua descrição de vulnerabilidade também identifica travamentos do sistema e corrupção de memória como riscos.
Para o Cardano, o aviso abrange tanto as máquinas que produzem blocos quanto os relés que as conectam à rede mais ampla. A documentação do operador do Cardano recomenda manter os produtores de blocos conectados apenas aos seus próprios relés ou a relés confiáveis, para protegê-los da internet. O aviso da Intersect não relata exploração contra o Cardano nem quantifica quantos pools executam kernels vulneráveis.
Correções e Medidas Intermediárias
Ubuntu’s tracker, atualizado pela última vez em 30 de outubro, lista seus kernels padrão para Ubuntu 22.04, 24.04, 26.04 e 26.10 como vulneráveis, com correções em andamento. O boletim da Red Hat de 30 de outubro lista RHEL 8, 9 e 10 como afetados e afirma que está acelerando as correções.
AlmaLinux disse em 30 de outubro que kernels corrigidos para suas versões 8, 9 e 10 estavam disponíveis em repositórios de teste, antes do lançamento em produção. Disse que nenhum kernel RHEL corrigido estava disponível na época. O bug remonta ao Linux 4.4, enquanto correções upstream foram backportadas para ramificações estáveis mantidas.
O ataque demonstrado utilizou Multipath TCP, ou MPTCP. Os pesquisadores da Anthropic disseram que seu prova de conceito pode enviar pacotes para um servidor Linux com um ouvinte MPTCP e executar comandos como root, sem credenciais ou interação do usuário. Mas o Time de Segurança do Go alertou que a falha subjacente não é específica do MPTCP, portanto sistemas sem esses ouvintes também podem ser vulneráveis.
AlmaLinux recomenda desativar o MPTCP onde não for necessário e reiniciar os serviços com ouvintes MPTCP existentes: alterar a configuração sozinha impede apenas a criação de novos soquetes MPTCP.
A Red Hat também oferece uma mitigação de firewall que filtra pacotes TCP IPv4 de entrada contendo opções IP. Ela alerta os operadores para testar a regra contra suas cargas de trabalho antes da implantação e afirma que a filtragem pode reduzir a exposição, mas não pode impedir completamente a exploração. Ambos os fornecedores enfatizam que medidas provisórias não substituem a instalação de um kernel corrigido; a Intersect informa explicitamente aos operadores para reiniciar após a atualização.