Cloudflare afferma che un bug di GLM-5.3 ha esposto 155 risposte tra sessioni di tenant

Il 26 ottobre 2026 Cloudflare ha pubblicato un rapporto sull’incidente, rivelando un’esposizione della cache KV tra richieste nel modello GLM-5.3 sulla sua piattaforma Workers AI: 155 risposte a prompt molto lunghi contenevano dati provenienti dalle sessioni di altri clienti.

Il ricercatore di sicurezza Gadi Evron, di Knostic, ha segnalato a Cloudflare il problema di isolamento tra tenant l’8 settembre 2026, tramite il programma HackerOne dell’azienda. L’esposizione ha interessato il modello, distribuito con il nome @cf/zai-org/glm-5.3, a partire dal 27 agosto 2026, giorno del lancio di GLM 5.3 su Workers AI. Cloudflare ha risolto il problema e ripristinato il modello il 9 settembre 2026, affermando di aver verificato che nessun altro modello ospitato su Workers AI fosse stato coinvolto.

Tutte le 155 risposte interessate riguardavano prompt di oltre 681.280 token. Cloudflare ha dichiarato che, escluse le proprie attività di test e le richieste del ricercatore, quelle individuate erano compatibili per tempistiche e volume con un normale utilizzo di contesti lunghi, anziché con ripetuti tentativi di sfruttare il bug, e che non aveva trovato prove di uno sfruttamento intenzionale.

I due problemi all’origine dell’esposizione

GLM è un modello di generazione testuale di Z.ai, progettato per flussi di lavoro di programmazione basati su agenti, ed è uno dei numerosi modelli disponibili tramite Workers AI. Cloudflare esegue GLM 5.3 con SGLang, un motore di inferenza open source, in una configurazione disaggregata: le GPU di prefill elaborano il prompt e generano la relativa cache KV, quindi la trasferiscono tramite accesso diretto remoto alla memoria (RDMA), attraverso Mooncake, alle GPU di decode che generano la risposta. La cache KV è un pool condiviso di pagine di dimensioni fisse; le pagine non vengono azzerate tra una richiesta e l’altra, quindi spetta al motore tenere traccia della titolarità di ciascuna pagina.

Il rapporto riconduce l’esposizione a due problemi. Il primo era un errore di configurazione: Cloudflare aveva distribuito GLM 5.3 con una finestra di contesto di 1.048.576 token, ma il pool della cache KV sulle GPU di prefill conteneva solo 681.280 token. Cloudflare ha affermato di essere a conoscenza della discrepanza prima del lancio, ma di aspettarsi che il motore restituisse un errore per ogni prompt che non fosse in grado di elaborare; inoltre, i test con contesti lunghi avevano restituito risposte valide, perciò non riteneva che la discrepanza fosse un problema. L’azienda ha dichiarato che i test verificavano i codici di risposta HTTP e le prestazioni del motore con contesti lunghi, senza convalidare l’output del modello e la sua coerenza, e che ora verifica direttamente la dimensione del pool KV rispetto alla lunghezza del contesto prima di distribuire qualsiasi modifica alle configurazioni disaggregate.

Il secondo problema era un bug di SGLang nella gestione delle richieste oltre il limite di lunghezza in modalità disaggregata di prefill e decode. Un prompt che non entrava nel pool veniva contrassegnato internamente come rifiutato e sostituito con un segnaposto di un token, ma il prefill continuava a generare la cache KV per il segnaposto e segnalava che il trasferimento era completato. Il nodo di decode generava quindi una risposta utilizzando pagine obsolete della cache, che contenevano ancora dati di richieste precedenti, e il client riceveva una risposta HTTP 200 anziché HTTP 400.

Il team SGLang afferma nel proprio post pubblicato in coordinamento che il percorso di rifiuto su un singolo nodo restituiva invece un errore; il problema si verificava quindi solo nella distribuzione disaggregata. Un altro utente aveva segnalato il bug a SGLang come issue #30233 il 6 luglio 2026; Cloudflare ha dichiarato di averne notato la segnalazione durante le indagini.

Risposta all’incidente e risoluzione

Cloudflare ha iniziato a verificare la segnalazione alle 08:00 UTC del 9 settembre 2026 e alle 13:22 ha dichiarato un incidente di sicurezza, dopo che il team Product Security aveva riprodotto la fuga di dati usando due account indipendenti nell’arco di 25 minuti. Alle 14:00 ha impostato GLM 5.3 come privato, alle 14:35 ha individuato la causa principale, entro le 14:52 ha aggiornato tutti i nodi di prefill con la configurazione corretta, alle 19:04 ha ricostruito l’intera distribuzione con una patch al motore sviluppata da Cloudflare e alle 19:40 ha ripristinato l’accesso pubblico al modello. La pagina di stato di Cloudflare ha registrato l’inizio dell’incidente di Workers AI alle 10:25 EDT del 9 settembre 2026, la sua individuazione alle 11:02 EDT e la risoluzione alle 16:09 EDT.

La correzione della configurazione ha ripristinato quella usata per GLM 5.2, liberando abbastanza memoria GPU da portare il pool KV di prefill a circa 2,04 milioni di token, all’incirca il doppio della lunghezza di contesto di 1.048.576 token; di conseguenza, ogni prompt che rientra nella finestra di contesto rientra sempre anche nel pool. La patch al motore fa sì che una richiesta con un rifiuto in sospeso venga interrotta, con il relativo errore originale, nella coda di ammissione alla disaggregazione, prima che avvengano operazioni di bootstrap, allocazione o trasferimento KV. Prima di ripristinare il modello, Cloudflare ha convalidato entrambe le modifiche con lo script di riproduzione del ricercatore e con i propri test basati su marcatori canary.

Correzioni a monte e attività in corso

Cloudflare ha proposto la propria correzione a monte con la pull request #38704 di SGLang; i manutentori hanno integrato la #38935, che rifiuta le richieste interessate al momento dell’ammissione seguendo l’approccio di Cloudflare. Una correzione correlata, la #36988, era stata integrata il 6 settembre 2026 per un percorso di errore simile. La patch è stata inclusa in SGLang v0.5.20, con ulteriori correzioni nelle versioni v0.5.21, rilasciata il 2 ottobre 2026, e v0.5.22, rilasciata il 19 ottobre 2026; Cloudflare raccomanda a tutti gli operatori di SGLang di aggiornare alla v0.5.22 o a una versione successiva. Il team SGLang afferma che la v0.5.21 protegge per impostazione predefinita le distribuzioni Mooncake e NIXL da ogni tipo di errore, che le distribuzioni MORI richiedono una build della v0.5.22 e che la linea di correzioni non è stata retroportata nei rami delle versioni precedenti.

Il team SGLang ha riferito che, in 21 esecuzioni su due GPU H100, le variazioni del throughput con le protezioni sono rimaste entro ±2%, con tutti gli intervalli di confidenza al 95% comprendenti lo zero. In una prova distinta, condotta su 16 esecuzioni con due GPU H200, il costo dell’attivazione predefinita del rilascio differito delle KV è stato pari a −0,38%, con un intervallo di confidenza compreso tra −2,12% e +1,36%, che il team ha definito non significativo. Cloudflare ha incontrato i manutentori di SGLang presso RadixArk il 10 settembre 2026, ha distribuito ulteriori misure di hardening in tutti i suoi ambienti di produzione SGLang tra l’11 e il 19 settembre 2026 e, dal 16 settembre al 12 ottobre 2026, sono state integrate a monte modifiche relative alla correzione in fase di ammissione, ai checksum per trasferimento, alla conservazione delle conferme di interruzione e all’attivazione predefinita del rilascio differito delle KV.

Per gli altri operatori che eseguono SGLang in modalità disaggregata, il rapporto di Cloudflare raccomanda di misurare il pool KV rispetto alla lunghezza del contesto su ogni nodo di prefill e decode dopo qualsiasi modifica ai pesi, alla quantizzazione, al parallelismo o alla frazione di memoria; di passare a una build che includa entrambe le correzioni in fase di ammissione; di attivare il rilascio differito delle KV su entrambi i ruoli; di abilitare il rilevamento della corruzione laddove il modello lo supporti; e di configurare i bilanciatori del carico in modo che la disconnessione di un client non interrompa una richiesta durante il trasferimento.

Cloudflare ha dichiarato di aver già realizzato un progetto prototipale che contrassegna ogni pagina KV fisica e verifica la mappatura prima che il decode legga la cache, e che nei test ha comportato un costo inferiore all’1% in termini di throughput e latenza di coda. L’azienda ha testato il prototipo con GLM 5.2 a metà agosto 2026, ma lo ha disattivato poco dopo a causa di problemi di affidabilità. Cloudflare sta collaborando con il team SGLang a una versione per la produzione integrata nel motore; il checksum per trasferimento incluso nella pull request #39500 rappresenta un primo passo. Ha inoltre dichiarato di stare applicando la propria esperienza nei metodi formali alla modellazione e alla dimostrazione della sicurezza di un protocollo di trasferimento della cache KV basato su RDMA, che utilizza Mooncake nella sua distribuzione SGLang di produzione.

Nel suo post, il team SGLang ringrazia gli ingegneri di Cloudflare Kevin Flansburg e Kastan Day per il loro lavoro sulle correzioni e indica la divulgazione coordinata da SGLang e Cloudflare del 26 ottobre 2026 come ultima voce della cronologia della divulgazione. Il rapporto del ricercatore, che secondo il team SGLang illustrerà la scoperta e la convalida esterna, deve ancora essere pubblicato.