Il 16 luglio 2026 CISA ha aggiunto tre vulnerabilità attivamente sfruttate al catalogo Known Exploited Vulnerabilities: due command injection su Fortinet FortiSandbox e una deserializzazione su Microsoft SharePoint. Per tutte e tre la scadenza di remediation è il 19 luglio. Per tutte e tre il campo KEV sull’uso in campagne ransomware riporta Unknown.
Tre giorni. È tutta la distanza tra la comparsa di una vulnerabilità nel catalogo Known Exploited Vulnerabilities di CISA il 16 luglio 2026 e la data entro cui va corretta. Ad aprile lo stesso catalogo ne concedeva quattordici.
CISA ha aggiunto tre vulnerabilità attivamente sfruttate al catalogo KEV il 16 luglio 2026, tutte con scadenza 19 luglio. Due riguardano Fortinet FortiSandbox (CVE-2026-25089 e CVE-2026-39808, entrambe OS command injection raggiungibili senza autenticazione). Una riguarda Microsoft SharePoint (CVE-2026-58644, deserializzazione di dati non attendibili con esecuzione di codice da remoto). Il catalogo conta ora 1.647 voci.
Leggi i metadati KEV prima dei titoli
Per CVE-2026-25089, CVE-2026-39808 e CVE-2026-58644 il campo KEV knownRansomwareCampaignUse riporta Unknown. È il catalogo che dichiara di non avere evidenze che colleghino queste falle a una campagna ransomware. Vanno trattate per quello che il record sostiene: esecuzione di codice da remoto attivamente sfruttata su infrastruttura esposta. Nulla nella voce KEV giustifica l’etichetta ransomware, e l’assenza di quell’etichetta non riduce l’urgenza della scadenza.
Cosa ha pubblicato CISA il 16 luglio 2026
Le tre voci aggiunte al catalogo, come registrate nel JSON KEV:
- CVE-2026-25089, Fortinet FortiSandbox OS Command Injection Vulnerability. FortiSandbox, FortiSandbox Cloud e FortiSandbox PaaS contengono una command injection che consente a un attaccante non autenticato di eseguire comandi non autorizzati tramite richieste HTTP costruite ad arte. Advisory del vendor FG-IR-26-141.
- CVE-2026-39808, Fortinet FortiSandbox OS Command Injection Vulnerability. FortiSandbox contiene una command injection che può consentire a un attaccante non autenticato di eseguire codice o comandi non autorizzati tramite richieste HTTP costruite ad arte. Advisory del vendor FG-IR-26-100.
- CVE-2026-58644, Microsoft SharePoint Deserialization of Untrusted Data Vulnerability. SharePoint contiene una deserializzazione di dati non attendibili che consente a un attaccante non autorizzato di eseguire codice via rete.
- Tutte e tre sono state aggiunte il 16 luglio 2026 con dueDate 19 luglio 2026.
- L’azione richiesta per tutte e tre è applicare le mitigazioni del vendor in conformità alla Binding Operational Directive 26-04 di CISA e ai Forensics Triage Requirements, oppure dismettere il prodotto se le mitigazioni non sono disponibili.
Il batch KEV del 16 luglio in numeri
Tutti i dati sono letti direttamente dal catalogo JSON CISA Known Exploited Vulnerabilities, versione 2026.07.16. Il catalogo è il record autoritativo per dateAdded, dueDate, requiredAction e knownRansomwareCampaignUse. Nessuna interpretazione di terze parti è inclusa nei numeri sopra.
Cosa richiede davvero il catalogo
Applicare le mitigazioni secondo le istruzioni del vendor, assicurando la conformità alla guidance BOD 26-04 Prioritizing Security Updates Based on Risk di CISA e ai Forensics Triage Requirements di CISA. Seguire la guidance BOD 26-04 applicabile ai servizi cloud oppure dismettere l’uso del prodotto se le mitigazioni non sono disponibili.
Come si è chiusa la finestra di patching
Il dato interessante di questo batch non è il punteggio CVSS. È la distanza tra dateAdded e dueDate, e come quella distanza sia cambiata nel 2026 con il passaggio di CISA da BOD 22-01 a BOD 26-04. Per il quadro generale, vedi la nostra guida su decryption e recovery del ransomware.
Giorni tra inserimento nel KEV e scadenza
La finestra di remediation si è ristretta da quattordici giorni a tre
Catalogo JSON CISA KEV, versione 2026.07.16
Controlli che corrispondono a queste voci specifiche
I controlli sotto corrispondono a ciò che le voci KEV descrivono davvero, cioè esecuzione di codice da remoto senza autenticazione contro un appliance di sicurezza e un server di collaborazione. Non sono una lista di hardening generica.
| Controllo | Perché conta per questo batch KEV | Lacuna che chiude |
|---|---|---|
| Inventario degli appliance esposti su internet | Entrambe le voci FortiSandbox descrivono un attaccante non autenticato che raggiunge il prodotto via richieste HTTP | Appliance di cui nessuno è owner perché considerati strumenti di sicurezza |
| SLA di patching a tre giorni per le voci KEV | L’azione richiesta lega la remediation alle scadenze BOD 26-04, che in questo batch è il 19 luglio | Cicli di patch misurati in settimane contro un catalogo misurato in giorni |
| Sottoscrizione agli advisory del vendor | Le note KEV rimandano a FG-IR-26-141 e FG-IR-26-100 per il dettaglio delle mitigazioni | Attendere la copertura stampa invece dell’advisory PSIRT |
| Prontezza di triage forense | L’azione richiesta cita esplicitamente i Forensics Triage Requirements di CISA accanto al patching | Applicare la patch su una macchina sfruttata e distruggere le evidenze |
| Percorso di dismissione | L’azione richiesta consente di dismettere il prodotto se le mitigazioni non sono disponibili | Nessun piano per un appliance che non si riesce a correggere in tempo |
Dove si sbaglia nella pratica
I failure mode sotto non sono rischi ipotetici. Discendono direttamente dalla struttura delle voci KEV di questo batch.
- ⛔ Trattare un appliance di sicurezza come infrastruttura che protegge invece che come infrastruttura esposta. FortiSandbox è raggiungibile via HTTP in entrambe le voci.
- ⛔ Leggere un inserimento nel KEV come un allarme ransomware. Il catalogo registra Unknown sull’uso in campagne ransomware per tutte e tre le voci, e inventare quel collegamento è un errore di reporting, non una precauzione.
- ⛔ Pianificare la remediation su un ciclo mensile mentre il catalogo emette scadenze a tre giorni.
- ⛔ Applicare la patch e non fare mai triage, quando l’azione richiesta include il triage forense nell’obbligo.
- ⛔ Dare per scontato che la scadenza vincoli solo le agenzie federali, e quindi ignorare che quella scadenza esiste perché lo sfruttamento è già confermato.
La patch non dice se sei già stato raggiunto
Una voce KEV significa che lo sfruttamento è stato osservato da qualche parte, prima che la scadenza fosse fissata. Applicare la correzione del vendor chiude la porta ma non dice nulla su chi l’abbia attraversata prima. È esattamente per questo che l’azione richiesta per queste tre voci affianca alla mitigazione i Forensics Triage Requirements di CISA invece di limitarsi al patching.
Cosa fare entro il 19 luglio
Nulla di quanto segue richiede una nuova voce di budget. Discende dall’azione richiesta registrata nelle voci KEV stesse, nell’ordine che riduce l’esposizione più in fretta. Per la checklist completa vedi la guida su come prevenire un attacco ransomware.
- ✅ Verificare se FortiSandbox, FortiSandbox Cloud o FortiSandbox PaaS sono presenti in qualunque punto del parco macchine, incluse le istanze in carico al team di sicurezza e non all’IT.
- ✅ Applicare le mitigazioni degli advisory Fortinet FG-IR-26-141 e FG-IR-26-100 e la voce dell’update guide Microsoft per CVE-2026-58644.
- ✅ Controllare se le voci SharePoint aggiunte l’1 e il 14 luglio, CVE-2026-45659 e CVE-2026-56164, sono ancora aperte. Le loro scadenze sono già passate.
- ✅ Eseguire triage forense su ogni istanza raggiungibile da internet prima della correzione, invece di considerare la patch come la fine del lavoro.
- ✅ Dove un prodotto non è mitigabile in tempo, usare il percorso di dismissione che l’azione richiesta consente esplicitamente.
Il catalogo è leggibile da una macchina, quindi usalo così
CISA pubblica il KEV come feed JSON, quindi dateAdded, dueDate, requiredAction e knownRansomwareCampaignUse possono essere confrontati automaticamente con un inventario asset invece di essere letti da un articolo di giornale. In Italia la stessa logica di prioritizzazione basata sul rischio è coerente con gli obblighi di gestione delle vulnerabilità introdotti dal recepimento della direttiva NIS2 e con gli avvisi di sicurezza pubblicati dall’ACN. È anche il punto di partenza per recuperare i file crittografati se il triage rileva un’intrusione.
Fonti
Juan Ricardo Palacio
Co-fondatore e CEO per le Americhe, HelpRansomware
Juan Ricardo Palacio è ingegnere elettronico, imprenditore e specialista in telecomunicazioni, cybersecurity e digital forensics, con oltre 25 anni di esperienza professionale. Co-fondatore di HelpRansomware, opera nei campi della cyber resilience, della risposta agli attacchi ransomware, del recupero dati, della crittografia e del reverse engineering, supportando aziende e organizzazioni nella gestione di incidenti informatici ad alta criticità.
📰 Menzionato e citato su Forbes Georgia, Business Insider Africa, LA Weekly e Il Sole 24 Ore.
📅 Ultimo aggiornamento: 17 luglio 2026
