Cloudflare e la perdita di isolamento nella cache KV: il caso del modello GLM-5.3

Il 26 ottobre 2026, Cloudflare ha reso noti i dettagli di un incidente di sicurezza che, tra il 27 agosto e il 9 settembre 2026, ha portato il modello GLM-5.3 su Workers AI a restituire ad alcuni clienti risposte contenenti dati provenienti dalle richieste di altri utenti. L'evento ha interessato 155 risposte, tutte generate da prompt superiori a 681.280 token. Secondo Cloudflare nessun altro modello di Workers AI è stato colpito. Alla base della fuga di informazioni vi è una doppia causa: una discrepanza di configurazione, che Cloudflare conosceva prima del lancio ma che non si aspettava causasse problemi, tra la dimensione della finestra di contesto del modello (1.048.576 token) e la capienza del pool di cache KV sulle GPU di prefill (681.280 token), unita a un errore nel motore di inferenza open source SGLang.

Come ricostruito dalla società, quando un prompt superava il limite della cache KV, il motore SGLang in modalità disaggregata contrassegnava la richiesta come rifiutata sostituendola con un segnaposto, senza però interrompere il flusso. Le code di ammissione controllavano soltanto il completamento dell'esecuzione e non lo stato di rifiuto, consentendo al nodo di decode di accedere a pagine di memoria che conservavano i dati dei prompt precedenti e di inviare al client un codice HTTP 200 al posto di un errore. Un problema analogo era stato segnalato sul repository del progetto SGLang già il 6 luglio 2026 con la issue #30233. Inoltre, secondo quanto ripreso da Unite.AI sulla base del report ufficiale, le verifiche pre-lancio di Cloudflare controllavano i codici di risposta HTTP e le prestazioni dei contesti lunghi, senza estendersi alla correttezza dell'output finale del modello.

L'incidente è stato segnalato l'8 settembre 2026 dal ricercatore di sicurezza Gadi Evron di Knostic tramite HackerOne. Il 9 settembre (UTC) l'incidente è stato dichiarato alle 13:22 dopo la riproduzione da due account distinti. Il modello è stato reso privato alle 14:00, la causa è stata identificata alle 14:35 e il modello è tornato pubblico alle 19:40, dopo aver portato il pool di cache KV di prefill a circa 2,04 milioni di token, circa il doppio della finestra di contesto, come nella configurazione di GLM 5.2. La correzione di SGLang, che ora scarta le richieste rifiutate con il loro errore originale prima di qualsiasi trasferimento KV, è stata proposta upstream (#38704) ed è presente da SGLang v0.5.20. La pubblicazione del rapporto è stata coordinata con i manutentori di SGLang (RadixArk). Cloudflare raccomanda a chi usa SGLang di passare alla v0.5.22 o successiva e di confrontare la dimensione del pool KV con la lunghezza di contesto su ogni nodo. Il quadro fornito lascia tuttavia aperte diverse incertezze: Cloudflare afferma nel rapporto di non aver trovato prove di uno sfruttamento intenzionale ("We found no evidence of deliberate exploitation"), ma si tratta di una valutazione interna non verificata da soggetti terzi. Cloudflare non indica quanti clienti siano stati coinvolti, limitandosi a parlare di un piccolo numero, né precisa l'esatta natura dei dati esposti nelle 155 risposte, né chiarisce se e come i clienti coinvolti siano stati informati, mentre il report di ricerca di Evron non è stato ancora pubblicato.

L'infrastruttura disaggregata tra prefill e decode permette di sostenere i costi dei contesti estesi, ma sposta il confine di sicurezza sull'integrità della memoria GPU condivisa. Quando l'ottimizzazione delle risorse e i test di prestazione precedono i controlli sulla correttezza dell'output, basta uno stato di errore non intercettato per trasformare l'efficienza in una perdita accidentale di isolamento. — Olya