Falhas antigas no KEV: priorize o caminho de ataque, não a idade da CVE

A CISA acrescentou cinco vulnerabilidades ao catálogo Known Exploited Vulnerabilities, o KEV, após identificar uso em atividades ligadas ao Flax Typhoon, ator associado à China.[5] A lista reúne ProFTPD, ONLYOFFICE Docs, Strapi, Apache Struts e ISC BIND, com falhas de diferentes anos e impactos.[5] O recado para engenharia não é que todo software antigo esteja comprometido, mas que a data da descoberta não encerra o risco.

O que muda para quem desenvolve

A CVE-2015-3306 do ProFTPD permite leitura e escrita arbitrárias de arquivos por funcionalidades de cópia; a CVE-2021-3199 do ONLYOFFICE Docs envolve travessia de diretórios em upload de imagem, no cenário descrito com JWT, podendo levar a execução remota.[5] A CVE-2023-22894 do Strapi permite descobrir dados sensíveis a partir do painel administrativo por filtros de consulta.[5]

Já a CVE-2016-3081 do Apache Struts permite execução remota quando a invocação dinâmica de métodos está habilitada, enquanto a CVE-2015-5477 do BIND pode provocar negação de serviço por consultas TKEY.[5] São condições distintas. Uma fila única com a palavra crítico não explica qual ação resolve cada caso.

Minha leitura: priorização deveria produzir uma hipótese verificável de exposição. Para cada entrada, pergunte se o componente está presente, se a versão é afetada, se a configuração necessária existe e quem consegue alcançar o caminho relevante. Não use a ausência de acesso público como conclusão automática de ausência de risco; documente também os acessos internos relevantes.

Como aplicar

Escolha uma aplicação e construa uma tabela com componente, versão, configuração determinante, ponto de entrada e responsável pela correção. Inclua dependências empacotadas e serviços operacionais necessários ao sistema, não apenas o código que a equipe escreve.

Para cada possível correspondência com a lista, registre uma de três saídas: afetado com evidência, não afetado com justificativa ou ainda não determinado. Essa terceira categoria é importante. Ela impede que falta de inventário vire um selo de segurança.

Depois da atualização ou da desativação de uma funcionalidade, repita a verificação de configuração e teste a jornada legítima correspondente. O experimento termina quando há evidência da mudança e do funcionamento esperado, não quando um ticket recebe o status resolvido.

Se houver indícios de acesso indevido, abra investigação separada sobre persistência e credenciais. Recomendo não tratar a correção da porta de entrada como prova de remoção de tudo que um invasor possa ter alterado.

Cuidados e limites

O prazo de 11 de outubro de 2026 citado na notícia se aplica às agências federais dos Estados Unidos, que devem corrigir ou deixar de usar os componentes afetados.[5] Não o apresente como obrigação legal automática para uma organização brasileira.

A atribuição ao Flax Typhoon pertence ao alerta reportado.[5] Encontrar um dos produtos no inventário não identifica o autor de um eventual ataque. Use o catálogo como evidência para priorizar correção e investigação, preservando a diferença entre presença do componente, vulnerabilidade confirmada e incidente atribuído.

Fonte

[5] Fonte: The Hacker News