CitrixBleed 3: perché un bug NetScaler di marzo è l'emergenza di giugno

Citrix ha rilasciato la correzione per la CVE-2026-3055 il 23 marzo 2026. Sette giorni dopo CISA l'ha inserita nel catalogo Known Exploited Vulnerabilities. Il 31 marzo è comparso un modulo Metasploit. Secondo ogni metrica che una dashboard di vulnerability management traccia, questo bug si è chiuso nel primo trimestre. Eppure, nei primi giorni di giugno, il team di threat intelligence di Fortinet ha confermato lo sfruttamento su larga scala contro appliance NetScaler esposte su internet e configurate come SAML identity provider. La distanza tra "patch disponibile" e "attacco finito" è ormai larga undici settimane, e resta aperta. Quella distanza è tutta la storia.

La community di sicurezza chiama il bug CitrixBleed 3, e il nome è un avvertimento, non una battuta. Il CitrixBleed originale (CVE-2023-4966) è uno dei bug su appliance perimetrali più gravi del decennio: ha dato agli affiliati di LockBit l'appiglio dietro le intrusioni di Boeing, Comcast e ICBC. CitrixBleed 2 è arrivato nel 2025. La CVE-2026-3055 è la stessa classe di vulnerabilità, sulla stessa macchina, con lo stesso meccanismo di fallimento che ha trasformato il primo in un incidente lungo un anno: una patch che le organizzazioni applicano senza fare l'unica cosa che davvero sfratta l'attaccante.

Cos'è davvero CitrixBleed 3 (CVE-2026-3055)

La CVE-2026-3055 è un out-of-bounds read — il bollettino di Citrix (CTX696300) lo definisce "memory overread" — in NetScaler ADC e NetScaler Gateway. Ha un punteggio CVSS v4 di 9.3 ed è non autenticata. Nessun login, nessun token, nessuna precondizione dal lato dell'attaccante. C'è esattamente una precondizione dal vostro: l'appliance dev'essere configurata come SAML identity provider.

Quella condizione conta più di quanto sembri. SAML IDP non è un'impostazione esotica. È il modo predefinito con cui le aziende collegano NetScaler al single sign-on: l'appliance diventa ciò che emette le asserzioni di identità verso Microsoft 365, Salesforce, ogni SaaS federato in azienda. Molti team l'hanno abilitata durante un rollout SSO mesi dopo aver installato e testato la macchina, e non ci hanno più pensato.

L'exploit è banale nel modo in cui i bug peggiori lo sono sempre. L'attaccante invia una richiesta malformata agli endpoint SAML — /saml/login con il parametro AssertionConsumerServiceURL omesso, oppure /wsfed/passive?wctx con un valore wctx vuoto — e l'appliance risponde con kilobyte di memoria di processo residua, codificata in base64 dentro il cookie di risposta NSC_TASS. L'analisi di watchTowr lo colloca senza ambiguità nella "stessa classe di vulnerabilità di CitrixBleed e CitrixBleed 2". Ripetete la richiesta e ottenete una porzione di memoria diversa ogni volta. Iterate, e ricomponete tutto ciò che l'appliance teneva in memoria di recente: token di sessione, asserzioni SAML valide, credenziali LDAP e Active Directory.

Difensore: "NetScaler l'abbiamo patchato a marzo. Lo scanner è verde." Attaccante: "Ad aprile ho estratto il token di sessione del tuo CFO dalla memoria di processo, prima che patchassi. Lo sto ancora usando. Il tuo scanner non sa che la mia sessione esiste."

Quello scambio non è ipotetico. È il meccanismo esatto che ha reso il primo CitrixBleed una catastrofe, e nulla nella terza variante lo cambia.

Un'appliance patchata può restare spalancata

Ecco il dettaglio che la strumentazione di vulnerability management strutturalmente non può vedere, perché vive del tutto fuori dal modello della patch.

Quando il memory overread fa trapelare un token di sessione, quel token è una credenziale di autenticazione pienamente valida. Non è una password che ruotate forzando un reset; è una sessione viva che l'appliance onorerà finché la sessione stessa non viene terminata. Applicare la patch al firmware ferma i nuovi leak. Non fa nulla ai token già esfiltrati. Come Citrix dovette mettere nero su bianco durante il CitrixBleed originale, alla patch deve seguire un passaggio esplicito: terminare ogni sessione attiva e persistente prima — o subito dopo — l'aggiornamento (la copertura di BankInfoSecurity sull'indicazione "kill sessions" di NetScaler).

Nel 2023 la maggior parte delle organizzazioni non lo fece. Patcharono, videro lo scanner diventare verde e andarono avanti — mentre gli attaccanti riusavano i token rubati per settimane. Non c'è alcun segnale che la memoria muscolare sia cambiata. Un NetScaler patchato ma non ripulito dalle sessioni, a giugno 2026, è esattamente nello stato che ha reso CitrixBleed un incidente lungo un anno: la porta d'ingresso è chiusa a chiave e l'attaccante è già dentro, con in mano una chiave che la serratura accetta ancora.

Ecco perché l'ondata di sfruttamento di giugno è comportamento razionale dell'attaccante, non un paradosso. Undici settimane dopo la patch esistono due popolazioni di appliance vulnerabili:

• Le ancora non patchate. Le appliance perimetrali si aggiornano notoriamente con lentezza perché stanno nel percorso critico dell'accesso remoto e nessuno vuole la finestra di manutenzione. Scansionare internet per gli endpoint SAML costa poco, quindi gli attaccanti aspettano e raccolgono i ritardatari.
• Le patchate ma non ripulite. I token rubati nella finestra di fine marzo, prima della patch, restano validi su ogni macchina in cui le sessioni non sono mai state terminate. Il leak è finito; l'accesso che ha prodotto no.

Il raggio d'impatto del SAML IDP

Il motivo per cui CitrixBleed 3 merita più attenzione di un generico RCE perimetrale è il raggio d'impatto della federazione di identità. Quando la memoria trapelata contiene un'asserzione SAML valida, l'attaccante non è solo dentro il NetScaler. Ha in mano un'affermazione di identità falsa-ma-autentica che ogni service provider a valle si fida per progettazione. Federazione significa che il parco SaaS non ri-verifica l'utente: si fida della parola dell'IDP. Fai sanguinare l'IDP, e puoi impersonare un utente federato su ogni applicazione collegata senza mai toccare l'autenticazione di quelle applicazioni.

Questo trasforma un singolo bug di memoria su un'appliance in una compromissione dell'identità su scala dell'intero tenant. È la differenza tra "un attaccante può leggere un po' di memoria" e "un attaccante può essere il tuo domain admin in Microsoft 365". Le credenziali LDAP e AD trapelate estendono lo stesso raggio dentro la directory on-prem. È la proprietà che rende NetScaler — come ogni appliance di identity edge — un bersaglio sproporzionatamente prezioso: un bug, le chiavi di tutto ciò che si fida di lui.

La cronologia è la lezione

Data	Evento
23 mar 2026	Citrix divulga CVE-2026-3055 e CVE-2026-4368; rilascio patch (CTX696300)
27 mar 2026	CrowdSec osserva le prime tracce di sfruttamento
30 mar 2026	CISA inserisce la CVE-2026-3055 nel catalogo KEV
31 mar 2026	Modulo Metasploit pubblico disponibile
inizio giu 2026	Fortinet conferma lo sfruttamento su larga scala delle appliance SAML IDP

Letta dall'alto al basso, la cronologia mette sotto accusa il modello di sicurezza puntuale. Tutto ciò che un processo trimestrale è progettato per produrre — divulgazione, patch, inserimento in KEV, un avviso da cui agire — era completo entro il 31 marzo. Un'organizzazione che avesse eseguito il proprio pentest esterno programmato a febbraio si sarebbe sentita dire che NetScaler era a posto, perché a febbraio lo era: la CVE non esisteva e, su molte macchine, il ruolo SAML IDP non era ancora stato attivato. L'esposizione è stata creata da un cambio di configurazione e sostenuta da una remediation incompleta, entrambi avvenuti nel lungo silenzio tra una valutazione programmata e l'altra.

Perché il test puntuale non vede CitrixBleed 3

Un pentest è una fotografia. CitrixBleed 3 è un film. L'appliance pulita nella valutazione del primo trimestre ha acquisito un ruolo SAML IDP ad aprile, ha saltato l'aggiornamento firmware in una finestra di manutenzione rinviata, ed è stata patchata a maggio senza terminare le sessioni. Tre cambi di stato indipendenti, nessuno visibile alla valutazione che aveva dato l'ok alla macchina mesi prima. La cadenza annuale o trimestrale non ha un fotogramma per nessuno di essi.

Ciò che davvero intercetta tutto questo è un test che gira come funzione continua dell'ambiente vivo, non del calendario — un test che ri-verifica l'identity edge quando la sua configurazione cambia, che distingue "firmware patchato" da "ancora sfruttabile perché le sessioni non sono mai state invalidate", e che guarda il filo per il pattern di sfruttamento mentre accade invece di ricostruirlo dai log il trimestre dopo.

È qui che Zero Hunt è costruito per la forma esatta di questo problema. Lo swarm di pentest generativo a 10 agenti tratta il perimetro come un bersaglio mobile: le sue campagne change-triggered scattano quando compare un nuovo asset o una nuova configurazione di servizio, così un NetScaler che diventa SAML IDP ad aprile viene ri-testato ad aprile — non alla prossima finestra programmata. Gli agenti Recon ed Exploit generano una catena di exploit fresca per ogni bersaglio contro la configurazione viva, quindi la domanda a cui rispondono non è "questa CVE è patchata in astratto?" ma "questa appliance, in questa config, con queste sessioni, è sfruttabile adesso?" — incluso il caso di session-replay post-patch che un controllo di versione della CVE riporta come chiuso. Ogni finding è backtestato nell'AI Gym prima di girare in produzione e firmato ECDSA in scrittura, così quando l'auditor chiede perché l'identity edge fosse o non fosse esposto in un dato giorno, la risposta è un record verificabile, non un ricordo.

Il lato detection chiude l'altra metà. L'AI Traffic Analysis di Zero Hunt — un modello di deep learning con quattro teste di inferenza che gira sulla GPU dell'appliance a 2.7+ Gbit/s, senza alcuna chiamata verso il cloud — vede la firma di CitrixBleed sul filo mentre accade: le ripetute richieste malformate agli endpoint SAML, le risposte NSC_TASS anomale che trasportano memoria in base64, e il replay di un token di sessione da un ASN da cui l'utente legittimo non ha mai avuto origine. È la finestra di undici settimane che la dashboard non poteva vedere, osservata in tempo reale invece che ricostruita dal digest SIEM del trimestre successivo. Una CVE di marzo diventa un'emergenza di giugno solo quando nessuno guarda nel mezzo. Il punto è guardare.