FortiOS CVE-2025-68686 vence a 10 de agosto — corrigir sem procurar persistência deixa metade do trabalho
A CISA incluiu a falha no KEV e exige mitigação conforme o fabricante. O detalhe decisivo é que o bypass observado pressupõe que o equipamento já tenha sido comprometido ao nível do sistema de ficheiros.
- Natureza
- Alerta operacional de vulnerabilidade explorada
- Prazo KEV
- 10 de agosto de 2026 para entidades federais abrangidas; referência forte de prioridade para outras organizações
- Produtos
- FortiOS nas gamas confirmadas pelo NVD e fabricante
- Limite
- A inclusão em KEV prova exploração conhecida, não prova compromisso do seu ativo
Em resumo
A entrada KEV, adicionada a 27 de julho e com prazo de 10 de agosto, cobre uma exposição de informação em FortiOS. NVD e o aviso do fabricante indicam versões afetadas desde 6.4.0 até antes de 7.4.7 e 7.6.0 até antes de 7.6.2. A exploração descrita usa pedidos HTTP preparados para contornar a correção do mecanismo de persistência por symbolic link depois de um compromisso anterior. A resposta deve combinar versão corrigida, redução de exposição, triagem forense e rotação de segredos.
- Inventarie versão ativa, interface de administração e exposição externa de cada appliance; CMDB sem runtime não basta.
- Atualize para uma versão corrigida conforme o advisory do fabricante e confirme o estado após reboot.
- Procure indicadores e alterações persistentes antes de declarar remediação; o CVE descreve uma etapa pós-compromisso.
- Rode credenciais, certificados e tokens acessíveis ao equipamento quando a triagem não excluir acesso anterior.
O score médio não reduz a urgência de uma falha pós-compromisso
O fabricante atribui CVSS 3.1 de 5,9, mas a CISA inclui a falha no catálogo de vulnerabilidades exploradas. O cenário requer compromisso prévio ao nível do sistema de ficheiros; por isso, a pergunta não é apenas se o pedido HTTP funciona, mas se um atacante já instalou persistência que sobreviveu a correções anteriores.
O NVD lista FortiOS 6.4.0 até antes de 7.4.7 e 7.6.0 até antes de 7.6.2 como intervalos vulneráveis. Confirme a tabela do fabricante para a linha exata e não converta um intervalo CPE amplo numa instrução de atualização sem validar o produto.
Resposta com prazo e prova
- 27 JULEntrada em KEV
CISA confirma exploração conhecida e publica a ação exigida.
- 9 AGOContenção
Identificar ativos, limitar gestão exposta e recolher prova antes de alterar.
- 10 AGOPrazo KEV
Aplicar mitigação do fabricante ou retirar o produto quando não houver caminho seguro.
- DEPOISCaça e recuperação
Validar persistência, segredos, configuração e integridade do equipamento.
Priorize por exploração, exposição e função — depois escolha a intervenção
Comece pelos equipamentos com administração acessível da Internet, controlo de tráfego crítico ou sinais de alteração. Preserve configuração, logs, imagem ou artefactos indicados pelo fabricante antes de reinicializações destrutivas, equilibrando recolha com contenção.
A atualização corrige o caminho vulnerável, mas não revoga credenciais nem apaga necessariamente persistência prévia. Se a equipa não consegue estabelecer integridade, substituição ou reconstrução a partir de configuração verificada pode ser mais defensável do que uma simples atualização in-place.
Decisão por ativo
| Sinal | Ação imediata | Prova | Saída |
|---|---|---|---|
| Gestão exposta | Restringir e monitorizar | Scan e ACL | Superfície fechada |
| Versão afetada | Atualizar/mitigar | Versão ativa | Build corrigida |
| Indício de persistência | Isolar e preservar | Artefactos e timeline | Triagem concluída |
| Segredos acessíveis | Revogar e rodar | Inventário de credenciais | Tokens inválidos |
| Integridade incerta | Reconstruir/substituir | Configuração conhecida | Ativo limpo |
O encerramento exige reconciliação entre patch e incidente
Abra dois fluxos ligados: gestão de vulnerabilidade para fechar versão e exposição; resposta a incidente para avaliar compromisso anterior. Um ticket de patch fechado não pode apagar a incerteza forense.
Valide serviço e segurança depois da mudança: versão em execução, política carregada, interfaces fechadas, logs a chegar, certificados válidos e tráfego esperado. Documente a razão para não reconstruir quando escolhe manter um ativo suspeito.
- Não priorizar apenas pelo CVSS base.
- Não reiniciar antes de preservar a prova necessária.
- Não assumir que patch remove persistência ou segredos roubados.
- Não fechar até a versão ativa e o estado forense terem responsáveis.
Fontes consultadas
Consultadas na data de atualização indicada.
Abre numa nova janela.- 01Known Exploited Vulnerabilities CatalogCISA · CY-CISA
- 02CVE-2025-68686NIST NVD · CY-NVD
- 03CVE-2025-68686 recordCVE Program · CY-CVE
- 04FG-IR-25-934Fortinet PSIRT · CY-FORTINET
- 05BOD 26-04 — Prioritizing Security Updates Based on RiskCISA · CY-CISA
- 06Guide to Enterprise Patch Management PlanningNIST CSRC · CY-NISTCSRC
Participar
Partilhe a análise. Acrescente contexto.
Divulgue a matéria no seu canal ou deixe uma observação ligada ao tema.
Comentários
A carregar a conversa.