Ciberseguretat
Cloudflare: la memòria cau KV va servir dades d'altri en 155 respostes
Cloudflare, empresa nord-americana de xarxa i seguretat web, va publicar el 26 d'octubre de 2026 l'informe d'una fallada del seu servei Workers AI que va estar activa del 27 d'agost al 9 de setembre. Segons l'empresa, el model GLM-5.3 va retornar en 155 respostes fragments de peticions d'altres clients: la seva memòria cau KV reaprofitava memòria i un error del motor SGLang permetia llegir-ne pàgines alienes. La fallada està corregida des del 9 de setembre; les novetats són les causes, els pedaços i la recomanació adreçada a qui fa servir SGLang.
Rep el resum diari d'IA
Cada matí, l'essencial de la intel·ligència artificial al teu correu, sense fum. Al dia amb la IA.
En subscriure-t'hi acceptes rebre el butlletí d'AI Informator. Pots donar-te de baixa quan vulguis.
En resum
- Segons Cloudflare, entre el 27 d'agost i el 9 de setembre de 2026, 155 respostes del model GLM-5.3 a Workers AI van incloure dades d'altres peticions, totes a prompts de més de 681.280 tokens.
- Cloudflare afirma que no va trobar indicis d'explotació deliberada i que cap altre model de Workers AI no es va veure afectat.
- Segons Cloudflare, l'espai reservat per a la memòria cau KV era més petit que la finestra de context anunciada, i un error de SGLang va convertir aquest desajust en una fuita.
- Cloudflare reconeix que les seves proves prèvies al llançament només comprovaven els codis HTTP i el rendiment, no el text que retornava el model.
- Cloudflare recomana a qui serveixi models amb SGLang que actualitzi a la versió 0.5.22 o posterior.
Un servei d'IA que retornava restes d'altres converses
Workers AI és el servei de Cloudflare per executar models d'IA a la seva pròpia xarxa. Un d'aquests models és GLM-5.3, un model de generació de text de Z.ai que, segons Cloudflare, està pensat per a fluxos de treball de programació amb agents. Cloudflare el va publicar a Workers AI el 27 d'agost de 2026 i, segons el seu informe, l'exposició existia des d'aquell mateix dia.
El 8 de setembre, l'investigador de seguretat Gadi Evron, de l'empresa de seguretat Knostic, va donar l'avís a través del programa de Cloudflare a HackerOne, la plataforma de recompenses per vulnerabilitats. Segons Cloudflare, l'avís deia que els prompts molt llargs enviats a GLM-5.3 de vegades retornaven text de sessions d'altres usuaris.
Segons Cloudflare, el seu equip va reproduir la fallada l'endemà al matí amb dos comptes independents en 25 minuts, va retirar el model en menys de 40 minuts des que va declarar l'incident i el va restablir el 9 de setembre amb una configuració corregida i el motor apedaçat.
El balanç que fa l'empresa és de 155 respostes afectades, totes a prompts de més de 681.280 tokens. Segons Cloudflare, en aquell període un nombre petit de clients va rebre respostes amb dades de peticions al mateix model fetes poc abans. Un cop descomptades les seves pròpies proves i les de l'investigador, Cloudflare sosté que aquelles peticions encaixen en temps i volum amb un ús normal de contextos llargs i que no hi va trobar indicis d'explotació deliberada.
La finestra anunciada no cabia a la memòria reservada
Veure les dades en una taula
| Finestra de context anunciada | Reserva de memòria cau KV en el llançament | Reserva de memòria cau KV després de la correcció | |
|---|---|---|---|
| Tokens | 1.048.576tokens | 681.280tokens | 2.040.000tokens |
La primera causa, segons Cloudflare, va ser de configuració. GLM-5.3 es va anunciar amb una finestra de context d'una mica més d'un milió de tokens, però la reserva de memòria cau KV a les GPU que processen el prompt era força més petita. Qualsevol petició que superés aquesta reserva quedava fora de la memòria disponible encara que respectés la finestra anunciada.
Cloudflare reconeix que coneixia el desajust abans del llançament. Segons el seu informe, esperava que el motor retornés un error davant de qualsevol prompt que no pogués processar, i com que les seves proves de context llarg rebien respostes HTTP correctes, no ho va considerar un problema.
Un error de SGLang va convertir el rebuig en una resposta vàlida
La segona causa, segons Cloudflare, va ser una fallada de SGLang, el motor d'inferència de codi obert que fa servir l'empresa, quan funciona amb prefill i decode separats. El prompt que no hi cabia es marcava com a rebutjat i se substituïa per un marcador d'un sol token. En comptes d'avortar la petició, la màquina de prefill calculava la memòria cau d'aquell token i la lliurava a la de decode.
La màquina de decode es pensava que havia rebut la petició completa i generava la resposta llegint pàgines de memòria antigues, que encara guardaven dades de peticions anteriors d'altres usuaris. Segons Cloudflare, el client rebia un codi HTTP 200, el d'una petició atesa amb èxit, en lloc d'un 400, el que indica una petició errònia, i a més una resposta coherent.
La fallada era possible perquè, segons Cloudflare, les pàgines de la memòria cau KV no es posen a zero entre peticions. L'empresa explica que és una pràctica habitual per qüestions de rendiment i que obliga el motor a saber en tot moment de qui és cada pàgina.
Dues correccions i una prova que no llegia les respostes
Segons Cloudflare, la correcció de configuració va ampliar la reserva de prefill fins a uns 2,04 milions de tokens, aproximadament el doble de la finestra de context. Amb això, un prompt que cap a la finestra sempre cap a la memòria reservada.
La correcció del motor retira les peticions rebutjades abans de reservar memòria o de transferir res entre màquines. Segons Cloudflare, els pedaços són a SGLang des de la versió 0.5.20, i l'empresa demana expressament a qui faci servir aquest motor que actualitzi a la 0.5.22 o posterior.
La fallada no era desconeguda. Segons Cloudflare, un altre usuari l'havia comunicada a SGLang com a incidència #30233 el 6 de juliol de 2026, i l'empresa la va veure durant la seva investigació.
L'autocrítica de Cloudflare apunta a les proves prèvies al llançament: «només vam validar els codis de resposta HTTP i el rendiment del motor amb contextos llargs, sense validar la sortida ni la coherència del model». Segons l'empresa, ara compara la mida de la reserva amb la finestra de context abans de cada desplegament.
La solució de fons: memòria amb propietari
Segons Cloudflare, el 10 de setembre es va reunir amb el director tècnic i amb enginyers de RadixArk, l'empresa que manté SGLang. L'informe del 26 d'octubre es publica de manera coordinada amb l'investigador i amb RadixArk.
La solució de fons que prepara Cloudflare consisteix a etiquetar cada pàgina de la memòria cau KV perquè el motor detecti, en el moment de llegir-la, que una petició farà servir una pàgina que no és seva. Segons l'empresa, el seu prototip va costar menys de l'1 % de rendiment, però el va desactivar per problemes de fiabilitat.
Conclusió
Segons Cloudflare, la fuita de GLM-5.3 a Workers AI va néixer d'un desajust conegut entre la finestra de context i la memòria reservada, i d'un error de SGLang que convertia un rebuig en una resposta amb dades alienes. Està tancada des del 9 de setembre, però l'avís continua vigent per a qualsevol que serveixi models amb SGLang separant prefill i decode: actualitzar a la versió 0.5.22 o posterior i comprovar el text que retorna el model, no només el codi HTTP. La peça que falta és que el motor mateix sàpiga de qui és cada pàgina de memòria abans de llegir-la.
Fonts primàries
Rep el resum diari d'IA
Cada matí, l'essencial de la intel·ligència artificial al teu correu, sense fum. Al dia amb la IA.
En subscriure-t'hi acceptes rebre el butlletí d'AI Informator. Pots donar-te de baixa quan vulguis.
Comentaris