Citrix NetScaler, patch da rifare: zero-day SAML CVE-2026-88779 già sfruttata

🛡️ Executive Summary

• CVE-2026-88779 colpisce NetScaler ADC e Gateway configurati come SAML SP o IdP e può provocare denial of service senza autenticazione.
• Citrix conferma attacchi mirati e impone un nuovo upgrade anche a parte degli appliance appena aggiornati contro le zero-day di settembre.
• CISA ha inserito la falla nel catalogo KEV; le ipotesi di esecuzione remota di codice restano invece non confermate dal vendor.

Citrix ha dovuto riaprire in pochi giorni il dossier NetScaler con una nuova patch d’emergenza. La vulnerabilità CVE-2026-88779, classificata con CVSS 8.7, interessa NetScaler ADC e NetScaler Gateway quando l’appliance è configurata come SAML Service Provider o SAML Identity Provider ed è già stata sfruttata in attacchi reali. Il dettaglio più rilevante non è soltanto l’ennesima falla su un dispositivo esposto al perimetro: gli amministratori che avevano appena installato gli aggiornamenti rilasciati per le zero-day di fine settembre devono verificare la configurazione e, se rientra nelle precondizioni indicate da Citrix, aggiornare nuovamente. CISA ha inserito la falla nel catalogo Known Exploited Vulnerabilities, trasformando una vulnerabilità descritta dal vendor come denial of service in una priorità operativa immediata.

CVE-2026-88779 colpisce l’autenticazione SAML di NetScaler

Nel bollettino CTX697174 di Citrix CVE-2026-88779 viene descritta come una memory overflow vulnerability riconducibile a CWE-119, con impatto dichiarato sulla disponibilità del servizio. La superficie non coincide con ogni installazione NetScaler: il requisito tecnico è la presenza di una configurazione SAML, identificabile con add authentication samlAction per il ruolo SP oppure add authentication samlIdPProfile per il ruolo IdP. Sono vulnerabili NetScaler ADC e NetScaler Gateway 14.1 precedenti alla build 14.1-73.41 e la linea 13.1 precedente alla 13.1-64.28; per le edizioni FIPS e NDcPP Citrix indica rispettivamente 14.1-73.41 FIPS e 13.1-37.282 come soglie corrette. Il vendor limita il bollettino agli ambienti customer-managed e afferma di aver già aggiornato i servizi cloud gestiti direttamente. Citrix conferma inoltre di aver osservato attacchi mirati contro installazioni non mitigate: l’attivazione ripetuta della condizione può mantenere indisponibile il servizio, mentre al momento non è stato identificato un impatto sull’integrità dei dati dei clienti.

Leggi anche: Citrix NetScaler sotto attacco: due zero-day RCE sfruttate globalmente

La patch precedente non basta: gli amministratori devono aggiornare ancora

Il problema arriva immediatamente dopo la gestione delle vulnerabilità CVE-2026-88771 e CVE-2026-88772, entrambe sfruttate in attacchi contro NetScaler e corrette con build rilasciate a fine settembre. Proprio qui emerge l’aspetto operativo più critico: un’installazione portata alla 14.1-73.37 o alla 13.1-64.23 per chiudere le falle precedenti può restare esposta a CVE-2026-88779 se utilizza SAML. Citrix chiarisce quindi che i clienti che soddisfano le nuove precondizioni devono effettuare un ulteriore upgrade. Per le organizzazioni che utilizzano NetScaler come punto di accesso remoto o componente dell’infrastruttura di identità, il rischio non è soltanto legato alla singola vulnerabilità, ma alla velocità con cui il perimetro deve essere rivalutato dopo una patch appena applicata. La recente sequenza di compromissioni e accessi remoti osservata attorno a NetScaler mostra quanto gli appliance di frontiera siano diventati un terreno di caccia privilegiato: quando concentrano autenticazione e accesso remoto, il tempo tra disclosure, aggiornamento e nuova esposizione diventa una variabile di sicurezza a tutti gli effetti.

CISA inserisce la falla nel KEV, ma la possibile RCE resta da provare

L’ingresso di CVE-2026-88779 nel catalogo KEV di CISA certifica l’esistenza di sfruttamento attivo e porta la vulnerabilità fuori dalla categoria delle patch ordinarie. Nell’allerta pubblicata il 4 ottobre da CISA l’agenzia statunitense inserisce la falla tra quelle da prioritizzare in base alle evidenze di exploitation; per le agenzie federali la remediation è fissata al 7 ottobre 2026. Anche per gli operatori privati il segnale è chiaro: gli asset NetScaler esposti a Internet e configurati per SAML devono essere identificati e aggiornati con priorità. Va però mantenuta una distinzione tecnica importante. Citrix attribuisce alla falla un impatto di denial of service e non ha dichiarato capacità di remote code execution. Le segnalazioni emerse durante gli attacchi hanno mostrato richieste di autenticazione contenenti comandi shell e ricercatori stanno verificando se la corruzione di memoria possa produrre effetti più gravi, ma questi elementi non equivalgono a una conferma di RCE. In un incidente già caratterizzato da più zero-day ravvicinate, confondere tentativi osservati, crash correlati e capacità di esecuzione realmente dimostrata produrrebbe una valutazione del rischio tecnicamente scorretta.

Continua con:

Citrix NetScaler sotto attacco: web shell root e patch non bastano più

FortiBleed e CitrixBleed 2 alimentano ransomware INC, Lynx e Anubis

Cosa devono controllare ora le organizzazioni con NetScaler

La priorità è verificare se l’appliance ricade nelle precondizioni SAML indicate da Citrix, controllare la build installata e portarla alle versioni corrette senza considerare sufficiente l’aggiornamento distribuito per le vulnerabilità della settimana precedente. Le organizzazioni che hanno registrato crash di nsaaad, failover o riavvii anomali dovrebbero trattare questi eventi come indicatori da approfondire, senza considerarli automaticamente prova di compromissione. Citrix mette inoltre a disposizione Global Deny Lists per bloccare indirizzi IP malevoli noti, ma la misura non sostituisce l’upgrade. La vicenda mostra un problema più ampio: NetScaler resta un bersaglio ad alto valore perché concentra autenticazione, accesso remoto e traffico di frontiera, e una nuova falla nello stesso ciclo di patch riduce drasticamente il margine per una gestione tradizionale delle finestre di manutenzione. Per chi usa SAML, il controllo non può fermarsi alla domanda “abbiamo patchato?”, ma deve diventare “abbiamo installato la build che corregge questa specifica vulnerabilità e verificato cosa è successo prima dell’aggiornamento?”.