CVE-2026-19490: primi tentativi di sfruttamento sull’authentication bypass di Citrix NetScaler

Un exploit pubblico il 2 settembre, i primi tentativi osservati il giorno dopo: la falla che consente di aggirare l’autenticazione su NetScaler ADC e Gateway è passata in ventiquattro ore dalla teoria alla pratica. Citrix dichiara che non esistono workaround, e il solo aggiornamento non chiude la partita.

Da rischio teorico a sfruttamento osservato

Il 19 agosto 2026 Citrix ha pubblicato il bollettino CTX696939, che documenta due vulnerabilità in NetScaler ADC e NetScaler Gateway. La più grave è la CVE-2026-19490, un authentication bypass con punteggio CVSS v4.0 pari a 9.3, classificato come CWE-288, ossia aggiramento dell’autenticazione attraverso un percorso o un canale alternativo. Il vettore descrive un attacco sfruttabile da remoto, a bassa complessità, senza privilegi né interazione dell’utente, con impatto elevato su riservatezza, integrità e disponibilità del sistema colpito. La seconda, CVE-2026-19489 (CVSS 8.8), è un memory overflow che interessa unicamente le configurazioni con gruppi Large Scale NAT e SIP ALG abilitato, quindi con una superficie di esposizione molto più ristretta.

Per due settimane la CVE-2026-19490 è rimasta un rischio potenziale. Il quadro è cambiato quando, il 2 settembre, è stato creato su GitHub un repository con un proof of concept che richiama esplicitamente il bollettino. Il giorno successivo un sensore della società di vulnerability intelligence Previdian ha intercettato le prime richieste corrispondenti a quell’exploit. La scheda di tracciamento tenuta dalla società, aggiornata al 4 settembre, riporta dieci tentativi complessivi provenienti da sei indirizzi IP unici, geolocalizzati in Australia, Germania, Giappone e Stati Uniti, e attribuisce allo sfruttamento attivo un livello di confidenza medio, sostenuto da tre elementi: la telemetria propria, l’attestazione di terze parti e la disponibilità pubblica dell’exploit.

Ventiquattro ore tra la comparsa dell’exploit e i primi tentativi osservati: è questo il dato che dovrebbe orientare la priorità di intervento, più del punteggio CVSS.

Il numero degli indirizzi è cresciuto nel corso della rilevazione, ed è la ragione per cui in giro si leggono cifre diverse: il 3 settembre Ryan Dewhurst, fondatore di Previdian, aveva parlato a BleepingComputer di tre indirizzi distinti tra Australia, Stati Uniti e Germania.

Due precisazioni sono doverose, e vengono dalla fonte stessa. Dewhurst ha sottolineato che si tratta di tentativi di sfruttamento, non della conferma di compromissioni riuscite su sistemi reali. E la rilevazione, come indica la stessa scheda, poggia su un solo sensore: è un segnale, non una misura della campagna.

Sul versante istituzionale, oltre al richiamo di Citrix di metà agosto, il Centre for Cybersecurity Belgium, che opera come centro nazionale di coordinamento NCC-BE, ha pubblicato il 4 settembre un avviso sui tentativi di sfruttamento della vulnerabilità, invitando gli amministratori a dare priorità all’aggiornamento di tutte le appliance vulnerabili.

Chi è vulnerabile, e perché questo bypass è difficile da vedere

La vulnerabilità interessa le appliance configurate come virtual server AAA oppure come Gateway nelle funzioni di SSL VPN, ICA Proxy, CVPN e RDP Proxy. Sono quindi coinvolti esattamente i dispositivi che governano l’accesso remoto: il perimetro logico dell’organizzazione.

Il dettaglio operativo che conta di più, e che nella copertura della notizia resta spesso implicito, riguarda i prerequisiti, che variano in funzione della build installata e della presenza di una SAML action:

• sulle versioni 14.1-43.56 e successive, e 13.1-61.28 e successive, lo sfruttamento richiede che sia configurata una SAML action oltre al Gateway o al virtual server AAA;
• sulle versioni 14.1-43.55 e precedenti, e 13.1-61.27 e precedenti, è sufficiente la presenza di un Gateway o di un virtual server AAA, senza alcun requisito aggiuntivo;
• le installazioni 13.1 FIPS risultano interessate quando l’appliance è configurata come Gateway o virtual server AAA.

La conseguenza è controintuitiva ma decisiva: più il firmware è vecchio, più ampia è la condizione di vulnerabilità. Le organizzazioni che hanno rinviato gli aggiornamenti non sono soltanto in ritardo, sono esposte su una superficie più larga.

Una precisazione va fatta proprio sul ruolo del SAML, perché si presta a un equivoco che circola già. Che su alcune build serva una SAML action configurata non significa che la vulnerabilità consista nella falsificazione di asserzioni SAML o nella rottura della relativa catena di firme: la presenza del SAML è un prerequisito di configurazione, non necessariamente il meccanismo dell’attacco. Citrix non ha pubblicato dettagli implementativi, e gli analisti che hanno esaminato il caso si sono astenuti dal ricostruire il meccanismo in assenza di quei dettagli. Chi legge un proof of concept di terze parti farebbe bene ad applicare la stessa cautela alla descrizione che quel codice dà di sé.

Sul piano della rilevabilità, e non della gravità assoluta, un authentication bypass su un concentratore VPN pone un problema diverso e per certi versi peggiore di una esecuzione di codice remota: l’accesso iniziale non richiede di installare nulla. L’attaccante ottiene una sessione che, agli occhi dei sistemi a valle, è indistinguibile da quella di un dipendente legittimo. Nel momento dell’ingresso non c’è dropper, non c’è beacon, non c’è artefatto sul disco: c’è un utente che si autentica e comincia a muoversi. È il tipo di compromissione che sfugge alle logiche di detection basate sull’endpoint e che emerge, quando emerge, dall’analisi comportamentale delle sessioni.

Le versioni corrette e il nodo dei workaround

Le build che risolvono la vulnerabilità sono:

Ramo	Build corretta
NetScaler ADC e Gateway 14.1	14.1-73.32 e successive
NetScaler ADC e Gateway 13.1	13.1-63.21 e successive
14.1 FIPS	14.1-73.32 FIPS e successive
13.1 FIPS e NDcPP	13.1-37.277 e successive

Su questo punto serve una precisazione che cambia il modo di pianificare l’intervento: alla voce workaround e fattori di mitigazione, il bollettino Citrix riporta “None”. Non esiste cioè un ripiego riconosciuto dal vendor, e l’unica risposta prevista è l’aggiornamento.

Circola, riportata da Help Net Security, la possibilità di una mitigazione basata su firme applicabile tramite NetScaler Console sui firmware successivi a 14.1-60.52 e a partire da 13.1-63.16, che dispongono della funzione Global Deny Lists. È una capacità del prodotto, non una misura che il bollettino avalli per questa vulnerabilità. Chi la adotta lo fa come tampone in attesa della finestra di manutenzione, e ha tutto l’interesse a verbalizzarla come tale: un ripiego documentato, con la sua motivazione e la sua scadenza, regge a un’ispezione; un ripiego non documentato no.

Sul fronte dell’esposizione, i conteggi Shadowserver riportati da BleepingComputer indicano oltre 22.000 appliance NetScaler ADC e quasi 1.700 istanze Gateway raggiungibili da internet a livello globale. Il numero va maneggiato con cautela: non è dato sapere quanti di quei sistemi siano honeypot, quanti abbiano una configurazione effettivamente vulnerabile e quanti siano già stati aggiornati. La vista collegata, che riguarda le istanze Gateway, è raggruppata per Paese, quindi chi vuole la fotografia italiana può leggerla direttamente lì, tenendo presente che conta dispositivi esposti e non vulnerabili.

Un precedente di pochi mesi fa

Le ventiquattro ore tra exploit pubblico e primi tentativi non sono un’anomalia di questa vicenda, ed è quanto era già accaduto sullo stesso prodotto in primavera.

Il 23 marzo 2026 Citrix aveva pubblicato l’avviso per altre due falle NetScaler, le CVE-2026-3055 e CVE-2026-4368. La prima, anch’essa con punteggio 9.3, è finita nel catalogo delle vulnerabilità attivamente sfruttate della CISA entro una settimana dall’avviso e comunque entro la fine dello stesso mese, con un termine di pochi giorni imposto alle agenzie federali statunitensi per l’aggiornamento.

Il dato d’insieme è più eloquente del singolo caso. Secondo il conteggio di BleepingComputer sul catalogo della CISA, da novembre 2021 sono ventitré le vulnerabilità Citrix classificate come sfruttate in rete, sei delle quali utilizzate anche da gruppi ransomware. Su questi apparati la sequenza avviso, analisi pubblica, sfruttamento non è un’eventualità remota, è lo schema ricorrente.

Proprio questo precedente suggerisce una considerazione, che è redazionale e non un dato. Il catalogo KEV della CISA viene spesso usato, anche fuori dagli Stati Uniti, come soglia implicita per far scattare un intervento urgente, ma è uno strumento rivolto alle agenzie federali statunitensi e non ha valore prescrittivo per un’organizzazione italiana. Usarlo come innesco è per di più una scelta fragile, perché l’inserimento nel catalogo certifica uno sfruttamento già in corso e arriva quindi, per definizione, dopo che la finestra di prevenzione si è chiusa. Il caso in esame lo conferma dal lato opposto: alla verifica del 5 settembre la CVE-2026-19490 non risulta nel catalogo, pur avendo punteggio 9.3, un exploit pubblico dal 2 settembre e tentativi osservati dal 3. Il segnale che conta non è l’ingresso in un elenco estero, è la combinazione di quei tre elementi, che qui era completa da giorni.

Threat hunting: cosa cercare, e perché la patch non basta

Aggiornare è necessario, non sufficiente. La lezione della CitrixBleed del 2023 (CVE-2023-4966) è stata proprio questa: un token di sessione sottratto resta valido dopo l’aggiornamento e consente, come rilevò allora Tenable, di aggirare l’autenticazione anche dove è attiva l’autenticazione a più fattori. Fu lo stesso vendor a raccomandare, dopo l’upgrade, la rimozione delle sessioni attive e persistenti con i comandi kill aaa session -all , kill icaconnection -all , kill rdp connection -all , kill pcoipConnection -all e clear lb persistentSessions .

Il bollettino per la CVE-2026-19490 non contiene indicazioni analoghe, quindi quella che segue è una sequenza derivata da quel precedente, non una prescrizione del vendor per questa vulnerabilità.

1. Inventario. Individuare tutte le appliance con Gateway o virtual server AAA configurati, rilevando firmware e presenza di SAML action. NetScaler Console mette a disposizione una funzione di rilevamento per CVE con avvio manuale della scansione.
2. Aggiornamento, con priorità alle appliance esposte su internet e ai firmware più datati, che come visto sono vulnerabili in condizioni più ampie.
3. Terminazione delle sessioni attive e persistenti dopo l’aggiornamento, seguita dalla rotazione delle credenziali e dei segreti gestiti dalle appliance.
4. Ricerca retrospettiva nei log. Le evidenze pubbliche partono dal 3 settembre, ma il punto di ingresso esiste da prima del bollettino e nulla esclude che qualcuno lo conoscesse per conto proprio: il 19 agosto è quindi il punto di partenza minimo ragionevole, non un confine. Da cercare: sessioni prive di un corrispondente evento di autenticazione, richieste SAML anomale, accessi da aree geografiche o intervalli di indirizzi inconsueti, modifiche di configurazione successive ad attività sospetta.
5. Correlazione a valle, perché il segnale più affidabile non è sull’appliance ma su ciò che è accaduto dopo: autenticazioni verso applicazioni interne provenienti da sessioni VPN senza storia, movimenti laterali, enumerazione di directory.

Il punto quattro è quello che distingue una risposta seria da una spunta su un foglio di calcolo. Se dall’analisi non emerge nulla, il risultato va comunque verbalizzato: in un’eventuale interlocuzione con l’autorità, l’assenza documentata di evidenze vale infinitamente più dell’assenza di documentazione.

Vale la pena aggiungere che, per le organizzazioni che ricadono nel perimetro NIS, l’esito di quella ricerca non resta un fatto interno. Se emergono evidenze di accesso non autorizzato scattano termini di notifica stretti verso il CSIRT Italia, e le fattispecie da notificare non sono le stesse per i soggetti essenziali e per quelli importanti: ne trattiamo nell’analisi dedicata agli incidenti significativi di base.

Il nodo strutturale

Ogni ciclo si ripete con la stessa meccanica: dispositivo di frontiera, vulnerabilità pre-autenticazione, PoC pubblico, sfruttamento nel giro di ore. I concentratori VPN e i gateway di accesso remoto restano il punto debole strutturale delle architetture aziendali perché concentrano una funzione critica in un software monolitico, esposto per definizione e aggiornabile solo con una finestra di manutenzione.

Le contromisure che riducono davvero l’impatto sono note e poco praticate: limitare l’interfaccia di gestione a intervalli di indirizzi amministrativi, separare il piano di gestione da quello di produzione, applicare virtual patching a monte con un web application firewall, segmentare ciò che sta oltre il gateway in modo che una sessione compromessa non si traduca automaticamente in accesso alla rete piatta. Nessuna di queste misure impedisce lo sfruttamento della CVE-2026-19490. Tutte riducono ciò che l’attaccante ottiene una volta dentro, che è la variabile su cui si gioca la differenza tra un incidente da notificare e una crisi da gestire.