Il 20 ottobre 2026 Palo Alto Networks ha aggiornato il proprio bollettino di sicurezza confermando che i gruppi ransomware Qilin e INC stanno sfruttando attivamente una falla nel portale GlobalProtect di PAN-OS per aprire sessioni VPN senza alcuna credenziale valida, autenticazione a due fattori compresa. La vulnerabilità, identificata come CVE-2026-0257, era già stata corretta a metà maggio 2026, ma a distanza di cinque mesi resta presente su un numero molto alto di apparati ancora raggiungibili da internet. Per una PMI che usa una VPN aziendale per far lavorare da remoto dipendenti e fornitori, la domanda utile non è come si è svolto l'attacco, ma cosa verificare subito sui propri apparati.
Una falla corretta a maggio, ancora sfruttata a ottobre
Palo Alto Networks ha pubblicato l'avviso su CVE-2026-0257 il 13 maggio 2026, con un aggiornamento il 3 giugno. La vulnerabilità è stata inserita nel catalogo delle falle note e sfruttate della statunitense CISA già il 29 maggio, con l'obbligo per le agenzie federali USA di mettere in sicurezza i propri apparati entro il 1? giugno. Nonostante questo, la società di sicurezza Rapid7 ha confermato sfruttamento attivo della falla in ambienti di più clienti già a distanza di poche settimane dalla patch, e l'unità di ricerca Unit42 di Palo Alto ha aggiornato il proprio threat brief il 20 ottobre 2026 segnalando attività in corso da parte dei gruppi ransomware Qilin (tracciato anche come Spikey Scorpius) e INC (Tarnished Scorpius), oltre a un terzo gruppo collegato al ransomware Settra. Secondo il servizio di monitoraggio Shadowserver, oltre 167.000 istanze del portale GlobalProtect risultano ancora esposte pubblicamente su internet: non è possibile sapere quante di queste girino effettivamente su versioni vulnerabili, ma il dato da solo indica quanto lentamente proceda l'aggiornamento su scala globale. Gli attacchi documentati da Palo Alto hanno colpito aziende di manifattura, sanità, finanza, logistica e trasporti, servizi professionali e legali, istruzione, ospitalità, retail, energia e pubblica amministrazione: settori molto simili a quelli di una tipica base clienti di una PMI italiana.
Perché in questo caso l'MFA non ha protetto nessuno
Il punto più importante da capire non è tecnico ma pratico: la falla non sta nell'autenticazione a due fattori in sé, sta in una funzione accessoria del gateway che, se configurata in un certo modo, permette di scavalcarla del tutto. GlobalProtect include una funzione non attiva di default chiamata «authentication override», pensata per riconnettere automaticamente un utente già autenticato senza fargli reinserire ogni volta credenziali e codice OTP. Questa funzione si basa su un cookie di sessione cifrato con un certificato. Sulle versioni vulnerabili, se quel certificato è condiviso con il servizio HTTPS del portale, il gateway non verifica la firma del cookie dopo averlo decifrato: chi riesce a recuperare la chiave pubblica dal certificato HTTPS esposto pubblicamente può quindi costruire da zero un cookie che il sistema accetta come valido, ottenendo una sessione VPN come se avesse già completato login e secondo fattore. L'attaccante non intercetta né indovina il codice OTP: salta a piè pari l'intero meccanismo che normalmente lo richiede. Per chi gestisce l'IT in azienda, il punto da ricordare è che una funzione accessoria pensata per comodità, su un apparato di perimetro, può annullare un controllo di sicurezza altrimenti solido: per questo la patch e la configurazione del gateway contano tanto quanto l'MFA imposta agli utenti.
Cosa controllare subito sui propri apparati Palo Alto
Il primo passo è verificare la versione di PAN-OS installata sui propri firewall e portali GlobalProtect. Secondo l'avviso ufficiale di Palo Alto risultano vulnerabili, tra le altre, le versioni:
- PAN-OS 12.1 precedenti alla 12.1.4-h6 o alla 12.1.7
- PAN-OS 11.2 precedenti alla 11.2.4-h17, 11.2.7-h14, 11.2.10-h7 o alla 11.2.12
- PAN-OS 11.1 precedenti alla 11.1.15 (e alle relative hotfix intermedie)
- PAN-OS 10.2 precedenti alla 10.2.18-h6 (e alle relative hotfix intermedie)
- Prisma Access nelle versioni 10.2 e 11.2 meno recenti
Se l'aggiornamento immediato non è possibile, Palo Alto indica due mitigazioni applicabili da console: dedicare al cookie di «authentication override» un certificato separato, non condiviso con il servizio HTTPS del portale, oppure disattivare del tutto questa funzione se non viene usata attivamente. Un apparato esposto da mesi senza patch va inoltre considerato potenzialmente già raggiunto: l'aggiornamento non basta da solo, va accompagnato da una verifica che non siano già presenti sessioni, account o configurazioni anomale.
Quali log delle sessioni VPN controllare
Le analisi di Unit42 sugli attacchi reali indicano alcuni segnali concreti da cercare nei log di autenticazione del portale e del gateway GlobalProtect:
- Nomi host generici o anomali associati alle sessioni, come stringhe del tipo «WINDOWS-LAPTOP-001», «DESKTOP-GP01» o «GP-CLIENT», poco plausibili come nome reale di un pc aziendale
- Indirizzi MAC segnaposto evidenti, come «aa:bb:cc:dd:ee:ff», che non corrispondono a un dispositivo fisico reale
- Campo dominio vuoto abbinato a una versione del sistema operativo generica (ad esempio Windows 10 Pro) su endpoint che in azienda dovrebbero sempre risultare uniti al dominio aziendale
- Sessioni aperte in orari insoliti, da indirizzi IP o paesi mai visti prima rispetto allo storico di dipendenti e fornitori autorizzati
- Tentativi di autenticazione RDP o SMB verso altri sistemi interni avviati subito dopo l'apertura di una sessione VPN, segno tipico del movimento laterale osservato in questi attacchi
Un confronto periodico tra l'elenco delle sessioni VPN attive e l'elenco reale di persone autorizzate a collegarsi da remoto resta il controllo più semplice ed efficace, ma va fatto con continuità, non solo dopo che una notizia come questa arriva sui giornali.
Perché bisogna controllare anche VMware e i backup
Negli attacchi documentati da Unit42, una volta dentro la rete tramite la VPN compromessa, Qilin e INC non si fermano al primo server raggiunto: puntano in modo specifico all'infrastruttura di virtualizzazione, arrivando a compromettere la console di gestione vCenter e a disattivare i controlli di sicurezza sugli hypervisor ESXi per estrarre offline le credenziali del controller di dominio direttamente dai dischi virtuali. In alcuni casi la falla viene combinata con CVE-2023-27532, una vulnerabilità nota di Veeam Backup & Replication, per estendere l'accesso fino ai sistemi che custodiscono le copie di backup. Per una PMI questo significa che non basta verificare il gateway VPN: va controllato se la rete di gestione di eventuali server VMware ESXi o vCenter è effettivamente separata dalla rete degli utenti VPN, se Veeam o altri sistemi di backup collegati alla stessa rete sono aggiornati, e se esistono copie di backup isolate o immutabili non raggiungibili dalla rete aziendale principale. Una VPN violata che porta dritta ai backup vanifica anche un piano di disaster recovery ben progettato sulla carta.
Un presidio costante sul perimetro di rete
Il caso di CVE-2026-0257 mostra che individuare una configurazione di rischio come quella del certificato condiviso per il cookie di «authentication override» richiede di seguire con continuità gli avvisi dei produttori e di saperli tradurre in verifiche concrete sui propri apparati, non un controllo che si esaurisce installando gli aggiornamenti generici quando capita. Hi-Keep segue proprio questo tipo di attività per le PMI che si affidano ai suoi servizi di Cyber Security e Networking: verifica della versione e della configurazione di sicurezza dei gateway VPN in uso, controllo dei log di accesso remoto per individuare sessioni anomale, e valutazione della segmentazione tra rete VPN, infrastrutture di virtualizzazione e sistemi di backup. Chi gestisce apparati Palo Alto o altre soluzioni VPN aziendali e vuole una verifica puntuale della propria esposizione può rivolgersi a Hi-Keep per un controllo mirato della configurazione e dei log del proprio perimetro di rete.