Cosa ha confermato la CISA il 18 agosto

La CISA ha aggiunto CVE-2026-33824 al proprio catalogo delle Known Exploited Vulnerabilities il 18 agosto 2026, confermando che una vulnerabilità double-free nelle IKE Service Extensions di Windows, il componente che gestisce le connessioni VPN IKEv2/IPsec, viene sfruttata attivamente. La falla raggiunge un punteggio CVSS di 9,8 su 10 e non richiede autenticazione, quindi un attaccante con accesso di rete può attivarla senza password, certificato o un punto d'appoggio precedente.

TappaData
Patch Microsoft rilasciataAprile 2026
Punteggio CVSS9,8 su 10
Inserimento nel catalogo KEV della CISA18 agosto 2026
Scadenza federale per la correzione21 agosto 2026 (già trascorsa)

La vulnerabilità colpisce le porte UDP 500 e 4500, quelle che IKEv2/IPsec usa per negoziare e mantenere un tunnel VPN, e riguarda ogni versione supportata di Windows Server, Windows 10 e Windows 11 con VPN IKEv2/IPsec esposta a internet. L'allerta della CISA è arrivata dentro un lotto di quattro CVE che comprendeva anche una falla di condivisione schermo su macOS e un bug di path traversal in VMware vCenter, ma la falla IKE di Windows presenta l'esposizione più chiara delle quattro, e la CISA ha fissato al 21 agosto 2026 la scadenza per la correzione da parte delle agenzie federali statunitensi, una scadenza già passata al momento di questa pubblicazione.

Come Unit 42 ha intercettato le connessioni di ritorno

Unit 42, la divisione threat intelligence di Palo Alto Networks, ha riferito di aver osservato un attore di lingua cinese inviare connessioni reverse-shell controllate a mano da tre endpoint VPN IKE distinti. Una reverse shell chiama verso l'esterno dalla macchina compromessa verso l'infrastruttura dell'attaccante invece di attendere una connessione entrante, e proprio per questo sopravvive alle regole del firewall orientate al traffico entrante su cui si basa gran parte della sicurezza perimetrale; il server VPN compromesso appare, a molti sistemi di monitoraggio, semplicemente come un server che apre una connessione in uscita di propria iniziativa.

L'attività manuale a tastiera significa che un operatore umano impartiva comandi in modo interattivo tramite la shell invece di eseguire uno script del tutto automatizzato, un livello di impegno che segnala un obiettivo ritenuto degno di attenzione diretta e non di una scansione indiscriminata di massa. BleepingComputer, il database CVE di SentinelOne e la Zero Day Initiative hanno ciascuno confermato i dettagli tecnici principali dopo l'allerta della CISA, e il reportage di gbhackers.com sulla ricerca di Unit 42 aggiunge il dettaglio della reverse shell che trasforma una generica falla double-free in un'intrusione documentata e ancora in corso.

Corretta ad aprile non è la stessa affermazione di sicura oggi

Microsoft ha rilasciato una correzione per CVE-2026-33824 ad aprile 2026, cinque mesi pieni prima che la CISA confermasse lo sfruttamento attivo e aggiungesse la falla al catalogo KEV. Quel divario temporale è la storia che si nasconde dietro la notizia: che una patch esista da aprile dice che Microsoft ha fatto la sua parte, ma non dice nulla sul fatto che ogni concentratore VPN esposto a internet di un'organizzazione l'abbia davvero ricevuta, e dice ancora meno sul fatto che qualcuno stesse osservando quei punti in cerca proprio del traffico in uscita da reverse shell che Unit 42 ha trovato.

"L'abbiamo corretta mesi fa" e "oggi siamo al sicuro" sono due affermazioni distinte, non una sola, e trattarle come intercambiabili è esattamente il modo in cui una correzione di cinque mesi finisce accanto a un'intrusione attiva, controllata a mano. Un concentratore VPN è un ritardatario naturale nei programmi di patching: spesso lo gestisce il team di rete e non quello che applica le patch agli endpoint, resta fuori dalle scansioni di vulnerabilità pensate per i cicli di aggiornamento tipici delle postazioni di lavoro, e non sempre può essere riavviato su una build nuova senza una finestra di manutenzione pianificata che compete con gli impegni di disponibilità. La segmentazione che limita dove può arrivare un server VPN compromesso, e il monitoraggio che segnala traffico in uscita anomalo da quel server, sono i due controlli che intercettano ciò che "la patch è arrivata ad aprile" da sola non intercetta.

Cosa verificare questa settimana

I team IT e sicurezza devono confermare la patch invece di darla per scontata: occorre verificare che ogni sistema Windows Server, Windows 10 o Windows 11 con VPN IKEv2/IPsec attiva e raggiungibile da internet abbia davvero ricevuto l'aggiornamento Microsoft di aprile 2026, e non solo che l'aggiornamento esista nel catalogo. Un gateway VPN messo in produzione o reinstallato dopo il rilascio della patch, o uno gestito da terzi, è esattamente il tipo di istanza che passa inosservata in un rollout che tutti gli altri ritengono completo.

Poi occorre verificare cosa succede dopo la conferma della patch: se il traffico UDP 500/4500 verso quel concentratore è segmentato dal resto della rete, così che un unico gateway compromesso non diventi un varco verso tutto ciò che c'è dietro, e se le connessioni in uscita dal server VPN stesso vengono monitorate per intercettare proprio il tipo di connessione reverse-shell documentato da Unit 42. Questo è esattamente il profilo che il catalogo KEV della CISA esiste per segnalare, e lo stesso profilo che agenzie nazionali come l'Agenzia per la Cybersicurezza Nazionale (ACN) trattano come priorità assoluta per chi gestisce infrastrutture VPN esposte a internet.