Cloudflare ha pubblicato un rapporto dettagliato sull'incidente che descrive come un bug di gestione della cache nella sua piattaforma AI serverless abbia causato ad almeno 155 utenti di una distribuzione del modello GLM-5.3 la ricezione di risposte contenenti frammenti di prompt e output di altri clienti. Il rapporto, pubblicato il 26 ottobre come divulgazione coordinata insieme al progetto del motore di inferenza open source SGLang, offre un raro sguardo pubblico all'interno dell'impianto idraulico del servizio LLM multi-tenant e un avvertimento sui presupposti di sicurezza della memoria GPU.
Come è stata trovata la perdita Per maggiori informazioni su questa storia, consulta la nostra notizie sull'IA.
Secondo Cloudflare, il ricercatore di sicurezza Gadi Evron di Knostic ha avvisato l'azienda l'8 settembre 2026, attraverso il suo programma bug bounty HackerOne. Evron ha riferito che i prompt molto lunghi inviati al modello GLM-5.3 sulla piattaforma Workers AI di Cloudflare a volte restituivano testo che apparteneva a sessioni di altri utenti. Cloudflare ha riprodotto il problema la mattina seguente e ha disabilitato il modello lo stesso giorno, ripristinandolo il 9 settembre dopo aver implementato le correzioni.
Il modello interessato era @cf/zai-org/glm-5.3, il modello di codifica ad agenti di Z.ai che Cloudflare serve tramite Workers AI, la piattaforma di inferenza serverless dell'azienda. Cloudflare ha confermato che nessun altro modello ospitato sulla piattaforma è stato interessato.
Cosa è realmente successo
L'incidente è riconducibile a due problemi sovrapposti, uno operativo e uno al motore stesso.
Innanzitutto, l'errata configurazione. Cloudflare ha implementato GLM-5.3 con una finestra di contesto di 1.048.576 token, ma il pool di cache del valore-chiave (KV) sulle sue GPU di precompilazione aveva spazio solo per 681.280 token. L'azienda ha riconosciuto di essere a conoscenza di questa discrepanza prima del lancio e si aspettava che il motore di inferenza rifiutasse in modo sicuro le richieste troppo lunghe.
In secondo luogo, il bug del motore. Nella modalità di precompilazione/decodifica disaggregata (l'architettura utilizzata da Workers AI, in cui un pool di GPU elabora il prompt e trasmette la cache KV risultante a un pool separato di GPU che genera la risposta) SGLang ha gestito la richiesta di lunghezza eccessiva in modo errato. Un prompt che non rientrava nel pool veniva contrassegnato internamente come rifiutato e sostituito con un segnaposto a un token. Ma invece di interrompere la richiesta e restituire un errore del client, la fase di precompilazione ha generato la cache KV per il prompt del segnaposto e l'ha trasferita al nodo di decodifica, che ha poi prodotto una risposta che mescolava i dati rimanenti delle richieste precedenti che condividevano le stesse pagine di memoria.
Il risultato: tra il 27 agosto e il 9 settembre, un piccolo numero di clienti che utilizzavano il modello hanno ricevuto risposte contenenti dati di richieste di altri clienti avanzate poco prima della loro. In totale, sono state interessate 155 risposte: tutte, secondo Cloudflare, a richieste più lunghe di 681.280 token.
Nessuna prova di sfruttamento intenzionale
Cloudflare ha affermato che, dopo aver escluso i propri test e le richieste di convalida del ricercatore, le richieste interessate erano coerenti nei tempi e nel volume con l'uso ordinario in contesti lunghi e la società non ha trovato prove che qualcuno abbia deliberatamente sfruttato il bug. Poiché ogni richiesta interessata superava la capacità del pool sottodimensionato, la finestra di esposizione era strettamente delimitata: un aspetto positivo che deriva proprio dall'errata configurazione che ha causato il problema.
La soluzione: pool più grandi e un percorso di fallimento più sicuro
La riparazione ha funzionato su entrambi i livelli del guasto. Cloudflare ha riconfigurato la sua distribuzione GLM-5.3 per corrispondere alla configurazione GLM-5.2, liberando memoria GPU sufficiente affinché il pool KV di precompilazione ora contenga circa 2,04 milioni di token, circa il doppio della lunghezza del contesto di 1.048.576 token del modello. Un prompt che si adatta alla finestra di contesto ora si adatta sempre al pool.
Ma l’azienda ha anche sottolineato che fare affidamento solo sul dimensionamento del pool è fragile: modifiche alla quantizzazione, al parallelismo del tensore, alle dimensioni del grafico CUDA o a una versione futura del modello possono modificare silenziosamente la dimensione del pool. Quindi ha anche corretto il percorso di rifiuto di SGLang, assicurando che una richiesta rifiutata venga interrotta in modo pulito invece di generare e trasferire la cache per un segnaposto. Entrambe le modifiche sono state convalidate rispetto allo script di riproduzione del ricercatore e ai test sui marker canary di Cloudflare prima che il modello fosse ripristinato, e le correzioni sono state fornite a monte ai manutentori di SGLang.
Perché la memoria GPU condivisa è una questione di sicurezza
Il rapporto spiega una pratica che sorprenderà molti sviluppatori di applicazioni: i motori di inferenza generalmente non azzerano le pagine della cache KV tra le richieste, perché la richiesta successiva semplicemente le sovrascrive. Si tratta di un compromesso deliberato in termini di prestazioni, comune a tutti i motori di inferenza, ma come dimostra questo incidente, qualsiasi percorso che consenta di generare una risposta prima che le pagine vengano completamente sovrascritte trasforma un'ottimizzazione delle prestazioni in un vettore di perdita di dati.
La rivelazione è arrivata alla comunità degli sviluppatori: la storia ha raggiunto 123 punti su Hacker News in poche ore, con la discussione incentrata su come la modalità di errore - una richiesta che avrebbe dovuto fallire rumorosamente invece di procedere silenziosamente su uno stato corrotto - rispecchia le classiche lezioni dell'ingegneria dei sistemi distribuiti.
Una lezione più ampia per l'infrastruttura AI
L’incidente ricorda che il perimetro di sicurezza per le applicazioni AI ora si estende in profondità nell’infrastruttura di inferenza. Il modello multi-tenant concentra i dati di molti clienti attraverso acceleratori condivisi, pool di cache condivisi e architetture sempre più esotiche come la precompilazione disaggregata e l'accesso diretto alla memoria remota. Una sottile discrepanza tra la finestra di contesto pubblicizzata di un modello e la capacità fisica fornita per servirlo è stata sufficiente a violare l'isolamento degli inquilini.
Per le aziende che utilizzano piattaforme AI serverless, il risultato del rapporto di Cloudflare è duplice: i bug di isolamento dei tenant nel servizio LLM sono reali e si sono già verificati in produzione, e il tempo di risposta dei fornitori - meno di 24 ore dalla segnalazione alla disattivazione, un giorno per correggere e ripristinare - è lo standard di diligenza da richiedere a qualsiasi fornitore che gestisce richieste sensibili.
---
Rimani Aggiornato sull'IALe ultime notizie, analisi e scoperte sull'intelligenza artificiale — tutto in un posto.
Leggi altre notizie sull'IA →
