Quasi tutti gli articoli su una vulnerabilità arrivano dopo. Dopo l'exploit pubblico, dopo le prime vittime, dopo l'inserimento nel catalogo KEV. Questo arriva prima, ed è l'unica ragione per cui vale la pena leggerlo con attenzione: la finestra è ancora aperta.

Il Nationaal Cyber Security Centrum olandese ha diffuso un avviso su due vulnerabilità critiche nei prodotti VPN di Check Point, CVE-2026-85102 e CVE-2026-85103, entrambe con punteggio CVSS 9.8. L'agenzia scrive che si attende uno sfruttamento su larga scala a breve, pur non essendo stato riportato al momento alcun proof-of-concept pubblico.

Un avviso del genere da un CSIRT nazionale europeo, in assenza di exploit circolanti, non è routine. È un segnale che vale la pena interpretare.

Le due vulnerabilità

Entrambe si collocano nel punto peggiore possibile: la fase di negoziazione VPN, cioè prima che qualunque autenticazione dell'utente sia avvenuta.

CVE-2026-85102 è una validazione impropria dei dati del certificato durante la negoziazione VPN. Un attaccante remoto può sfruttarla per eseguire codice arbitrario su un Security Gateway.

CVE-2026-85103 è un heap overflow nel decoder ASN.1 dei certificati VPN, e consente esecuzione di codice remota sia sui Security Gateway sia sui Security Management Server.

La seconda merita una sottolineatura. Il Security Management Server non è un dispositivo perimetrale: è il sistema da cui si amministrano tutti i gateway del parco. Chi lo controlla controlla le policy di sicurezza dell'intera organizzazione — può modificare regole, disattivare logging, aprire percorsi. Una RCE non autenticata su quel componente non è un incidente perimetrale, è un cambio di proprietario dell'infrastruttura di sicurezza.

Sul piano tecnico, l'ASN.1 parsing è uno dei classici della categoria: formato binario complesso, gestione manuale della memoria, input completamente sotto controllo dell'attaccante e processato prima di ogni verifica di identità. Non è la prima volta che produce RCE critiche, e non sarà l'ultima.

Check Point ha rilasciato le correzioni il 9 settembre 2026, insieme agli advisory dedicati sk1000117 e sk1000118.

Le versioni interessate sono R81.20, R82, R82.10, R81.10.x e R82.00.x, oltre ai rami già fuori supporto R80 fino a R80.40, R81 e R81.10. Su quest'ultimo punto conviene essere espliciti: per le versioni end-of-support non esiste una patch da applicare. L'unica via è l'aggiornamento a un ramo supportato, che non è un'operazione da finestra notturna ma un progetto, con test di compatibilità e possibili fermi di servizio.

Cosa significa per le aziende italiane

Check Point ha una penetrazione notevole nel mercato italiano, in particolare nella fascia medio-grande delle imprese, nel manifatturiero del Nord, nella sanità pubblica e privata, negli enti locali e presso molti MSP che gestiscono il perimetro dei clienti con firewall Check Point in multi-tenancy. Il prodotto è percepito, giustamente, come solido: ed è proprio questa reputazione a generare il problema, perché genera cicli di aggiornamento lenti. Un gateway che funziona da tre anni senza dare fastidio non viene toccato.

Ci sono tre elementi che rendono questo caso specifico più serio della media.

Il primo è che l'accesso remoto VPN non si può spegnere. Non è un servizio accessorio: dopo il 2020, per gran parte delle aziende italiane è il modo in cui i dipendenti lavorano. Le mitigazioni classiche — limitare le sorgenti, chiudere il servizio in attesa della patch — qui sono impraticabili. Il servizio deve restare acceso, quindi l'unica difesa reale è la patch.

Il secondo è il precedente storico. I gateway VPN sono, da anni, il vettore di ingresso preferito dei gruppi ransomware operanti in Italia. Il CSIRT Italia ha registrato per tutto il 2026 un'attività sostenuta di Qilin contro PMI e fornitori di servizi cloud, e la sequenza è sempre la stessa: accesso via apparato perimetrale non aggiornato, ricognizione, cifratura nel giro di giorni. Non serve immaginazione per prevedere cosa succede quando un exploit per una CVSS 9.8 su Check Point diventa disponibile.

Il terzo è il fattore MSP, e vale la pena insistere. Molte PMI italiane non sanno quale versione di Check Point stia girando sul proprio perimetro, perché il firewall è gestito da un fornitore. In questi scenari la catena di responsabilità si allunga: il contratto può prevedere la gestione degli aggiornamenti, ma la responsabilità normativa — NIS2, DORA, GDPR — resta in capo al titolare. Una telefonata al fornitore, con richiesta di conferma scritta della versione e della data di patching, costa dieci minuti ed è esattamente il tipo di documentazione che serve avere se l'incidente arriva.

Il quadro normativo

Per i soggetti essenziali e importanti ai sensi del D.lgs. 138/2024, la gestione delle vulnerabilità sugli apparati perimetrali rientra pienamente tra le misure di sicurezza richieste. Il punto meno compreso è che NIS2 non guarda solo agli incidenti, guarda al processo: in caso di verifica, non conta solo se si è stati violati, ma se esisteva una procedura documentata di gestione delle vulnerabilità e se è stata seguita. Un gateway rimasto non aggiornato per settimane dopo un avviso pubblico di un CSIRT europeo è difficile da difendere davanti a un'autorità di vigilanza.

Per il settore finanziario, DORA impone la registrazione e il trattamento delle vulnerabilità nei sistemi che supportano funzioni essenziali o importanti. La VPN di accesso remoto lo è quasi sempre.

Se lo sfruttamento si concretizza e l'attaccante raggiunge dati personali, si applicano i termini noti: pre-notifica al CSIRT Italia entro 24 ore per i soggetti NIS2, notifica al Garante entro 72 ore ex art. 33 GDPR.

Una nota che i consulenti conoscono bene ma che vale la pena ripetere: le versioni end-of-support sono un problema di conformità prima ancora che tecnico. Usare software non più supportato dal produttore per proteggere il perimetro è, in molte letture, incompatibile con l'obbligo di adottare misure adeguate allo stato dell'arte. Chi è ancora su R80.x o R81 ha una scadenza che non è quella della patch, è quella del piano di migrazione.

Cosa fare subito

  • Applicare le correzioni rilasciate il 9 settembre, seguendo gli advisory sk1000117 e sk1000118. La priorità non è discutibile: sono due CVSS 9.8 pre-autenticazione su un servizio esposto a internet.
  • Verificare la versione realmente in esecuzione su gateway e Management Server, non quella dell'inventario o del contratto. R81.20, R82, R82.10, R81.10.x e R82.00.x sono interessate.
  • Patchare per primo il Security Management Server, non ultimo. È il componente il cui compromesso produce l'impatto maggiore, ed è quello che nella pratica viene aggiornato per ultimo perché "non è esposto". CVE-2026-85103 dice il contrario.
  • Se si è su una versione end-of-support (R80–R80.40, R81, R81.10): non c'è patch. Avviare oggi il piano di migrazione a un ramo supportato, e nel frattempo restringere il più possibile le sorgenti ammesse alla negoziazione VPN e aumentare il monitoraggio.
  • Chiedere conferma scritta al fornitore o MSP, se il perimetro è gestito da terzi: versione installata, data di applicazione della patch, eventuali sistemi rimasti scoperti e perché. Conservare la risposta.
  • Aumentare il monitoraggio sui gateway nella finestra che precede il patching: crash o riavvii anomali dei processi VPN, negoziazioni fallite ripetute dalla stessa sorgente, comportamenti insoliti nei log del Management Server.
  • Verificare gli account amministrativi del Management Server: MFA attiva, interfaccia di gestione non raggiungibile da internet, nessuna credenziale condivisa fra più tecnici.
  • Assicurarsi che i log dei gateway siano replicati fuori dal perimetro Check Point, su un SIEM o un collector separato. Se il compromesso arriva al Management Server, i log conservati lì smettono di essere una fonte affidabile.

Il punto

C'è una differenza sostanziale tra questo articolo e la maggior parte di quelli che scriviamo su una vulnerabilità critica: oggi non c'è ancora un exploit pubblico. Nessuno ha ancora perso dati per queste due CVE, per quanto risulta.

La gestione delle vulnerabilità viene raccontata quasi sempre come attività reattiva, e nella pratica lo è: si corre quando la notizia esplode. Ma il valore di un programma di patching si misura precisamente nei giorni come questi, quando la patch esiste da una settimana, un CSIRT nazionale ha avvisato, e lo sfruttamento non è ancora iniziato.

Quella distanza — tra il 9 settembre, data della patch, e il giorno in cui il primo exploit funzionante circolerà — è tutto il vantaggio che si avrà. Vale la pena usarlo.