--- title: "CISA inclui nova vulnerabilidade explorada em seu catálogo de alerta" author: "André Iglesias" date: "2026-09-19 06:15:00-03" category: "Segurança & Privacidade" url: "http://desbugados.scale.press/portal/desbugados/post/2026/09/19/cisa-inclui-nova-vulnerabilidade-explorada-em-seu-catalogo-de-alerta/md" --- ## Resumo - A CISA incluiu a CVE-2025-39682 em seu catálogo de vulnerabilidades exploradas conhecidas em 18 de setembro de 2026. - A falha afeta o caminho de recebimento do TLS na implementação kTLS do kernel Linux. - Registros de tamanho zero podem resultar em vazamento de memória ou negação de serviço. - A exploração exige acesso local autenticado para manipular o enquadramento do registro. - Agências federais americanas receberam prazo até 21 de setembro de 2026 para corrigir os sistemas e realizar triagem forense. - A recomendação é atualizar o kernel fornecido pelo fabricante e avaliar a desativação do descarregamento TLS como medida paliativa. --- 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](https://www.cisa.gov/news-events/alerts/2026/09/18/cisa-adds-one-known-exploited-vulnerability-catalog) 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.