O FortiSandbox no KEV da CISA deixou de ser apenas um caso de correção preventiva: duas vulnerabilidades do produto estão associadas a exploração ativa e exigem uma resposta que combine atualização, isolamento e investigação. A prioridade vale para organizações que usam o appliance local, máquinas virtuais ou os serviços em nuvem.
Em 16 de julho de 2026, a CISA adicionou CVE-2026-39808 e CVE-2026-25089 ao catálogo Known Exploited Vulnerabilities. O registro federal criou prazo de remediação para agências civis dos Estados Unidos, mas o sinal técnico também serve para empresas privadas que precisam ordenar o backlog de vulnerabilidades.
O ponto mais relevante é que as duas falhas permitem execução de comandos sem autenticação por requisições HTTP criadas para explorar o serviço. Isso reduz a dependência de credenciais roubadas e torna a exposição da interface de administração um fator decisivo na avaliação de risco.
Por que o alerta mudou
O FortiSandbox ocupa uma posição diferente da de um servidor corporativo comum. Ele recebe arquivos, URLs e outros artefatos suspeitos para análise em ambiente isolado. Quando a ferramenta de inspeção é comprometida, o problema pode alcançar os fluxos que dependem dos veredictos produzidos pelo sistema.
O produto combina análise estática e dinâmica com inteligência de ameaças em tempo real. Essa arquitetura foi descrita pela própria Fortinet como uma forma de detectar malware, ransomware, ameaças desconhecidas e ataques de dia zero. A função explica por que a integridade do sandbox merece tratamento semelhante ao de outros ativos de segurança críticos.
A plataforma também pode operar no local, como máquina virtual, na nuvem ou como serviço PaaS. A variedade de modelos amplia o trabalho de inventário: uma equipe pode corrigir o appliance conhecido e ainda deixar uma instância virtual, uma assinatura Cloud ou uma implantação PaaS fora do processo de atualização.
Essa diferença de contexto evita uma leitura simplista do alerta. O catálogo KEV não afirma que toda implantação foi comprometida, nem que houve ransomware associado às duas CVEs. Ele registra exploração conhecida e orienta a priorização. A resposta correta é verificar exposição e evidências, sem transformar o aviso em prova de invasão generalizada.
Para contextualizar a relação entre vulnerabilidades exploradas e resposta de defesa, vale consultar também a análise sobre arquivos de exploit em circulação e o guia sobre priorização contra ransomware.
Falhas e versões afetadas
O primeiro caso é a CVE-2026-39808. O aviso FG-IR-26-100 limita a falha às versões 4.4.0 até 4.4.8 do FortiSandbox. A descrição técnica classifica o problema como injeção de comandos do sistema operacional, causada pela neutralização inadequada de elementos especiais em uma entrada processada pelo produto.
A correção indicada pela Fortinet para essa linha é a versão 4.4.9 ou posterior. O mesmo aviso informa que a linha 5.0 não é afetada por essa vulnerabilidade. Essa distinção é operacionalmente útil: a equipe precisa confirmar o produto e a versão antes de escolher a janela de manutenção.
| Vulnerabilidade | Escopo | Correção indicada |
|---|---|---|
| CVE-2026-39808 | FortiSandbox 4.4.0 a 4.4.8 | 4.4.9 ou posterior |
| CVE-2026-25089 | FortiSandbox 5.0.0 a 5.0.5; Cloud e PaaS 5.0.4 a 5.0.5; 4.4.0 a 4.4.8 | 4.4.9 ou 5.0.6, conforme a linha |
O segundo caso, CVE-2026-25089, aparece no aviso FG-IR-26-141 como uma injeção de comandos de segunda ordem por entrada JSON no recurso de inicialização VNC. O escopo inclui FortiSandbox, FortiSandbox Cloud e FortiSandbox PaaS, embora as tabelas de versões afetadas variem entre as modalidades.
A versão 5.0.6 é a correção indicada para as edições 5.0 afetadas. Na linha 4.4, a atualização recomendada é a 4.4.9. O aviso também identifica versões 5.2 como não afetadas. Para serviços hospedados, a confirmação deve ser feita com o provedor, pois a existência de uma assinatura Cloud não substitui a verificação da versão protegida.
A classificação do NVD para a CVE-2026-39808 registra vetor de rede, baixa complexidade, ausência de privilégios e ausência de interação do usuário, com impacto alto sobre confidencialidade, integridade e disponibilidade. Esse conjunto descreve uma falha acessível remotamente, não uma previsão de que cada instalação será atacada.
Risco para a defesa
O risco central não é apenas a execução de um comando no appliance. A Fortinet informa que o FortiSandbox se integra a FortiGate, FortiMail, FortiNDR, FortiEDR, FortiProxy, FortiSIEM e outras soluções da Security Fabric. Uma instância comprometida pode, portanto, ser relevante para credenciais de integração, telemetria e decisões automatizadas.
A integração do FortiSandbox alcança FortiGate, FortiMail, FortiNDR e outras soluções da Security Fabric. A consequência prática é que o time de resposta deve avaliar conexões de gerenciamento e contas técnicas associadas, em vez de limitar a análise ao endereço IP do sandbox.
Isso não significa que a exploração altere automaticamente veredictos, roube amostras ou produza movimento lateral. Esses resultados dependem de permissões, segmentação, configurações e ações posteriores do invasor. Ainda assim, a posição do produto torna prudente tratar sinais de execução anômala como possível incidente envolvendo infraestrutura de segurança.
A exploração confirmada muda a ordem de resposta: exposição e evidência vêm antes da rotina de atualização. Se a interface esteve acessível à internet ou a uma rede ampla, a organização deve preservar registros e avaliar o período de exposição antes de apagar artefatos durante a manutenção.
O próprio catálogo KEV orienta aplicar as mitigações do fornecedor e seguir a triagem forense indicada pela CISA. A orientação é compatível com uma resposta em duas trilhas: corrigir rapidamente o componente vulnerável e investigar se houve uso anterior da falha.
O caso também reforça uma diferença entre risco técnico e impacto confirmado. A severidade e a exploração observada justificam a prioridade, mas não permitem atribuir campanha, grupo criminoso ou finalidade de ransomware sem evidência específica. Uma análise sóbria separa o que as fontes registram do que ainda precisa ser apurado.
Resposta em quatro etapas
O primeiro passo é localizar todas as implantações. Inclua appliances físicos, máquinas virtuais, ambientes de teste, contas de serviço e assinaturas hospedadas. Compare a versão observada com as tabelas dos avisos da Fortinet e registre a exposição da interface de administração.
- Inventarie e classifique. Identifique versão, modalidade, endereço de gerenciamento, integrações e responsável técnico. Marque como prioridade máxima qualquer instância acessível pela internet ou por segmentos sem controle de origem.
- Atualize ou isole. Instale 4.4.9 ou 5.0.6 quando aplicável, seguindo o aviso correspondente. Enquanto a janela não ocorrer, restrinja a administração a redes confiáveis, VPN ou bastion host. Não trate o bloqueio temporário como substituto permanente do patch.
- Preserve e procure evidências. A verificação de logs deve procurar requisições HTTP anômalas e execuções inesperadas de comandos. Correlacione eventos do FortiSandbox com autenticações, conexões de saída, alterações administrativas e atividades incomuns nos produtos integrados.
- Revise confiança e credenciais. Se houver indício de acesso, faça rotação controlada de credenciais e tokens de integração, avalie sessões existentes e busque movimento lateral. A troca deve ocorrer com coordenação para não interromper a coleta de evidências nem criar falhas operacionais.
Para serviços em nuvem, a orientação da CISA prevê descontinuar o produto se não houver mitigação disponível. A decisão precisa ser documentada com o provedor, incluindo a versão em execução, a data da correção e os controles provisórios adotados. O objetivo é evitar que uma camada hospedada seja presumida como corrigida sem confirmação verificável.
A correção técnica não encerra a investigação quando a instância ficou vulnerável antes do patch. Uma equipe pode considerar a remediação concluída apenas depois de validar a versão, revisar os registros relevantes e confirmar que as conexões de confiança continuam sob controle.
O resultado esperado é uma decisão baseada em evidências: corrigir, limitar a exposição, investigar e acompanhar. Essa sequência reduz a chance de confundir a retirada da vulnerabilidade com a comprovação de que nenhum acesso ocorreu.