A vulnerabilidade CVE-2026-35616 permite contornar controles de API antes da autenticação e pode levar à execução não autorizada de código ou comandos em versões 7.4.5 e 7.4.6 do FortiClient EMS.
| Componente | FortiClient EMS, nas versões 7.4.5 a 7.4.6, com falha de controle de acesso em API antes da autenticação. |
| Vetor | Requisições manipuladas contra a API do FortiClient EMS podem contornar autenticação e autorização sem credenciais válidas. |
| Impacto | Exploração bem-sucedida pode permitir escalonamento de privilégio e execução não autorizada de código ou comandos. |
| Prioridade | Instalar o hotfix disponibilizado para FortiClient EMS 7.4.5 e 7.4.6 e validar exposição externa do serviço. |
| Versões | A correção completa é esperada na versão 7.4.7; a mitigação imediata indicada é o hotfix fora do ciclo regular. |
| Exploração | Tentativas contra honeypots foram registradas em 31 de março de 2026, e a exploração em ambiente real foi observada antes da publicação da correção. |
| Obrigação regulatória | A CISA incluiu CVE-2026-35616 no catálogo KEV em 6 de abril de 2026, com prazo de correção em 9 de abril de 2026 para agências federais civis dos Estados Unidos. |
A Fortinet publicou correções fora do ciclo regular para uma vulnerabilidade crítica no FortiClient EMS rastreada como CVE-2026-35616. A falha recebeu pontuação CVSS 9.1 e foi descrita como um bypass de acesso à API antes da autenticação que pode resultar em escalonamento de privilégio. O ponto central do risco está no controle de acesso impróprio, classificado como CWE-284, em uma superfície administrativa usada para gerenciar endpoints por meio do FortiClient EMS. A condição informada é grave porque o invasor não precisa estar autenticado para acionar o comportamento vulnerável, desde que consiga enviar requisições manipuladas ao serviço afetado.
O impacto técnico confirmado é a possibilidade de executar código ou comandos não autorizados por meio dessas requisições. O material analisado não sustenta afirmar roubo de dados, movimentação lateral, implantação de malware, comprometimento de identidades ou exfiltração como consequência observada dessa falha específica. A leitura operacional deve permanecer limitada ao que foi confirmado: desvio de autenticação e autorização na API, escalonamento de privilégio e execução não autorizada de código ou comandos. Esse limite é importante para que equipes de resposta não tratem o caso como um vazamento presumido sem evidência, mas também não subestimem a severidade de uma falha pré-autenticação explorada ativamente.
As versões explicitamente afetadas são FortiClient EMS 7.4.5 até 7.4.6. A correção completa foi indicada para a versão 7.4.7, enquanto a resposta imediata disponível é a aplicação do hotfix publicado para os ramos vulneráveis. A exploração em ambiente real foi reconhecida, e tentativas contra honeypots foram observadas a partir de 31 de março de 2026. Em 6 de abril de 2026, a CISA adicionou a falha ao catálogo Known Exploited Vulnerabilities, impondo prazo de correção até 9 de abril de 2026 para agências federais civis dos Estados Unidos.
A vulnerabilidade está associada à etapa em que o FortiClient EMS deveria aplicar controles de autenticação e autorização antes de aceitar determinadas operações de API. Em um desenho esperado, requisições administrativas precisariam ser vinculadas a uma identidade válida, a uma sessão autorizada e a permissões compatíveis com a ação solicitada. Em CVE-2026-35616, a descrição indica que uma requisição especialmente construída consegue desviar esse controle de acesso antes da autenticação. O resultado é que uma interface que deveria rejeitar tráfego não autenticado pode aceitar uma ação não autorizada, abrindo caminho para execução de código ou comandos.
O termo pré-autenticação altera a prioridade da correção porque remove a necessidade de roubo prévio de credenciais, sessão válida ou abuso de conta interna. O atacante ainda depende de alcance à superfície vulnerável, mas a barreira lógica descrita é menor do que em falhas pós-autenticação. Quando o FortiClient EMS fica acessível a partir da Internet ou de redes com baixa segmentação, o risco cresce, pois a API passa a receber tráfego de origens que não deveriam conseguir interagir com funções sensíveis. A exploração por requisições manipuladas também significa que dispositivos intermediários, proxies reversos, balanceadores e logs HTTP podem conter evidências relevantes, mesmo quando o endpoint final não registra detalhes completos da tentativa.
Não há indicação clara de que CVE-2026-35616 esteja sendo explorada em conjunto com outra vulnerabilidade, embora o contexto mencione uma falha crítica recente no mesmo produto, CVE-2026-21643, também explorada ativamente. Também não há confirmação de que o mesmo ator esteja por trás das duas atividades. Portanto, a análise defensiva deve separar os eventos: tratar CVE-2026-35616 como uma falha crítica própria, com exploração ativa e correção urgente, e investigar a presença de sinais relacionados a outras falhas apenas quando a telemetria local mostrar tráfego ou eventos compatíveis.
A superfície afetada compreende implantações do FortiClient EMS nas versões 7.4.5 e 7.4.6. O ativo deve ser tratado como sensível porque sua função envolve administração de clientes, políticas e componentes de segurança de endpoint. Mesmo quando o FortiClient EMS não está diretamente exposto à Internet, a falha continua relevante se redes de usuários, VPNs, segmentos administrativos, ambientes de terceiros ou túneis de suporte permitirem acesso à API. O requisito operacional para exploração descrito é alcançar o serviço vulnerável e enviar requisições manipuladas; não foi informado requisito de autenticação prévia.
Sistemas expostos à Internet exigem resposta imediata, mas a avaliação não deve terminar na borda externa. Ambientes corporativos frequentemente colocam consoles de administração em redes internas consideradas confiáveis, e essa confiança pode mascarar acessos indevidos vindos de estáções comprometidas, contas de terceiros, segmentos de laboratório ou redes sem filtragem adequada. Como o impacto envolve execução não autorizada de código ou comandos, o FortiClient EMS vulnerável deve ser analisado como um ponto potencial de execução privilegiada dentro da arquitetura de gerenciamento de endpoints.
A existência de hotfix para 7.4.5 e 7.4.6 muda a ordem prática de resposta: identificar instâncias, confirmar versão, aplicar a correção emergencial e planejar a adoção da 7.4.7 quando disponível no ciclo normal de atualização. A presença da falha no catálogo KEV também reforça que organizações sujeitas a políticas inspiradas no modelo da CISA podem precisar comprovar correção em janela curta, além de documentar exceções, sistemas inacessíveis e compensações temporárias.
- FortiClient EMS 7.4.5 e 7.4.6 devem ser considerados vulneráveis até aplicação do hotfix correspondente.
- Instâncias alcançáveis pela Internet têm prioridade máxima de correção e revisão de logs.
- Instâncias internas continuam relevantes quando a API pode ser acessada por redes de usuários, VPNs, terceiros ou segmentos pouco filtrados.
- A versão 7.4.7 é o destino de correção completa indicado, mas a medida imediata descrita é o hotfix.
A investigação deve começar por inventário e exposição. Equipes de segurança precisam localizar todos os servidores FortiClient EMS, identificar a versão instalada e verificar se há publicação direta ou indireta da interface de API. Em seguida, a telemetria deve ser organizada por janela temporal: antes de 31 de março de 2026, a partir do primeiro registro conhecido de tentativas contra honeypots, no período de aplicação do hotfix e após a correção. Essa separação ajuda a diferenciar varredura oportunista, tentativa de exploração, falha bloqueada e atividade posterior à mitigação.
Nos logs de aplicação e de infraestrutura, o foco defensivo deve recair sobre requisições pré-autenticadas para endpoints de API, especialmente quando ocorrerem sem fluxo de autenticação correspondente, com métodos incomuns, parâmetros fora do padrão, erros repetidos, respostas anômalas ou transições para execução de ações administrativas. Como o contexto não fornece caminhos de URL, nomes de parâmetros, payloads ou assinaturas específicas, não é adequado criar indicadores artificiais. A abordagem correta é comparar padrões normais do EMS com eventos fora do perfil, priorizando origens externas, endereços sem histórico de administração, bursts de requisições e sequências que terminem em comportamento de execução.
No endpoint que hospeda o FortiClient EMS, a defesa deve revisar eventos de processo, execução de comandos, criação ou modificação inesperada de arquivos, alteração de serviços, mudanças de configuração e conexões de saída iniciadas logo após requisições suspeitas. O objetivo não é presumir malware ou exfiltração, mas verificar se a falha de execução foi usada para realizar ações concretas no sistema. Também é recomendável correlacionar autenticação administrativa legítima, manutenção planejada e janelas de atualização para reduzir falsos positivos sem descartar atividade exploratória.
- Requisições de API sem autenticação válida ou sem sessão correlacionada antes de ações sensíveis.
- Acessos ao FortiClient EMS vindos de origens externas, redes de usuários ou endereços sem histórico administrativo.
- Picos de erros, respostas incomuns ou sequências de requisições manipuladas próximas a 31 de março de 2026 e aos dias seguintes.
- Processos, comandos ou alterações locais no servidor EMS iniciados logo após tráfego suspeito de API.
- Diferenças entre instâncias corrigidas e não corrigidas, com atenção a tentativas que continuem após a aplicação do hotfix.
A primeira ação deve ser aplicar o hotfix disponibilizado para FortiClient EMS 7.4.5 e 7.4.6. A correção não deve ser tratada como manutenção comum porque há exploração ativa e a falha dispensa autenticação. Após a atualização, a equipe precisa confirmar a versão, registrar evidência de aplicação, reiniciar serviços quando o procedimento do fornecedor exigir e testar se a console e os clientes gerenciados continuam operando corretamente. Quando a versão 7.4.7 estiver disponível para o ambiente, ela deve ser avaliada como caminho de correção completa conforme o ciclo interno de mudanças.
Antes ou durante a correção, controles compensatórios devem reduzir o alcance à API. Isso inclui restringir acesso ao FortiClient EMS a redes administrativas conhecidas, remover exposição direta à Internet quando existir, aplicar filtragem em firewall ou proxy reverso e revisar regras temporárias criadas para suporte remoto. Essas medidas não substituem o hotfix, mas reduzem a janela de exploração para sistemas que ainda aguardam manutenção. Em ambientes onde a mudança não pode ocorrer imediatamente, a exceção deve ter proprietário, prazo, justificativa técnica e monitoramento reforçado.
Depois da mitigação, a resposta deve validar se houve exploração anterior. A equipe deve preservar logs relevantes, comparar eventos de API e processo, revisar alterações administrativas recentes e procurar execução não autorizada no servidor EMS. Se houver sinais consistentes de exploração, a contenção deve incluir isolamento controlado do servidor, coleta forense proporcional, revisão de credenciais administrativas usadas no produto e validação das políticas distribuídas aos endpoints. O escopo deve ser expandido somente com base em evidência técnica; não há base para declarar vazamento ou movimentação lateral sem achados locais que sustentem essa conclusão.
A recorrência de duas vulnerabilidades críticas recentes no FortiClient EMS reforça a necessidade de governança específica para consoles de administração de segurança. Esses sistemas devem estar em segmentos restritos, com acesso administrativo mínimo, monitoramento de requisições, inventário de versão e processo de atualização emergencial já definido. Para organizações que dependem do EMS como parte da estratégia de endpoint, a falha deve servir como gatilho para revisar exposição, dependências, logs retidos, trilhas de auditoria e capacidade de responder fora de janelas tradicionais de mudança.
- Aplicar o hotfix para FortiClient EMS 7.4.5 e 7.4.6 e documentar a versão corrigida.
- Planejar atualização para 7.4.7 quando disponível no fluxo de correção completa.
- Restringir acesso à API e à console do EMS a redes administrativas explicitamente autorizadas.
- Revisar logs desde pelo menos 31 de março de 2026 em busca de tráfego pré-autenticado anômalo.
- Investigar execução de código ou comandos no servidor EMS sem presumir vazamento de dados sem evidência.
- Registrar exceções de correção com prazo curto, responsável técnico e monitoramento ativo.
0 Comentários