Il caso mostra che nell’inferenza condivisa l’isolamento tra clienti si verifica sul contenuto delle risposte, perché il codice HTTP 200 può accompagnare anche una fuga di dati.
Il 26 ottobre Cloudflare ha pubblicato la ricostruzione di un incidente sul servizio Workers AI. Tra il 27 agosto e il 9 settembre 2026, alcune risposte del modello GLM-5.3 contenevano dati provenienti dalle richieste di altri clienti. Le risposte coinvolte sono 155 e riguardano tutte prompt superiori a 681.280 token. Secondo Cloudflare la causa è una configurazione incoerente che ha fatto emergere un difetto del motore di inferenza SGLang, e gli altri modelli del servizio sono rimasti fuori dal perimetro dell’incidente.
GLM-5.3 è andato in produzione con una finestra di contesto di 1.048.576 token. Il pool di cache chiave-valore utilizzato nella fase di prefill, quella in cui il modello legge il prompt, ne conteneva 681.280. Cloudflare conosceva la differenza prima del lancio. I test preliminari restituivano codici HTTP di successo e frame d’errore assenti, e il team ne ha concluso che il motore gestisse il caso in modo corretto. Il post riconosce che la validazione copriva i codici di risposta e le prestazioni, e lasciava fuori la coerenza dei testi generati.
La cache chiave-valore conserva le rappresentazioni intermedie del prompt, così il modello evita di ricalcolarle a ogni token. Nella modalità disaggregata, prefill e decode girano su nodi diversi e si passano la cache.
Quando un prompt superava il pool, SGLang segnava la richiesta come rifiutata e la sostituiva con un segnaposto da un token. Le code di ammissione controllavano però se la richiesta fosse terminata e trascuravano lo stato di rifiuto, così la richiesta proseguiva in prefill e nel trasferimento. Il nodo di decode leggeva allora le 8 pagine riservate, ma per quella richiesta era stata scritta soltanto la prima. Le altre pagine contenevano residui di richieste precedenti, di altri clienti. Il cliente riceveva HTTP 200 con una risposta dal testo coerente. Il post cita l’issue SGLang n. 30233, aperta il 6 luglio 2026, come segnalazione a monte.
La segnalazione è arrivata l’8 settembre alle 23:11 UTC tramite HackerOne, dal ricercatore Gadi Evron di Knostic. Il giorno dopo Cloudflare ha dichiarato l’incidente alle 13:22 e ha riprodotto la fuga con due account in 25 minuti. Il modello è passato in modalità privata alle 14:00, con richieste che restituivano HTTP 400. La causa è stata individuata alle 14:35, e alle 14:52 tutti i nodi di prefill giravano con la configurazione corretta. Il modello è tornato pubblico alle 19:40, su un deployment ricostruito con la patch del motore.
Il pool di prefill è ora di circa 2,04 milioni di token, e la patch ritira le richieste rifiutate con il loro errore originale prima di qualunque allocazione o trasferimento. Le correzioni sono entrate in SGLang con le versioni 0.5.21 del 2 ottobre e 0.5.22 del 19 ottobre. La pubblicazione del 26 ottobre è stata coordinata con il ricercatore e con i manutentori di SGLang di RadixArk.
Il post indica un piccolo numero di clienti coinvolti e si ferma lì. Restano aperte tre domande: quanti clienti, quali tipi di dato e se siano stati avvisati uno per uno. Sono le informazioni che un responsabile della protezione dei dati deve avere per valutare un obbligo di notifica.
L’incidente ha una soglia d’ingresso alta: servono prompt superiori a 681.280 token, cioè contesti da centinaia di pagine. Sono i contesti tipici di agenti che caricano documenti interi e lunghe cronologie, dunque proprio i flussi di lavoro che le imprese stanno portando in produzione. L’errore era silenzioso, perché ogni controllo sui codici di risposta risultava verde. Il caso si affianca al deep del 27 ottobre di questa sala stampa sul modello open-weight che tenta un upload verso Pechino: anche lì il controllo efficace stava a valle del ragionamento, dove l’azione esce dal sistema. Per chi acquista inferenza come servizio e per chi la gestisce in casa con motori open source, la verifica sul contenuto diventa una parte del collaudo.
Le indicazioni di Cloudflare valgono per qualsiasi fornitore. La prima è confrontare, su ogni nodo di prefill e di decode, la dimensione del pool di cache con la lunghezza del contesto dopo ogni modifica, e aggiornare SGLang alla versione 0.5.22 o successiva, attivando dove disponibili i checksum sulla cache e i marcatori di controllo. La seconda è aggiungere ai test di rilascio una prova sul contenuto: due account, marcatori riconoscibili nei prompt lunghi, verifica che i marcatori di un account restino assenti dalle risposte dell’altro. La terza è chiedere ai fornitori di inferenza evidenze sull’isolamento della cache tra clienti e sulla procedura di notifica in caso di fuga. Cloudflare lavora intanto su tag di integrità a livello di pagina, con un costo misurato inferiore all’1 % di throughput nei suoi test, e sulla verifica formale del protocollo di trasferimento della cache. La domanda aperta riguarda quanti altri motori di inferenza condividano la stessa debolezza e chi la cercherà.