PAN-OS CVE-2026-0257: GlobalProtect patchato e sfruttabile allo stesso tempo

La scadenza FCEB per CVE-2026-0257 è stata ieri. Le agenzie civili federali statunitensi avevano tempo fino al 1 giugno 2026 per mitigare il bypass di autenticazione di Palo Alto GlobalProtect — una vulnerabilità divulgata il 13 maggio e aggiunta al catalogo Known Exploited Vulnerabilities della CISA il 29 maggio. L'advisory è pubblico da quasi tre settimane. Rapid7 ha osservato sfruttamento attivo a partire dal 17 maggio, e 8 clienti MDR su 10 sotto attacco hanno avuto sessioni VPN non autorizzate stabilite prima del contenimento.

Ecco la parte che la checklist "patch fatta, audit passato" non vede: un firewall PAN-OS pienamente patchato è ancora vulnerabile a CVE-2026-0257 se il portale GlobalProtect riusa il proprio certificato TLS per i cookie di authentication override. La fix non è la versione del firmware. La fix è una scelta di configurazione che la versione del firmware non cambia.

Cos'è realmente CVE-2026-0257

L'advisory di Palo Alto classifica la vulnerabilità come CWE-565 — reliance on cookies without validation and integrity checking. CVSS 4.0 a 7.8 (HIGH). Vector: network, non autenticato, nessuna interazione utente, complessità bassa.

Il meccanismo è abbastanza banale da essere imbarazzante. GlobalProtect supporta una feature di "authentication override" che emette un cookie dopo un login riuscito, in modo che l'utente non debba ri-autenticarsi a ogni connessione. Il cookie è cifrato e firmato con un certificato. Se l'amministratore sceglie un singolo certificato per "tutto ciò che riguarda questo portale" — TLS, firma SAML, protezione cookie — l'attaccante può estrarre la chiave pubblica dall'endpoint TLS esposto, derivare i parametri di firma, e forgiare un cookie di authentication override per qualunque utente, incluso l'account admin.

Non c'è un exploit-as-binary da rilevare sul wire. L'attaccante presenta un cookie forgiato a un portale GlobalProtect reale, e il portale valida il cookie rispetto al certificato che si fida. Il cookie supera la verifica. Il portale emette una sessione VPN. L'attaccante è dentro.

Il workaround di Palo Alto racconta tutta la storia:

Generate a new certificate exclusively for authentication override cookies and avoid reusing portal or gateway certificates.

Quella è la fix. Non l'aggiornamento del firmware — la separazione del certificato. L'aggiornamento del firmware irrigidisce la validazione del cookie, ma la misconfigurazione che ha esposto il materiale crittografico in primo luogo non è qualcosa che una patch possa risolvere. È una decisione di configurazione codificata nei template di Panorama e distribuita a migliaia di dispositivi.

La cronologia dello sfruttamento

Data	Evento
13 maggio 2026	Palo Alto pubblica l'advisory e gli hotfix PAN-OS (12.1.7, 11.2.12, 11.1.15, 10.2.18)
17 maggio 2026	Rapid7 MDR osserva i primi tentativi di sfruttamento
18 maggio 2026	Prima ondata da IP hostato su Vultr: cookie auth sospetto verso account admin locali
21 maggio 2026	Seconda ondata dal range Dromatics Systems, stesso MAC spoofato aa:bb:cc:dd:ee:ff
29 maggio 2026	CISA aggiunge CVE-2026-0257 al KEV; scadenza FCEB fissata al 1 giugno 2026
1 giugno 2026	Scadenza FCEB; Help Net Security riporta sfruttamento attivo in corso

Quattro giorni dall'advisory pubblico allo sfruttamento attivo. Dodici giorni dall'advisory all'escalation CISA. Diciannove giorni dall'advisory a un hard-stop federale. Niente di tutto questo è più insolito. Quello che è insolito è che al giorno 19 il reporting di The Hacker News conferma che gli attaccanti stanno ancora trovando istanze vulnerabili — molte delle quali eseguono versioni firmware che il vendor elenca come patchate.

Gli IOC pubblicati da Rapid7 vanno letti con attenzione perché dicono che aspetto ha la fase post-auth, non solo il cookie forge:

• IP sorgente: 104.207.144.154, 146.19.216.119, 146.19.216.120, 146.19.216.125
• Machine name presentati dalla sessione forgiata: GP-CLIENT (Linux), DESKTOP-GP01 (Windows)
• MAC spoofato consistente tra le due ondate: aa:bb:cc:dd:ee:ff — un indirizzo placeholder, non un OUI reale

Il MAC placeholder è il test del fumo. Un vero client GlobalProtect non invia mai aa:bb:cc:dd:ee:ff come hardware address. È il tipo di dettaglio che uno strato di deep-packet inspection con una baseline degli identificatori normali dei client GlobalProtect cattura alla prima sessione. Il cookie forge è invisibile a livello HTTP. La postura del client a valle no.

Perché "patchato" non equivale a "sicuro"

Il gap di audit è strutturale. La maggior parte delle grandi enterprise basa l'evidenza di conformità su tre segnali:

1. Report del vulnerability scanner — Nessus, Qualys, Rapid7 InsightVM. Controllano la versione del banner e le stringhe CPE conosciute. PAN-OS 12.1.7 risulta patchato contro CVE-2026-0257 nel database CPE. Lo scanner segna PASS.
2. CMDB / patch management — conferma che il firewall è su 12.1.7. Stato della patch = compliant.
3. Pen test o report di audit — annuale o trimestrale. L'ultimo è passato.

Tutti e tre saranno verdi su un dispositivo pienamente sfruttabile, perché nessuno di loro enumera quale certificato è legato a quale endpoint TLS e se lo stesso certificato è anche configurato per la cifratura dei cookie sul path di auth-override. Quella è una proprietà di configurazione del portale GlobalProtect, non una proprietà del binario PAN-OS.

La condizione di riuso del certificato esiste nei template PAN-OS che vengono distribuiti da anni. La maggior parte degli ambienti riesamina la propria strategia di certificati solo quando il cert scade. CVE-2026-0257 non si interessa della scadenza. Si interessa del riuso.

Auditor: "Mostrami che hai patchato CVE-2026-0257." CISO: "Ecco le versioni PAN-OS su ogni firewall. Tutti sulla hotfix corretta o successiva." Auditor: "Passa." Attaccante: forgia un cookie contro un firewall pienamente patchato

Questo è il gap. Non è specifico di Palo Alto. È specifico di una classe di CVE — chiamiamoli CVE configuration-dependent — in cui la fix del vendor è corretta, il firmware è aggiornato, e il sistema rimane esposto perché la superficie di exploit è governata da una scelta di configurazione che la patch non tocca.

Le metriche stile "patch hygiene" rendono questo gap invisibile. La dashboard dice 100% patchato. La verità è qualunque cosa dicano i template dei certificati.

Cosa i vulnerability scanner convenzionali non vedono

Uno scanner esterno generico vede il portale GlobalProtect come una di tre cose: certificato TLS, versione del banner, comportamento osservabile. Nessuna delle tre racconta del riuso della chiave di cifratura dei cookie, perché quella chiave non è mai osservabile dall'esterno. Si può enumerare la misconfigurazione solo se si comprende l'architettura di autenticazione del vendor e si chiede al dispositivo — o al management plane — quale certificato è legato a quale feature.

La maggior parte delle toolchain red team non lo farà automaticamente. ExploitDB ospita un PoC legato al primitivo di sfruttamento (forgia il cookie dalla chiave pubblica). Funzionerà se la condizione di riuso del certificato è presente. Non enumererà quali dei tuoi portali la presentano e quali no. Quel passo di enumerazione — quello che trasforma un PoC CVE in una lista degli host effettivamente vulnerabili nel tuo estate — è il gap che la validazione continua deve riempire.

Per tutto ciò che sta dopo il cookie forge, la visibilità si sposta dal firewall alla rete. La sessione forgiata atterra sull'IP VPN assegnato. Dalla prospettiva del firewall è un utente autenticato legittimo. I pacchetti successivi sono ricognizione: ARP, mDNS, port scan, enumerazione SMB, tentativi di raggiungere il domain controller. Machine learning sul wire con una baseline di come si comporta un vero utente GlobalProtect cattura la divergenza — MAC placeholder, pattern del machine name, velocità di scan, ora del giorno — prima che l'attaccante faccia pivot. Questo è il secondo tempo della difesa, e non è risolto nemmeno dalla patch del vendor del firewall.

Cosa il regolatore vuole vedere

NIS2 Titolo 13 (misure tecniche e organizzative), DORA con l'RTS sul threat-led penetration testing, NIST CSF 2.0, e ISO 27001 Annex A 8.8 (Management of technical vulnerabilities) convergono tutti sulla stessa forma di evidenza:

• Puoi dimostrare identificazione continua delle vulnerabilità note attraverso l'estate.
• Puoi dimostrare che le mitigazioni sono efficaci, non solo applicate.
• Puoi produrre evidenza datata, firmata, tamper-evident di entrambe.

Una lista di versioni è la prima. Non è la seconda né la terza. Dimostrare che la mitigazione è efficace richiede un control test — per CVE-2026-0257 significa tentare effettivamente il cookie forge contro il portale di produzione e verificare che il tentativo fallisca. È una voce di red team trimestrale nella maggior parte delle organizzazioni. Quando il pentest trimestrale successivo arriva, l'exploit sarà nel wild da 90 giorni e il dwell time di qualunque compromissione misurerà settimane.

La domanda dell'auditor non è "siete patchati?" È "mostratemi cosa avete testato, quando lo avete testato, e che l'evidenza non può essere stata modificata dopo." Una CVE configuration-dependent rompe la prima risposta se la seconda manca.

Chiudere il gap di audit

I 32 framework su cui Zero Hunt mappa continuativamente ogni finding — NIS2 Titolo 13, DORA TLPT RTS 2025, ISO 27001 Annex A 8.8 e 8.9, NIST CSF 2.0 ID.RA-01 e PR.IR-04, PCI-DSS 11.4.x, SOC 2 CC7.1 — condividono tutti un testo di controllo che mappa pulitamente su "configurazione testata, evidenza datata". Il cross-framework mapping trasforma un singolo test cookie-forge su GlobalProtect in evidenza contro otto controlli simultanei, non una singola voce in un singolo audit.

Il pilastro del Pentest Generativo gestisce poi la parte che lo scanner non può fare: lo swarm di 10 agenti AI enumera lo stato di binding dei certificati per ogni portale, istanzia il tentativo di forge in un container Docker effimero contro una superficie GlobalProtect non di produzione, e registra il risultato come finding firmato. Continuo, change-triggered: quando un nuovo certificato viene distribuito a un portale via Panorama, la campagna successiva testa la nuova configurazione entro l'ora, non il trimestre successivo. Ogni finding è firmato ECDSA al momento della scrittura — l'evidenza che il regolatore vuole è generata come sottoprodotto del test, non assemblata retroattivamente in un documento Word la settimana prima dell'audit.

La difesa davanti al cookie forge — rilevamento sul wire della divergenza post-auth — è il modello a 4 teste di AI Traffic Analysis che gira localmente sulla GPU dell'appliance a line rate multi-gigabit. Il MAC placeholder, il pattern del machine name GP-CLIENT, la velocità di scan da un IP VPN appena assegnato — sono i segnali che il modello è addestrato a catturare sul wire mentre la sessione è viva, non nel digest SIEM di domani.

La combinazione è la risposta da audit:

• Cosa hai testato, quando? Enumerazione continua e change-triggered del binding dei certificati per portale, più tentativo di forge.
• La mitigazione ha funzionato? Pass/fail firmato per portale, datato.
• Puoi provare che l'evidenza è integra? Chain of custody ECDSA dalla scrittura del finding all'export Trust Center.
• Cosa rileva il gap se passa? ML sul wire sulla sessione post-VPN-auth.

CVE-2026-0257 non è l'ultima CVE configuration-dependent. Le appliance VPN edge ne sono piene, e la prossima è già nella coda di bug bounty di qualcuno. La risposta giusta è smettere di trattare "patchato" come sinonimo di "sicuro", e cablare la chain of custody che prova quale dei due il tuo estate è davvero.

Per altro sul modello di evidenza continua applicato al primo audit NIS2, vedi il gap delle CVE note che la maggior parte degli audit incontrerà entro il 30 giugno. Per il pattern di detection del pilastro 2 quando l'attaccante è già oltre il perimetro, vedi gli 858 giorni di dwell time a UNMC REDCap.