Cloudflare afirmă că o eroare din GLM-5.3 a expus 155 de răspunsuri între sesiunile clienților

Pe 26 octombrie 2026, Cloudflare a publicat un raport privind incidentul, dezvăluind o expunere a memoriei cache KV între solicitări în modelul GLM-5.3 de pe platforma sa Workers AI. În urma acesteia, 155 de răspunsuri la solicitări foarte lungi au inclus date din sesiunile altor clienți.

Cercetătorul în domeniul securității Gadi Evron, de la Knostic, a raportat problema izolării între clienți către Cloudflare pe 8 septembrie 2026, prin programul HackerOne al companiei. Expunerea a afectat modelul furnizat sub numele @cf/zai-org/glm-5.3 începând din 27 august 2026, ziua în care GLM 5.3 a fost lansat pe Workers AI. Cloudflare a remediat problema și a repus modelul în funcțiune pe 9 septembrie 2026 și a declarat că a confirmat că niciun alt model găzduit pe Workers AI nu a fost afectat.

Toate cele 155 de răspunsuri afectate au fost generate pentru solicitări mai lungi de 681,280 de tokeni. Cloudflare a declarat că, după excluderea propriilor teste și a solicitărilor cercetătorului, solicitările identificate de companie corespundeau, ca moment și volum, utilizării obișnuite a contextelor lungi, nu unor exploatări repetate ale erorii, și că nu a găsit dovezi ale unei exploatări deliberate.

Cele două probleme care au dus la expunere

GLM este un model de generare de text de la Z.ai, conceput pentru fluxuri de lucru de programare agentică, și unul dintre numeroasele modele disponibile prin Workers AI. Cloudflare rulează GLM 5.3 cu SGLang, un motor de inferență cu sursă deschisă, într-o configurație dezagregată: GPU-urile de preumplere procesează solicitarea și generează memoria cache KV, apoi o transferă prin acces direct la memorie la distanță (RDMA), folosind Mooncake, către GPU-urile de decodare, care generează răspunsul. Memoria cache KV este un rezervor partajat de pagini cu dimensiune fixă; paginile nu sunt resetate la zero între solicitări, astfel că motorul trebuie să țină evidența proprietarului fiecărei pagini.

Raportul atribuie expunerea a două probleme. Prima a fost o configurare greșită: Cloudflare a implementat GLM 5.3 cu o fereastră de context de 1,048,576 de tokeni, însă rezervorul de memorie cache KV de pe GPU-urile de preumplere avea o capacitate de numai 681,280 de tokeni. Cloudflare a declarat că știa de neconcordanță înainte de lansare, dar se aștepta ca motorul să returneze o eroare pentru orice solicitare pe care nu o putea procesa. În plus, testele cu contexte lungi au returnat răspunsuri reușite, așa că nu a considerat că neconcordanța reprezenta o problemă. Compania a declarat că testele sale au verificat codurile de răspuns HTTP și performanța motorului la contexte lungi, fără să verifice rezultatul și coerența modelului, iar acum compară direct dimensiunea rezervorului KV cu lungimea contextului înainte de lansarea oricărei modificări a implementării dezagregate.

A doua problemă a fost o eroare în SGLang, legată de gestionarea solicitărilor care depășeau limita în modul dezagregat de preumplere și decodare. O solicitare care nu încăpea în rezervor era marcată intern ca respinsă și înlocuită cu un substituent de un token, însă procesul de preumplere genera în continuare memoria cache KV pentru substituent și semnala că transferul se încheiase. Nodul de decodare genera apoi un răspuns folosind pagini cache vechi, care păstrau încă date din solicitări anterioare, iar clientul primea un răspuns HTTP 200 în loc de HTTP 400.

Echipa SGLang afirmă în propria sa postare coordonată că, pe un singur nod, calea de respingere returna o eroare; prin urmare, problema apărea numai în servirea dezagregată. Un alt utilizator raportase eroarea către SGLang la 6 iulie 2026, în problema #30233, despre care Cloudflare a declarat că a aflat în cursul investigației.

Răspunsul la incident și remedierea

Cloudflare a început verificarea raportului la 08:00 UTC, pe 9 septembrie 2026, și a declarat un incident de securitate la 13:22, după ce echipa sa de securitate a produselor a reprodus scurgerea folosind două conturi independente în decurs de 25 de minute. La 14:00, a setat GLM 5.3 ca privat; la 14:35, a identificat cauza principală; până la 14:52, a actualizat toate nodurile de preumplere la configurația corectată; până la 19:04, a reconstruit întreaga implementare cu un patch pentru motor creat de Cloudflare; iar la 19:40, a restabilit accesul public la model. Pagina de stare Cloudflare a consemnat că incidentul Workers AI a început la 10:25 AM EDT, pe 9 septembrie 2026, a fost identificat la 11:02 AM EDT și rezolvat la 4:09 PM EDT.

Corectarea configurației a aliniat-o la cea folosită pentru GLM 5.2, eliberând suficientă memorie GPU pentru ca rezervorul KV de preumplere să poată stoca acum aproximativ 2,04 milioane de tokeni, adică de circa două ori mai mult decât lungimea ferestrei de context de 1,048,576 de tokeni. Astfel, orice solicitare care încape în fereastra de context încape întotdeauna și în rezervor. Patch-ul pentru motor încheie, la coada de admitere pentru dezagregare, procesarea oricărei solicitări care are o respingere în așteptare, păstrând eroarea inițială, înainte de orice inițializare, alocare sau transfer KV. Cloudflare a validat ambele modificări folosind scriptul de reproducere al cercetătorului și propriile teste cu marcatori canary înainte de a repune modelul în funcțiune.

Remedieri în amonte și activități în curs

Cloudflare a propus remedierea în amonte, sub forma cererii de integrare SGLang #38704, iar responsabilii proiectului au integrat #38935, care respinge solicitările afectate în etapa de admitere, urmând abordarea Cloudflare. O remediere conexă, #36988, fusese integrată pe 6 septembrie 2026 pentru o cale de eșec înrudită. Patch-ul a fost inclus în SGLang v0.5.20, urmat de actualizările v0.5.21, lansată pe 2 octombrie 2026, și v0.5.22, lansată pe 19 octombrie 2026; Cloudflare recomandă tuturor operatorilor SGLang să actualizeze la v0.5.22 sau la o versiune ulterioară. Echipa SGLang afirmă că v0.5.21 protejează în mod implicit implementările Mooncake și NIXL împotriva tuturor tipurilor de eșec, că implementările MORI necesită o compilare din v0.5.22 și că linia de remedieri nu a fost transferată în ramurile versiunilor anterioare.

Echipa SGLang a raportat că, în 21 de rulări pe două GPU-uri H100, variațiile debitului cu măsurile de protecție au fost de cel mult ±2%, iar fiecare interval de încredere de 95% a inclus zero. Într-o serie separată de 16 rulări pe două GPU-uri H200, costul activării implicite a eliberării amânate a KV a fost de −0,38%, cu un interval de încredere cuprins între −2,12% și +1,36%, rezultat pe care echipa l-a descris ca nesemnificativ. Cloudflare s-a întâlnit cu responsabilii proiectului SGLang la RadixArk pe 10 septembrie 2026, a implementat măsuri suplimentare de consolidare în toate implementările SGLang de producție între 11 și 19 septembrie 2026, iar fuziunile în proiectul din amonte care au inclus remedierea admiterii, sumele de control pentru fiecare transfer, păstrarea confirmării de anulare și activarea implicită a eliberării amânate a KV au avut loc între 16 septembrie și 12 octombrie 2026.

Pentru alți operatori care rulează SGLang în modul dezagregat, raportul Cloudflare recomandă să măsoare capacitatea pool-ului KV în raport cu lungimea contextului pe fiecare nod de preumplere și de decodare după orice modificare a ponderilor, cuantizării, paralelismului sau fracției de memorie; să treacă la o versiune care include ambele remedieri privind admiterea; să activeze eliberarea amânată a KV pentru ambele roluri; să activeze detectarea coruperii acolo unde modelul permite acest lucru; și să configureze echilibratoarele de sarcină astfel încât deconectarea clientului să nu întrerupă o cerere în mijlocul transferului.

Cloudflare a declarat că proiectase anterior un prototip care eticheta fiecare pagină fizică KV și verifica maparea înainte ca decodarea să citească memoria cache și că, în teste, acesta a avut un cost sub 1% în ceea ce privește debitul și latența de coadă. Compania a testat prototipul pe GLM 5.2 la mijlocul lunii august 2026, dar l-a dezactivat la scurt timp după aceea din cauza unor probleme de fiabilitate. Cloudflare colaborează cu echipa SGLang la o versiune de producție integrată în motor, suma de control pentru fiecare transfer din cererea de integrare #39500 fiind primul pas. Compania a mai declarat că își pune experiența în metode formale în slujba modelării și demonstrării siguranței unui protocol de transfer al memoriei cache KV bazat pe RDMA, care folosește Mooncake în implementarea sa SGLang de producție.

Postarea echipei SGLang le mulțumește inginerilor Cloudflare Kevin Flansburg și Kastan Day pentru contribuția lor la remedieri și indică dezvăluirea coordonată de SGLang și Cloudflare din 26 octombrie 2026 drept ultima intrare din cronologia dezvăluirii. Raportul cercetătorului însuși, care, potrivit echipei SGLang, va descrie descoperirea și validarea externă, urmează să apară.