Il 17 giugno 2026, il team di threat research di Qualys ha pubblicato un report su FortiBleed: una campagna di abuso su larga scala contro dispositivi FortiGate management e SSL-VPN esposti a Internet. Il 18 giugno, CISA e UK NCSC hanno emesso guidance per hardening e investigazione. Il 19 giugno, Fortinet ha confermato l'analisi. La posta in gioco è un paradosso tecnico che mette in crisi il modello di difesa per patching: dispositivi tecnicamente aggiornati restano vulnerabili se credenziali e hash legacy non sono stati migrati.
- FortiBleed è credential reuse e brute-force, non una nuova vulnerabilità zero-day: Qualys e Fortinet lo documentano esplicitamente.
- Le credenziali provengono dagli incidenti FG-IR-26-060 e FG-IR-25-647, con CVE-2026-24858 e CVE-2025-59718 citate come fonti di credenziali riutilizzate.
- Le scale riportate oscillano tra ~30.800 record validati in subset, ~74.000 riferiti da CISA, ~75.000 dispositivi in analisi indipendente, ~73.900 URL firewall unici e 86.644 record in altro reporting: cifre eterogenee per oggetti, snapshot e metodi diversi, non combinali.
- Un dispositivo patchato può rimanere esposto se credenziali o materiale di configurazione sono stati copiati prima della remediation, specialmente dove la migrazione a PBKDF2 e il cleanup degli hash legacy sono incompleti.
Il meccanismo: credenziali vecchie, dispositivi "nuovi"
La campagna non sfrutta una vulnerabilità fresca. Secondo l'advisory di Qualys, FortiBleed è "driven by credential reuse and brute-force, not a single new zero-day". Fortinet ha replicato: "This is not a new Fortinet vulnerability, and this activity is not related to any recent incident or advisory".
I vettori di origine delle credenziali sono documentati. CVE-2026-24858, con CVSS 9.8 CRITICAL secondo il record NVD, è un bypass SSO autenticativo che Fortinet cita come fonte di credenziali riutilizzate nella campagna di giugno 2026. CVE-2025-59718, anch'esso CVSS 9.8 CRITICAL, è un bypass SAML di FortiCloud SSO, esplicitamente citato come "reused-credential source". CVE-2025-59719, paired advisory per FortiWeb/SSO inventory, completa il cluster. Queste CVE non sono il vettore attivo di giugno: sono la provenienza delle credenziali che alimentano l'attacco.
Il meccanismo operativo è duplice. Gli attaccanti combinano credential reuse — credenziali rubate in incidenti precedenti — con brute-force e password-spraying contro interfacce amministrative esposte a Internet. Non serve exploit: serve che le credenziali siano ancora valide o che gli hash legacy siano crackabili.
La trappola del PBKDF2 non migrato
Qui entra in gioco il nucleo tecnico del "patching illusion". FortiOS ha introdotto PBKDF2 per lo hashing delle credenziali, deprecando algoritmi legacy. Ma la migrazione è spesso incompleta: gli hash legacy possono persistere in configurazioni non pulite, in backup, in sistemi ridondanti o in istanze non toccate dall'upgrade.
Qualys scrive: "A patched device can remain exposed if credentials or configuration material were stolen before remediation, especially where PBKDF2 migration and legacy-hash cleanup are incomplete". Fortinet conferma la stessa guidance. Il risultato è che un amministratore che ha aggiornato FortiOS alla versione corretta — 7.4, 7.6 o 8.0 con PBKDF2 abilitato — può comunque vedere il proprio dispositivo compromesso se la rotazione delle credenziali non è accompagnata da verifica della configurazione e terminazione delle sessioni attive.
La persistenza è il problema più insidioso. Se un attaccante ha già ottenuto accesso amministrativo, può aver modificato la configurazione, installato meccanismi di accesso alternativi o esfiltrato materiale di autenticazione integrato — AD, LDAP, RADIUS — che sopravvive al cambio della password locale.
"factory reset the device, as changing credentials alone may not be sufficient if threat actors have obtained persistence on the device"
— UK NCSC Alert
Le scale: numeri che non si sommano
Il reporting pubblico ha prodotto cifre impressionanti che tuttavia non descrivono un universo omogeneo. Qualys elenca multiple figure con esplicito caveat: "~30.800 record validati in un subset", "~74.000 record riferiti da CISA", "~75.000 dispositivi in analisi indipendente", "~73.900 URL firewall unici", "86.644 record in altro reporting". La fonte primaria avverte che questi numeri "reflect different objects, snapshots, validation claims, and deduplication methods" e che non vanno combinati.
Cosa significa in pratica: ~73.900 URL unici sono endpoint esposti, non necessariamente compromessi. ~30.800 record validati sono un subset con claim di verifica, non un conteggio globale. I ~74.000 riferiti da CISA e gli 86.644 di altro reporting usano oggetti e metodi non dettagliati. Non esiste un numero consolidato di dispositivi effettivamente violati, e il dossier non ne fornisce uno.
Cosa fare adesso
Fortinet raccomanda specificamente: terminare tutte le sessioni attive, eseguire reset delle credenziali, implementare MFA, aggiornare a versioni 7.4/7.6/8.0 con PBKDF2 abilitato, validare la configurazione, controllare i log e ridurre la superficie di attacco esponendo meno interfacce management a Internet.
NCSC aggiunge una raccomandazione più radicale: se la compromissione è sospettata, "factory reset the device, as changing credentials alone may not be sufficient if threat actors have obtained persistence on the device". Il factory reset è l'unica garanzia di eliminare meccanismi di persistenza occulta in configurazioni modificate.
Fortinet ha inoltre dichiarato: "Fortinet has identified the potentially compromised systems, and we are proactively contacting impacted customers and will complete outreach in the days to come". Le organizzazioni con dispositivi esposti dovrebbero verificare di aver ricevuto comunicazione diretta.
Il dossier non specifica quanti dispositivi con hash legacy non migrati siano effettivamente esposti, né se credenziali da CVE-2018-13379 — la vulnerabilità del 2018 con CVSS 9.1 CRITICAL — siano ancora valide in sistemi target attuali. Questi punti restano da verificare caso per caso.
Perché questo caso rivela un fallimento sistematico
FortiBleed non è una storia di zero-day. È una storia di technical debt in cryptography configuration che diventa vulnerabilità attiva. La migrazione PBKDF2 era tecnicamente disponibile, ma la sua implementazione incompleta — hash legacy persistiti, credenziali non ruotate, sessioni non terminate — crea una finestra di esposizione che sopravvive al patching.
Il caso evidenzia tre fallimenti ricorrenti nel perimeter enterprise: esposizione di interfacze management a Internet, assenza di MFA su sistemi critici, e riutilizzo di credenziali across incidenti senza rotazione programmatica. Questi non sono bug del software: sono errori di hygiene che si cumulano in technical debt e si attivano quando la threat landscape li incontra.
Per il settore, il messaggio è che il patching è condizione necessaria ma non sufficiente. La remediation completa richiede audit delle credenziali, verifica della migrazione crittografica, e — in caso di compromissione confermata — factory reset con rebuild della configurazione da baseline trusted. Il costo operativo è superiore al semplice aggiornamento, ma è l'unico modo per chiudere la finestra che le patch da sole lasciano aperta.
Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.
Fonti
- https://blog.qualys.com/vulnerabilities-threat-research/2026/07/08/fortibleed-fortigate-credential-reuse-internet-exposed
- https://www.fortinet.com/blog/psirt-blogs/analysis-of-reported-credential-compromise-of-fortigate-devices
- https://www.ncsc.gov.uk/news/advice-following-global-targeting-of-fortinet-firewalls-and-vpn-gateways
- https://ik.imagekit.io/qualys/wp-content/uploads/2026/07/CVE-2023-27997_survival_curve-1070x499.png
- https://www.qualys.com/apps/vulnerability-management-detection-response
