Três KEV chegam ao prazo hoje: Langflow, Tomcat e N-central pedem prova, não um ticket

O que está confirmado — e o que o catálogo não diz

A versão 2026.08.06 do feed CISA contém 1.661 entradas e mantém as três vulnerabilidades com data de adição de 4 de agosto e due date de 7 de agosto. A inclusão no KEV confirma evidência de exploração no mundo real segundo o processo CISA. Não confirma comprometimento de uma entidade específica, autor, escala, ransomware ou exposição de todos os produtos com o mesmo nome.

O prazo curto decorre da BOD 26-04 e aplica-se às agências federais civis abrangidas. Uma empresa em Portugal pode e deve usar o sinal para priorizar ativos expostos e críticos, mas precisa de definir o seu próprio SLA de risco. A CISA pede instruções do fornecedor, avaliação de exposição, mitigação ou descontinuação quando não existe correção e requisitos de triagem forense.

Triagem de 90 minutos: identificar, limitar e preservar antes de declarar vitória

Comece por inventário real: versões, localização, dono, exposição à Internet, autenticação, dados acessíveis, integrações e contas de serviço. Se a equipa não consegue provar que o produto não existe, trate a resposta como descoberta pendente. Se existe e está exposto, reduza superfície segundo orientação aplicável e preserve evidência antes de alterações destrutivas.

A matriz abaixo não substitui advisories do fabricante nem recomenda executar provas de conceito. Serve para evitar três erros: atualizar o produto errado, apagar sinais úteis durante a correção e deixar chaves ou sessões potencialmente expostas depois de instalar uma versão corrigida.

Fechar com duas perguntas: estamos corrigidos e estivemos comprometidos?

A primeira pergunta exige a versão ou mitigação correta, reinício quando aplicável, teste funcional, validação externa de exposição e monitorização reforçada. A segunda exige uma janela temporal, fontes de log, indicadores disponíveis, alterações de contas, processos, tarefas, tokens e tráfego. Uma resposta pode ser “não há evidência suficiente”; deve ficar registada como limitação.

Rode segredos ou invalide sessões quando a exposição e o impacto justificarem, mas preserve primeiro o que for necessário para investigação. Escalone para resposta a incidente se surgirem sinais de execução, acesso indevido ou persistência. Não publique atribuição nem extensão de impacto sem confirmação.

• Associe cada ativo a uma evidência de versão e localização.
• Guarde hora da contenção, da correção e do teste.
• Registe logs indisponíveis como lacuna, não como ausência de ataque.
• Agende nova verificação quando CISA, NVD ou o fornecedor atualizar a orientação.