CVE-2026-35616: FortiClient EMS Sotto Sfruttamento Attivo — Il Bypass Pre-Auth che Trasforma la Gestione Endpoint in un Vettore di Intrusione

Quando una vulnerabilità di bypass di autenticazione colpisce un edge device — un firewall, un VPN concentrator — il danno è grave ma circoscritto: l'attaccante entra in rete. Quando la stessa classe di vulnerabilità colpisce la console di gestione degli endpoint aziendali, il danno è di un ordine di grandezza superiore: l'attaccante non entra in rete, eredita la rete. CVE-2026-35616 appartiene a questa seconda categoria, ed è la ragione per cui Fortinet ha rilasciato la patch fuori dal ciclo ordinario e perché CISA e i partner internazionali hanno accelerato la pubblicazione degli advisory.

La vulnerabilità, classificata con punteggio CVSS 9.1, è descritta come un bypass dell'accesso alle API pre-autenticazione che porta a privilege escalation. In pratica: un attaccante non autenticato in grado di raggiungere l'interfaccia API di FortiClient EMS può costruire richieste che lo fanno riconoscere come amministratore, bypassando il controllo di autenticazione, e da lì eseguire codice o comandi non autorizzati nel contesto del servizio. I primi tentativi di sfruttamento in natura sono stati registrati il 31 marzo 2026 — prima della disclosure pubblica, segno che almeno un cluster di attaccanti aveva accesso anticipato all'informazione, sia per ricerca indipendente sia per leak della supply chain di vulnerability research.

Cos'è FortiClient EMS e Perché Rende la Vulnerabilità Così Grave

FortiClient Enterprise Management Server (EMS) è la piattaforma centrale con cui le aziende che adottano l'ecosistema Fortinet gestiscono l'agente di endpoint FortiClient. Da EMS passano il deployment dell'agente, la gestione delle policy (accesso VPN, posture antivirus, controllo applicazioni), la raccolta della telemetria di endpoint e la visibilità centralizzata sullo stato di conformità della flotta. È, in altre parole, il pannello di controllo attraverso cui si gestiscono migliaia o decine di migliaia di workstation e portatili aziendali.

Questa posizione nell'architettura spiega perché CVE-2026-35616 è particolarmente pericolosa. Un attaccante che ottiene esecuzione di codice sul server EMS non è un attaccante che ha bucato un endpoint: è un attaccante che ha preso il comando della console che distribuisce policy, script e (in alcune configurazioni) software a tutti gli endpoint gestiti. La traiettoria naturale dello sfruttamento non si ferma all'EMS — si propaga agli endpoint sottostanti attraverso il canale di gestione legittimo, con la fiducia pre-costituita che gli agenti hanno nei confronti del server di gestione. È lo stesso pattern che abbiamo visto negli attacchi a Kaseya (ransomware REvil, 2021), SolarWinds (2020), e più recentemente nel caso Stryker-Handala con Microsoft Intune (documentato da AEGIDA il 9 aprile 2026): compromettere il piano di gestione significa scavalcare ogni difesa perimetrale e ogni controllo di isolamento.

Anatomia del Bypass: Quando l'API Riconosce come Admin Senza Credenziali

La descrizione pubblica di Fortinet e gli advisory dei partner di intelligence (Arctic Wolf in particolare) convergono su una dinamica tipica di questa classe di bug: l'interfaccia API di EMS include un percorso in cui il controllo di autenticazione viene effettuato in una fase successiva rispetto all'interpretazione di alcuni parametri della richiesta. Un attaccante che costruisce una richiesta malformata in modo specifico può portare il processo a saltare il gate di autenticazione e procedere direttamente alle operazioni di gestione, che per default richiedono privilegi amministrativi.

Non è il primo bug di questa famiglia per EMS: nel 2024 CVE-2024-48887 aveva già mostrato che lo stack API della console presentava fragilità analoghe. La ricorrenza suggerisce che la superficie di attacco della console non ha ricevuto la stessa attenzione di hardening del firewall FortiGate, nonostante eserciti un ruolo architetturale di uguale o superiore criticità. È un problema strutturale dell'industria EDR/XDR: le console di gestione crescono in funzionalità molto velocemente (integrazione cloud, API per automazione, connettori di terze parti), e il rate di scoperta di vulnerabilità critiche le segue.

Lo Sfruttamento: Cosa Fa un Attaccante Dopo il Bypass

La catena di attacco osservata o plausibile, sulla base di campagne analoghe, prevede una sequenza in cinque fasi. Prima: il bypass API per ottenere ruolo amministrativo senza credenziali. Seconda: l'enumerazione della flotta di endpoint gestiti — lista di host, utenti, versioni di sistema operativo, policy applicate, stato EDR. Terza: la creazione di una policy o di uno script di deployment che esegue un payload arbitrario sugli endpoint target, sfruttando il canale legittimo agente-console. Quarta: l'attivazione della policy su un subset di endpoint ad alto valore (server di dominio, workstation di amministratori di sistema, endpoint di sviluppatori). Quinta: la cancellazione delle tracce — modifica dei log, disattivazione temporanea delle regole di alert, creazione di accessi persistenti indipendenti dall'EMS per sopravvivere alla patch.

In scenari maturi, come quelli documentati nelle campagne Handala e CyberAv3ngers, la finestra tra intrusione iniziale e impatto osservabile può essere di giorni o settimane: l'attaccante usa il tempo per mappare la rete, raccogliere credenziali, identificare i sistemi finanziari o operativi critici, prima di attivare la fase finale (esfiltrazione dati, ransomware, wiper, o una combinazione). Il difensore che scopre la compromissione solo nella fase finale ha già perso la partita: tutto il lavoro di rilevamento e risposta si concentra allora sulla mitigazione del danno, non sulla sua prevenzione.

• Fase 1 — Bypass API pre-autenticazione su EMS (CVE-2026-35616)
• Fase 2 — Enumerazione flotta endpoint, utenti, policy, EDR state
• Fase 3 — Creazione policy/script malevolo propagato via canale legittimo
• Fase 4 — Attivazione su endpoint ad alto valore (DC, admin workstation, dev)
• Fase 5 — Cancellazione tracce + persistenza indipendente dall'EMS

Chi È Esposto e Perché la Patch da Sola Non Basta

Ogni organizzazione che espone l'interfaccia amministrativa di FortiClient EMS a Internet — per ragioni di gestione di endpoint remoti, di accesso di amministratori da fuori rete aziendale, o per pigrizia di configurazione — è nella prima fascia di rischio. Gli scanner internet-wide hanno già identificato migliaia di istanze EMS esposte, e il fingerprint del servizio è riconoscibile in modo affidabile. Anche organizzazioni che mettono EMS dietro un reverse proxy o una VPN devono valutare lo scenario in cui l'attaccante acceda alla VPN con credenziali compromesse (via phishing, password spraying, o altro bug) e poi sfrutti CVE-2026-35616 dall'interno della rete amministrativa.

La patch out-of-band è necessaria ma non sufficiente. Se un'istanza è stata raggiungibile su Internet tra il 31 marzo (prima exploit osservato) e il momento dell'aggiornamento, deve essere trattata come potenzialmente compromessa. Questo impone un'indagine forense: analisi dei log API per richieste anomale su endpoint amministrativi prima del patch, confronto tra la lista di policy attive e quelle attese, ricerca di account amministrativi creati o modificati nel periodo di esposizione, verifica degli script di deployment eseguiti sugli endpoint gestiti. Solo dopo questa verifica si può considerare la patch come incidente chiuso; altrimenti si sta chiudendo la porta di ingresso mentre l'attaccante è ancora dentro.

Raccomandazioni Operative

1. 1.Applicazione immediata della patch out-of-band di Fortinet su tutte le istanze di FortiClient EMS. Non attendere la finestra di manutenzione: questa patch è una priorità paragonabile a un incidente attivo.
2. 2.Audit di esposizione: verifica se l'interfaccia di gestione EMS è stata raggiungibile da Internet in qualsiasi momento dal 31 marzo 2026 in poi. Usa Shodan, Censys o scanner interni per la conferma.
3. 3.Indagine forense delle istanze potenzialmente esposte: revisione dei log API, delle policy modificate, degli account amministrativi, degli script di deployment inviati agli endpoint nel periodo di vulnerabilità.
4. 4.Isolamento della console di gestione dalla rete utente: EMS deve stare su un segmento amministrativo dedicato, accessibile solo tramite bastion host autenticato e con MFA resistente al phishing.
5. 5.Revisione delle policy di deployment: ogni policy attiva deve essere riconducibile a un change ticket approvato. Ogni anomalia va trattata come potenziale compromissione fino a prova contraria.
6. 6.Rotazione delle credenziali amministrative usate su EMS e sui sistemi connessi (AD, certificate authority, SCCM, se integrati).
7. 7.Attivazione di alert su modifica di policy EMS e su deployment massivi non pianificati — controllo sotto-utilizzato in molte installazioni.
8. 8.Threat hunting sugli endpoint gestiti: ricerca di esecuzioni anomale di processi da FortiClient agent, creazione di scheduled task non documentati, modifica di chiavi di registro di persistenza.
9. 9.Piano di segmentazione estesa: trattare ogni console di gestione endpoint (EMS, Intune, SCCM, Workspace ONE, Jamf) come infrastruttura critica al pari dei domain controller. Stesso regime di hardening, monitoring, backup e test di ripristino.

Conclusione: Le Console di Gestione Sono il Nuovo Centro di Gravità dell'Attacco

CVE-2026-35616 non è un caso isolato: è un altro capitolo di una tendenza chiara del 2024-2026, in cui gli attaccanti hanno spostato il baricentro delle operazioni dall'endpoint singolo e dal perimetro alle piattaforme di gestione centralizzata. Kaseya, SolarWinds, Ivanti, ConnectWise, Intune, ora FortiClient EMS: la lista è lunga e destinata a crescere, perché la logica dell'attaccante è razionale. Perché compromettere mille endpoint uno alla volta, quando si può compromettere la console che li gestisce tutti?

Per i difensori, la conseguenza operativa è che il modello mentale tradizionale — "il firewall protegge il perimetro, l'EDR protegge l'endpoint, la console di gestione è uno strumento di amministrazione" — deve essere superato. La console di gestione non è uno strumento: è un asset critico, spesso il più critico della rete, perché dalla sua compromissione discende la compromissione di tutto ciò che gestisce. Hardening, segmentazione, monitoraggio e gestione delle patch su queste piattaforme devono essere al livello massimo di priorità, non una pratica di routine. CVE-2026-35616 è il promemoria di questa settimana. Il prossimo arriverà presto.