The Pulse
Cloudflare scopre che 155 risposte di GLM-5.3 hanno esposto dati di altri utenti
Cloudflare afferma che un difetto nel suo servizio GLM-5.3 su Workers AI ha esposto frammenti delle richieste di altri clienti in 155 risposte tra il 27 agosto e il 9 settembre 2026. L’azienda ha ricondotto l’esposizione a un pool della cac
AI.info Team · Scritto con l’IA · verificato ·
Cloudflare afferma che 155 risposte del suo modello GLM-5.3 contenevano dati provenienti dalle richieste di altri clienti, dopo che i prompt avevano superato i 681.280 token. L’esposizione ha interessato il modello su Workers AI tra il 27 agosto e il 9 settembre 2026 ed è derivata da una discrepanza tra la finestra di contesto dichiarata per il modello e la memoria disponibile per elaborarla. Cloudflare ha pubblicato il rapporto sull’incidente il 26 ottobre, affermando di non aver trovato prove di uno sfruttamento intenzionale.
155 risposte hanno superato i confini tra clienti
Il modello interessato, identificato come @cf/zai-org/glm-5.3, operava con una finestra di contesto di 1.048.576 token, ma le GPU dedicate al prefill disponevano di spazio nella cache KV per soli 681.280 token. Ciascuna delle risposte interessate seguiva un prompt più lungo di quanto quel pool potesse contenere. Cloudflare ha descritto come esiguo il numero di clienti coinvolti, senza però comunicarne il totale.
Cloudflare afferma che le richieste individuate, esclusi i propri test e quelli del ricercatore, erano compatibili per tempi e volume con un normale utilizzo di contesti lunghi. «Non abbiamo trovato prove di uno sfruttamento intenzionale», si legge nel rapporto dell’azienda. Questa è la valutazione di Cloudflare sulla propria indagine; il post non specifica quali tipi di dati siano comparsi nelle risposte esposte.
Un prompt rifiutato è comunque arrivato alle GPU di decode
Il malfunzionamento ha coinvolto due aspetti della configurazione del servizio. In primo luogo, un prompt poteva rientrare nella finestra di contesto configurata pur superando la capacità del più piccolo pool della cache KV. Cloudflare afferma di essere stata a conoscenza della discrepanza prima del lancio, ma i suoi test verificavano la riuscita delle risposte HTTP e le prestazioni con contesti lunghi, non la coerenza del testo risultante.
In secondo luogo, SGLang gestiva in modo errato i prompt che superavano la capacità disponibile nel serving disaggregato, in cui un gruppo di GPU elabora il prompt e un altro genera la risposta. Il motore contrassegnava una richiesta troppo lunga come rifiutata e la sostituiva con un segnaposto di un token, ma la richiesta attraversava comunque il passaggio dal prefill al decode. Il decode considerava completo il trasferimento e leggeva pagine della cache che la nuova richiesta non aveva sovrascritto, nelle quali rimanevano dati di richieste precedenti.
Secondo il rapporto di Cloudflare, il client poteva ricevere HTTP 200 anziché un errore, con una risposta apparentemente coerente che includeva contenuti delle sessioni di altri utenti. Il problema riguardava specificamente GLM-5.3 su Workers AI, secondo l’azienda, che afferma che gli altri suoi modelli avevano pool della cache più grandi delle rispettive finestre di contesto configurate e non potevano imboccare questo percorso di rifiuto.
Cloudflare ha corretto la configurazione e il percorso di rifiuto
Dopo aver riprodotto il problema il 9 settembre, Cloudflare ha reso privato GLM-5.3, ne ha corretto la configurazione e ha distribuito una patch per il motore prima di ripristinare il modello quella sera. Il pool di prefill rivisto contiene circa 2,04 milioni di token, all’incirca il doppio della finestra di contesto da 1.048.576 token. La patch rimuove le richieste rifiutate prima che entrino nel passaggio tra le componenti disaggregate, impedendo al decode di considerare completo un prompt il cui trasferimento nella cache è solo parziale.
Cloudflare afferma di aver aggiunto anche controlli della capacità del pool della cache rispetto alla lunghezza del contesto e di aver distribuito ulteriori misure di protezione nei suoi servizi SGLang in produzione. Tra queste figurano il mantenimento delle pagine della cache fino al completamento dei trasferimenti e l’imposizione di limiti ai batch di trasferimento. L’azienda afferma che i suoi controlli si applicano ora a ogni nuova distribuzione disaggregata.
Agli operatori di SGLang viene consigliato un aggiornamento
Le modifiche al motore sono disponibili nel progetto originale. Cloudflare afferma che la patch è stata inclusa in SGLang v0.5.20, con ulteriori correzioni nelle versioni v0.5.21 e v0.5.22, e raccomanda agli operatori di usare la versione v0.5.22 o successiva. La comunicazione coordinata di SGLang descrive separatamente rischi correlati che riguardano pagine della cache rilasciate mentre le scritture remote potrebbero essere ancora in corso.
Per i clienti, il rapporto di Cloudflare stabilisce il periodo dell’esposizione, il modello interessato e la condizione che ha innescato il problema, ma lascia non specificati due dettagli: quanti clienti distinti siano stati coinvolti e quali informazioni siano apparse nelle 155 risposte. L’azienda afferma che il problema è stato risolto il 9 settembre; il conteggio pubblicato resta di 155 risposte interessate.