Falhas no kernel do Linux entraram no radar de emergência da CISA (Cybersecurity and Infrastructure Security Agency) após três vulnerabilidades serem adicionadas ao catálogo Known Exploited Vulnerabilities (KEV) com evidências de exploração ativa. Os problemas atingem diferentes componentes do kernel, incluindo AF_ALG, ebtables e kTLS, e podem abrir caminho para corrupção de memória, escalonamento de privilégios e comprometimento de sistemas Linux.
O alerta ganha ainda mais importância porque uma das falhas, a CVE-2025-39964, permaneceu no código do kernel por aproximadamente 14 anos. Pesquisadores da STAR Labs identificaram o problema no subsistema criptográfico AF_ALG e demonstraram exploração capaz de obter escalonamento local de privilégios e escape de contêiner.
As três vulnerabilidades foram incluídas no KEV em 18 de setembro de 2026, e o prazo indicado pela CISA para remediação das falhas é 21 de setembro de 2026. Embora as obrigações formais do catálogo sejam direcionadas às agências federais dos Estados Unidos, a inclusão no KEV é um importante sinal para administradores de qualquer ambiente Linux, especialmente quando existem evidências de exploração real.
As falhas no kernel do Linux que exigem atenção
As três vulnerabilidades não possuem exatamente o mesmo vetor de ataque. Elas atingem subsistemas diferentes e exigem condições distintas para exploração. O ponto em comum é que todas afetam componentes de baixo nível, onde uma vulnerabilidade pode ultrapassar as barreiras normalmente utilizadas para separar aplicações, usuários e serviços.
CVE-2025-39964 e a falha que permaneceu 14 anos no kernel
A CVE-2025-39964 está relacionada a uma condição de corrida no AF_ALG, a interface do kernel Linux utilizada para disponibilizar operações criptográficas para aplicações por meio de sockets.
O problema estava na possibilidade de ocorrerem escritas concorrentes no mesmo socket AF_ALG. Nessas circunstâncias, dados poderiam ser intercalados de maneira inesperada e deixar o estado interno do socket inconsistente. A correção introduziu controle exclusivo de escrita para impedir que dois processos alterassem simultaneamente o mesmo contexto.
O aspecto mais preocupante é a idade do código vulnerável. Segundo a STAR Labs, o problema estava presente desde o Linux 2.6.38, lançado em 2011, permanecendo no kernel por aproximadamente 14 anos antes de ser identificado durante pesquisas envolvendo o kernelCTF.
Os pesquisadores também demonstraram consequências que vão além de uma simples negação de serviço. A exploração permitiu escalonamento de privilégios e escape de contêiner, cenário particularmente relevante para servidores que executam cargas isoladas com Docker, Kubernetes ou outras tecnologias de virtualização baseada em namespaces.
CVE-2026-53266 e o problema no ebtables
A CVE-2026-53266 afeta o caminho de ebtables, utilizado pelo subsistema de bridge e filtragem de rede do Linux.
O problema está relacionado ao alvo ebt_snat e à reescrita do endereço de hardware do remetente em pacotes ARP. Em determinadas condições, o kernel pode tentar modificar uma região de memória que não foi devidamente tornada gravável. A operação pode atingir um fragmento não linear de um socket buffer (skb) respaldado por uma página compartilhada.
Na prática, isso cria uma situação particularmente perigosa: uma operação de rede pode acabar provocando uma escrita fora dos limites esperados, com potencial para modificar memória compartilhada.
A documentação técnica do problema aponta que a exploração requer condições locais específicas, incluindo capacidade de configurar o caminho de bridge/ebtables e manipular determinadas estruturas de memória. Entretanto, privilégios de rede como CAP_NET_ADMIN podem estar disponíveis dentro de namespaces, o que torna o cenário especialmente relevante para ambientes com contêineres e isolamento por namespaces.
O comportamento lembra, em termos conceituais, uma característica que tornou a Dirty Pipe particularmente perigosa: a possibilidade de transformar uma operação aparentemente limitada em uma primitiva capaz de alterar memória associada a arquivos compartilhados. Isso não significa que as duas vulnerabilidades sejam tecnicamente iguais, mas o paralelo ajuda a entender por que corrupção de páginas compartilhadas pode representar um risco significativo para a segurança do sistema.
A CVE-2026-53266 recebeu classificação alta, com CVSS 3.1 de 8,8, e foi incluída no KEV após a CISA registrar exploração ativa.
CVE-2025-39682 e o caminho de recebimento do kTLS
A terceira vulnerabilidade é a CVE-2025-39682, localizada no processamento de registros do kTLS, mecanismo que permite ao kernel participar diretamente do processamento de conexões TLS.
O problema ocorre no caminho de recebimento quando um registro de tamanho zero presente na rx_list não é tratado corretamente. A lógica do recvmsg() deveria manter determinadas restrições sobre os tipos de registros processados em uma chamada. Uma combinação específica envolvendo registros DATA, um registro não-DATA de tamanho zero e outro registro DATA pode fazer com que essa lógica seja violada.
Isso é importante porque o kTLS pode ser utilizado por aplicações e serviços que transferem dados protegidos por TLS diretamente através das funcionalidades do kernel. A vulnerabilidade pode ser acionada remotamente quando o kTLS está habilitado, dependendo da configuração e do uso do caminho afetado.
A vulnerabilidade também ganhou atenção por existir exploração ativa registrada pela CISA. Informações públicas de acompanhamento da falha apontam ainda para a existência de material de exploração disponível publicamente, aumentando a necessidade de verificar imediatamente servidores que utilizem o recurso.
A Red Hat documentou a falha e sua correção, além de indicar como medida de mitigação a possibilidade de impedir o carregamento do módulo tls quando a atualização imediata não puder ser aplicada. Essa alternativa deve ser avaliada de acordo com as necessidades do serviço, pois pode interromper aplicações que dependem de kTLS.
Impacto prático das falhas no kernel do Linux em servidores e contêineres
Para administradores, o maior problema não é apenas a existência das vulnerabilidades, mas o fato de que elas foram classificadas pela CISA como vulnerabilidades exploradas na prática.
Um servidor Linux comprometido no nível do kernel pode representar um risco muito maior do que uma aplicação individual comprometida. O kernel controla memória, processos, dispositivos, rede e mecanismos de isolamento. Consequentemente, uma exploração bem-sucedida pode permitir que um invasor ultrapasse barreiras que normalmente limitariam o impacto de uma conta ou aplicação.
O risco de escape de contêineres merece atenção especial no caso da CVE-2025-39964. Contêineres são frequentemente tratados como unidades isoladas, mas compartilham o kernel com o sistema hospedeiro. Uma vulnerabilidade no kernel pode, portanto, transformar uma falha inicialmente localizada dentro de um contêiner em um problema para todo o host.
A CVE-2026-53266 também merece análise em ambientes que utilizam namespaces de rede, bridges Linux e filtragem baseada em ebtables. Já a CVE-2025-39682 deve ser investigada em servidores que utilizam kTLS, especialmente aqueles expostos à rede.
Até o momento, os registros públicos consultados não indicam associação dessas três vulnerabilidades a uma campanha de ransomware. Isso, porém, não reduz a urgência da correção. A classificação no KEV significa que a exploração já foi observada, independentemente de haver ou não uma campanha de ransomware associada.
Além da aplicação do patch, organizações que identifiquem sistemas vulneráveis devem considerar a necessidade de triagem forense. A orientação da CISA para vulnerabilidades incluídas no KEV reforça a importância de avaliar se um equipamento pode ter sido comprometido antes da atualização.
Como proteger sistemas contra as falhas no kernel do Linux
A prioridade deve ser identificar quais servidores, máquinas virtuais, hosts de contêineres e appliances utilizam versões vulneráveis do kernel.
O primeiro passo é verificar o kernel em execução:
uname -rEm seguida, o administrador deve consultar os avisos de segurança da distribuição utilizada e verificar se o pacote instalado contém as correções correspondentes às três CVEs. Isso é particularmente importante em Red Hat Enterprise Linux, Ubuntu, Debian e outras distribuições que aplicam correções de segurança por meio de pacotes próprios.
Não basta comparar apenas o número principal da versão. Distribuições Linux frequentemente fazem backport de correções, portanto um kernel com uma versão aparentemente antiga pode já conter o patch de segurança.
A recomendação principal é atualizar o kernel pelos canais oficiais da distribuição, reiniciar o sistema quando necessário e confirmar posteriormente qual kernel está realmente em execução. Em servidores críticos, a atualização deve ser planejada dentro da janela de manutenção mais curta possível, considerando dependências de aplicações e mecanismos de alta disponibilidade.
Quando a atualização imediata não for possível, administradores devem avaliar as mitigações específicas de cada fornecedor. Desabilitar módulos ou funcionalidades vulneráveis pode reduzir a exposição, mas não deve ser tratado como substituto permanente do patch.
O alerta envolvendo as três falhas no kernel do Linux reforça uma lição importante para equipes de infraestrutura: vulnerabilidades de baixo nível podem permanecer durante anos sem chamar atenção e, quando passam a ser exploradas, podem atingir justamente as camadas responsáveis pelo isolamento e pela segurança de todo o ambiente.
Por isso, servidores Linux, hosts de contêineres e plataformas de infraestrutura devem entrar imediatamente no processo de inventário, atualização e verificação de comprometimento. Para ambientes que utilizam Linux em produção, a correção dessas vulnerabilidades deve ser tratada como uma prioridade de segurança, especialmente diante da inclusão no catálogo KEV da CISA.