Cloudflare afferma che un bug che interessava il suo modello GLM-5.3 su Workers AI ha esposto i dati delle richieste di alcuni clienti ad altri clienti tra il 27 agosto e il 9 settembre 2026. L’azienda ha identificato 155 risposte interessate, tutte generate da prompt lunghi più di 681.280 token, e non ha trovato prove che il problema sia stato sfruttato deliberatamente.
Il problema è venuto alla luce dopo che il ricercatore di sicurezza Gadi Evron, di Knostic, lo ha segnalato tramite il programma HackerOne di Cloudflare l’8 settembre. Cloudflare ha riprodotto il problema la mattina seguente, ha messo il modello offline entro 40 minuti dalla dichiarazione dell’incidente e lo ha ripristinato più tardi quello stesso giorno, dopo aver distribuito correzioni alla configurazione e al motore. L’azienda ha dichiarato che nessun altro modello ospitato su Workers AI è stato interessato.
Cloudflare ha attribuito l’esposizione a due problemi. GLM-5.3 era configurato con una finestra di contesto di 1.048.576 token, ma il pool di cache KV sulle GPU di prefill poteva contenere soltanto 681.280 token. Separatamente, SGLang, il motore di inferenza usato per fornire il modello, gestiva in modo errato le richieste che superavano la capacità del pool nella sua configurazione disaggregata di prefill e decodifica.
Invece di interrompere una richiesta troppo grande e restituire un errore, il percorso SGLang interessato sostituiva il prompt con un segnaposto di un token. La fase di prefill trasferiva quindi i dati della cache per quel segnaposto, mentre la fase di decodifica considerava completato il trasferimento e leggeva l’intero insieme di pagine riservate alla richiesta originale. La maggior parte di queste pagine non era stata sovrascritta e conteneva ancora dati di richieste precedenti, che potevano quindi comparire nella risposta.
Cloudflare ha modificato la configurazione affinché il pool KV di prefill possa contenere circa 2,04 milioni di token, all’incirca il doppio della lunghezza del contesto del modello. Ha inoltre applicato una patch a SGLang per ritirare le richieste rifiutate prima dell’avvio, dell’allocazione della memoria o del trasferimento KV, e ha aggiunto un controllo per verificare che il numero di token trasferiti corrisponda alla quantità riservata dalla fase di decodifica. L’azienda afferma di aver testato le modifiche usando lo script di riproduzione del ricercatore e i propri test con marcatori canary prima di ripristinare il modello.
L’incidente ha inoltre portato all’introduzione di misure di protezione più ampie nelle distribuzioni SGLang di Cloudflare, tra cui controlli che verificano che la capacità del pool superi la lunghezza del contesto e misure per ridurre i rischi legati ai trasferimenti della cache KV e al riutilizzo delle pagine. Cloudflare raccomanda agli operatori che utilizzano SGLang disaggregato di aggiornare alla versione 0.5.22 o successive, oppure di integrare retroattivamente le correzioni pertinenti. L’azienda ha dichiarato che le correzioni relative all’incidente e ai problemi correlati della cache sono state integrate nel repository upstream, e che la maggior parte è inclusa in SGLang 0.5.22.
Fonti: Cloudflare Blog.