CVE-2026-24858

Falha de bypass de autenticação (CWE-288) no mecanismo de SSO administrativo via FortiCloud, presente em praticamente toda a linha de produtos Fortinet (FortiOS, FortiProxy, FortiManager, FortiAnalyzer, FortiNAC-F, FortiWeb e, segundo o advisory do fornecedor, também FortiSwitchManager). Um atacante com uma conta FortiCloud legítima e ao menos um dispositivo registrado nela consegue autenticar-se como administrador em dispositivos de terceiros registrados em outras contas FortiCloud — desde que o SSO FortiCloud esteja habilitado nesses dispositivos. Importa porque já houve exploração confirmada em massa antes da divulgação pública, com criação de contas administrativas persistentes e exfiltração de configuração dos equipamentos comprometidos.

O SSO administrativo do FortiCloud deveria vincular estritamente cada dispositivo registrado à conta FortiCloud que o registrou: só administradores dessa conta deveriam conseguir autenticar via SSO naquele dispositivo específico. A falha (CWE-288, Authentication Bypass Using an Alternate Path or Channel) está em como essa vinculação dispositivo-conta é validada no fluxo de SSO — existe um caminho alternativo de autenticação que não reforça corretamente esse isolamento, permitindo que a identidade validada para a conta A seja aceita como administrador legítimo em um dispositivo pertencente à conta B.

O ponto crítico é que essa é uma falha *nova*, distinta das duas vulnerabilidades de bypass SSO via FortiCloud divulgadas em dezembro de 2025 (CVE-2025-59718 e CVE-2025-59719, FG-IR-25-647), que exploravam SAML malformado. A Fortinet identificou exploração em dispositivos já totalmente corrigidos contra aquelas duas CVEs, o que indicou um vetor de ataque diferente e levou à descoberta desta falha.

O fornecedor não publicou detalhes de código ou do exato defeito de validação — apenas a classificação CWE-288 e a descrição funcional do impacto. Não há indicação pública de que o bypass dependa de manipulação de asserção SAML, token ou parâmetro específico; o que se sabe é o resultado observado: login SSO bem-sucedido com perfil super_admin em dispositivo de conta alheia.

Um ponto que a manchete do CVSS 9.4/9.8 esconde: o SSO via FortiCloud não vem habilitado de fábrica. Ele só passa a existir quando um administrador registra o dispositivo no FortiCare pela GUI e não desativa explicitamente a opção "Allow administrative login using FortiCloud SSO" durante o registro. Ambientes que nunca registraram o equipamento no FortiCare, ou que desativaram esse toggle, não expõem essa superfície.

O vetor é de rede, sem interação do usuário e sem necessidade de credenciais válidas no dispositivo-alvo (PR:N/UI:N/AV:N no CVSS) — a única credencial que o atacante precisa é uma conta FortiCloud própria com pelo menos um dispositivo registrado a ela, algo que qualquer pessoa pode obter criando uma conta gratuita e registrando um equipamento Fortinet (ou possivelmente virtual/de teste). A partir daí, o SSO é usado para autenticar como administrador em dispositivos de outras contas que tenham FortiCloud SSO habilitado e sejam alcançáveis via internet.

Exploração ativa foi confirmada pela própria Fortinet: duas contas FortiCloud maliciosas foram identificadas abusando do mecanismo, bloqueadas em 22/01/2026. O padrão observado pós-login é consistente: autenticação SSO com perfil super_admin, seguida da criação de uma conta administrativa local (nomes como audit, backup, itadmin, secadmin, support, entre outros) para garantir persistência caso a conta SSO seja revogada, e download do arquivo de configuração do dispositivo — o que expõe segredos de configuração, chaves e topologia de rede.

A CISA incluiu a CVE no catálogo KEV no mesmo dia da publicação (27/01/2026), com prazo de mitigação de apenas 3 dias (30/01/2026), refletindo a gravidade e a exploração já em curso. Não há relato de uso em campanhas de ransomware até o momento, segundo a própria entrada do KEV.

A correção definitiva é atualizar para as versões corrigidas por produto/branch (ver campo versions_fixed). A Fortinet também tomou uma ação server-side: em 26/01/2026 desabilitou o FortiCloud SSO globalmente para conter a exploração, e ao reabilitá-lo em 27/01/2026 passou a bloquear logins originados de firmwares vulneráveis. Isso reduz o risco imediato, mas é um controle temporário e fora do controle do cliente — não substitui a atualização, porque depende inteiramente de a Fortinet manter essa restrição do lado do serviço em nuvem.

Como paliativo controlável pelo cliente, é possível desabilitar o login via FortiCloud SSO no próprio dispositivo: em FortiOS/FortiProxy, System > Settings, desligando "Allow administrative login using FortiCloud SSO" (ou via CLI, `config system global` / `set admin-forticloud-sso-login disable`); em FortiManager/FortiAnalyzer, System Settings > SAML SSO, desligando "Allow admins to login with FortiCloud" (ou via CLI, `config system saml` / `set forticloud-sso disable`). O custo é perder a conveniência do SSO centralizado — não há perda funcional relevante além disso. Adicionalmente, restringir o acesso administrativo por local-in policy (limitando IPs de origem para a interface de gestão) reduz a superfície geral, mas não neutraliza especificamente este bypass se o SSO permanecer habilitado.

Setups usando Custom IdP para SSO (incluindo FortiAuthenticator) não são afetados — isso não é mitigação a ser aplicada, é uma condição já fora do escopo do problema. FortiManager Cloud, FortiAnalyzer Cloud e FortiGate Cloud (as ofertas SaaS) também não são impactados. Não existe mitigação via WAF, já que o problema está na lógica de validação de identidade entre contas, não em um payload filtrável na camada HTTP.

O log de login administrativo (logid=0100032001, logdesc="Admin login successful") mostra method="sso" e o campo ui="sso()" quando a autenticação ocorreu via FortiCloud SSO; revisar todas as entradas com profile="super_admin" via SSO originadas de IPs que não correspondem à infraestrutura de gestão conhecida é o sinal mais direto. As contas usadas pelo(s) atacante(s) observadas até a divulgação foram cloud-noc@mail.io, cloud-init@mail.io, heltaylor.12@tutamail.com e support@openmail.pro, e os IPs incluem uma faixa Cloudflare (104.28.244.x, 104.28.212.x, 104.28.195.x, 104.28.227.x) além de 163.61.198.15 e 38.54.6.28 — mas a própria Fortinet alerta que essas contas e IPs provavelmente já mudaram, então a ausência desses indicadores específicos não garante ausência de exploração.

O segundo sinal forte é pós-exploração: criação de conta administrativa local (logid=0100044547, logdesc="Object attribute configured", cfgpath="system.admin") com nomes como audit, backup, itadmin, secadmin, support, backupadmin, deploy, remoteadmin, security, svcadmin, system ou adccount, tipicamente minutos após um login SSO. Qualquer conta admin local não reconhecida pela equipe, combinada com histórico de download de arquivo de configuração, deve ser tratada como indicador de comprometimento e o dispositivo, como potencialmente sob controle do atacante.