Em 18 de setembro de 2026, a CISA incluiu a CVE-2025-39682 no catálogo de vulnerabilidades exploradas conhecidas, citando evidências de exploração ativa. A falha está relacionada ao kernel Linux e recebeu atenção especial porque a agência trata vulnerabilidades presentes no catálogo como problemas que exigem resposta rápida em ativos expostos publicamente. Para administradores, o alerta muda a ordem de prioridade: a primeira tarefa é confirmar onde a implementação afetada está presente, verificar a disponibilidade da correção do fornecedor e procurar sinais de comprometimento antes de considerar o problema encerrado. O aviso oficial da CISA ajuda a entender por que a inclusão merece tratamento diferente de uma falha sem evidências de uso real.

Por que a entrada no catálogo exige resposta rápida

A entrada no catálogo aciona uma obrigação específica para as agências federais americanas. Sob a Diretiva Operacional Vinculante BOD 26-04, esses órgãos devem priorizar a remediação rápida de vulnerabilidades de alto risco encontradas em ativos expostos publicamente, ou seja, sistemas que podem ser alcançados a partir de redes externas. Na prática, a determinação reduz o espaço para deixar a correção em uma fila comum de manutenção, porque a combinação entre exposição pública e exploração ativa exige uma verificação imediata da infraestrutura. Esse modelo também explica por que a orientação não termina na instalação de um pacote: o administrador precisa confirmar se a atualização foi aplicada corretamente e se o ativo apresentou sinais de abuso.

Essa prioridade faz parte de uma atualização mais ampla publicada em setembro de 2026, quando três vulnerabilidades do kernel Linux foram incluídas no catálogo. Dentro desse conjunto, a falha tratada aqui foi apontada como a mais grave e recebeu pontuação CVSS 9.8, segundo o CNA responsável pela avaliação. A pontuação não substitui a análise do ambiente, mas ajuda a dimensionar por que o prazo dado às agências foi tão curto, especialmente quando a vulnerabilidade já tem evidências de exploração em campo. O dado mais relevante para quem administra sistemas, portanto, não é apenas a nota: é a combinação entre severidade elevada, presença em um componente de baixo nível e confirmação de uso contra ativos reais.

Onde está o problema no caminho de recebimento

O motivo técnico do alerta está no caminho de recebimento do TLS dentro da implementação conhecida como kTLS, que permite tratar a comunicação protegida no próprio kernel. A falha aparece quando esse caminho lida com registros de tamanho zero armazenados na lista rx_list, uma estrutura usada durante o recebimento dos dados. A validação inadequada para essa condição pode levar a vazamento de memória ou a uma negação de serviço, situação em que o sistema deixa de responder normalmente às solicitações. Traduzindo o tecnicismo: uma entrada que deveria ser tratada como excepcional passa pelo fluxo de recebimento sem a checagem esperada, criando uma condição capaz de afetar a disponibilidade ou a integridade do processamento.

Dentro desse caminho, a causa descrita pelas fontes é uma validação incompleta no loop responsável pelo recebimento de registros TLS de tamanho zero. A exploração exige acesso local autenticado para manipular o enquadramento do registro no caminho de recebimento, o que delimita a forma de abuso descrita até agora, mas não elimina a necessidade de investigação. Em termos práticos, o requisito significa que o invasor precisa alcançar uma posição local autorizada antes de tentar explorar a condição, enquanto o impacto possível continua envolvendo vazamento de memória e indisponibilidade do serviço. Essa diferença entre o ponto de entrada e o dano potencial é justamente o tipo de detalhe que deve orientar a triagem técnica.

Prazo curto e investigação além do patch

A gravidade operacional aumenta porque a CISA determinou que as agências federais investiguem seus ativos expostos em busca de sinais de comprometimento, além de aplicar as correções. A triagem forense é a etapa de procurar evidências de que o sistema já foi manipulado, em vez de presumir que a instalação de um patch apaga o histórico do problema. Para as três vulnerabilidades incluídas na atualização, a agência exigiu essa análise adicional, o que transforma registros, integridade dos sistemas e histórico de acesso em partes da resposta. O objetivo é descobrir se a exploração aconteceu antes da correção e impedir que uma equipe trate como resolvido um ativo que ainda conserva sinais de intrusão.

O prazo definido pela BOD 26-04 terminou em 21 de setembro de 2026, apenas três dias depois da inclusão da vulnerabilidade no catálogo. A janela curta mostra que a classificação da CISA produz uma consequência operacional imediata para os órgãos submetidos à diretiva: localizar os ativos afetados, corrigir os sistemas e concluir a verificação forense dentro de um período delimitado. Embora o prazo citado se aplique às agências federais americanas, a evidência de exploração ativa mantém o alerta relevante para qualquer organização que utilize a implementação afetada. O relógio regulatório pode variar entre empresas, mas a necessidade técnica de descobrir exposição e sinais de comprometimento permanece.

O que fazer agora no ambiente afetado

Esse conjunto de informações aponta para duas medidas práticas. A primeira é instalar a atualização do kernel fornecida pelo fornecedor responsável pelo sistema, seguindo o procedimento de manutenção adotado no ambiente e confirmando depois que a versão corrigida está realmente em execução. A segunda é avaliar, quando tecnicamente possível, a desativação do descarregamento de TLS no kernel, o kTLS, como medida paliativa até a aplicação da correção. Essa alternativa não substitui o patch, porque a recomendação principal continua sendo atualizar o kernel, mas pode reduzir a exposição ao caminho específico enquanto a equipe organiza a manutenção. A decisão precisa considerar o funcionamento do serviço, já que alterar o processamento de comunicações protegidas pode afetar a operação.

Mesmo com a exigência de acesso local autenticado descrita para a exploração, a confirmação de uso em campo impede que a falha seja tratada como uma hipótese distante. Não há detalhes sobre campanhas específicas ou atores identificados, mas a CISA confirmou exploração ativa, e a investigação deve começar pelos ativos públicos e pelos sistemas que apresentem sinais anormais. O próximo passo para as agências abrangidas pela diretiva é concluir a correção e a triagem até 21 de setembro de 2026; para os demais administradores, a sequência mais segura é verificar a presença da implementação, aplicar a atualização do fornecedor, avaliar a medida paliativa e preservar evidências antes de encerrar o atendimento do alerta.