Cloudflare a publicat un raport detaliat al incidentului care descrie modul în care o eroare de gestionare a cache-ului în platforma sa AI fără server a determinat ca cel puțin 155 de utilizatori ai implementării unui model GLM-5.3 să primească răspunsuri care conțineau fragmente din solicitările și rezultatele altor clienți. Raportul, publicat pe 26 octombrie ca o dezvăluire coordonată alături de proiectul motorului de inferență open-source SGLang, oferă o privire publică rară asupra instalațiilor de servicii LLM multi-locatari - și un avertisment despre ipotezele de securitate ale memoriei GPU.
Cum a fost găsită scurgerea For more context on this story, see our ongoing AI trends.
Potrivit Cloudflare, cercetătorul de securitate Gadi Evron de la Knostic a alertat compania pe 8 septembrie 2026, prin programul său de recompensă pentru erori HackerOne. Evron a raportat că solicitările foarte lungi trimise modelului GLM-5.3 pe platforma Workers AI a Cloudflare au returnat uneori text care aparținea sesiunilor altor utilizatori. Cloudflare a reprodus problema în dimineața următoare și a dezactivat modelul în aceeași zi, restabilindu-l pe 9 septembrie după implementarea remedierilor.
Modelul afectat a fost @cf/zai-org/glm-5.3 — modelul de codare agentic de la Z.ai pe care Cloudflare îl servește prin Workers AI, platforma de inferență fără server a companiei. Cloudflare a confirmat că niciun alt model găzduit pe platformă nu a fost afectat.
Ce s-a întâmplat de fapt
Incidentul are la bază două probleme care se suprapun, una operațională și una la motorul însuși.
În primul rând, configurația greșită. Cloudflare a implementat GLM-5.3 cu o fereastră de context de 1.048.576 de jetoane, dar pool-ul de cache cheie-valoare (KV) de pe GPU-urile sale de pre-completare avea loc doar pentru 681.280 de jetoane. Compania a recunoscut că era conștientă de această nepotrivire înainte de lansare și se aștepta ca motorul de inferență să respingă în siguranță cererile de supra-lungime.
În al doilea rând, eroarea motorului. În modul dezagregat de precompletare/decodare - arhitectura pe care o folosește Workers AI, în care un grup de GPU-uri procesează promptul și predă memoria cache KV rezultată unui grup separat de GPU-uri care generează răspunsul - SGLang a gestionat incorect cererea de supra-lungime. O solicitare care nu se potrivea cu pool-ul a fost marcată intern ca respinsă și înlocuită cu un substituent cu un singur simbol. Dar, în loc să anuleze cererea și să returneze o eroare client, etapa de precompletare a generat cache KV pentru promptul substituent și l-a transferat în nodul de decodificare, care apoi a produs un răspuns care a amestecat datele rămase de la solicitările anterioare care partajau aceleași pagini de memorie.
Rezultatul: între 27 august și 9 septembrie, un număr mic de clienți care foloseau modelul au primit răspunsuri care conțineau date de la solicitările altor clienți făcute cu puțin timp înaintea lor. În total, 155 de răspunsuri au fost afectate - toate, a constatat Cloudflare, la solicitări mai lungi de 681.280 de jetoane.
Nicio dovadă de exploatare deliberată
Cloudflare a declarat că, după excluderea propriilor teste și a cererilor de validare ale cercetătorului, cererile afectate au fost consecvente ca timp și volum cu utilizarea obișnuită în context lung, iar compania nu a găsit nicio dovadă că cineva a exploatat în mod deliberat bug-ul. Deoarece fiecare solicitare afectată a depășit capacitatea piscinei subdimensionate, fereastra de expunere a fost strâns delimitată - o cătușeală de argint care rezultă din configurația greșită care a cauzat problema.
Remedierea: bazine mai mari și o cale de eșec mai sigură
Remedierea a funcționat pe ambele straturi ale defecțiunii. Cloudflare și-a reconfigurat implementarea GLM-5.3 pentru a se potrivi cu configurația GLM-5.2, eliberând suficientă memorie GPU pentru ca grupul KV de pre-completare să dețină acum aproximativ 2,04 milioane de jetoane - aproximativ dublu față de lungimea contextului de 1.048.576 de jetoane a modelului. O solicitare care se potrivește cu fereastra de context se potrivește acum întotdeauna în pool.
Dar compania a subliniat, de asemenea, că bazarea numai pe dimensionarea piscinei este fragilă: modificările cuantizării, paralelismul tensorului, dimensiunile graficului CUDA sau o versiune viitoare a modelului pot schimba în tăcere dimensiunea piscinei. Așa că a corectat și calea de respingere a SGLang în sine, asigurându-se că o solicitare respinsă se anulează în mod curat în loc să genereze și să transfere memoria cache pentru un substituent. Ambele modificări au fost validate în comparație cu scriptul de reproducere al cercetătorului și cu testele de marcare canary ale Cloudflare înainte ca modelul să fie restaurat, iar remediile au fost aduse în amonte pentru întreținerii SGLang.
De ce memoria GPU partajată este o întrebare de securitate
Raportul explică o practică care va surprinde mulți dezvoltatori de aplicații: motoarele de inferență, în general, nu scot la zero paginile de cache KV între cereri, deoarece următoarea solicitare le suprascrie pur și simplu. Acesta este un compromis deliberat de performanță, comun în toate motoarele de inferență, dar, așa cum arată acest incident, orice cale care permite generarea unui răspuns înainte ca acele pagini să fie complet suprascrise transformă o optimizare a performanței într-un vector de scurgere de date.
Dezvăluirea a ajuns la comunitatea dezvoltatorilor: povestea a atins 123 de puncte pe Hacker News în câteva ore, discuția concentrându-se asupra modului în care modul de eșec – o solicitare care ar fi trebuit să eșueze cu voce tare, în loc să continue în tăcere pe starea coruptă – oglindește lecțiile clasice din ingineria sistemelor distribuite.
O lecție mai largă pentru infrastructura AI
Incidentul este un memento că perimetrul de securitate pentru aplicațiile AI se extinde acum adânc în infrastructura de inferență. Servirea modelelor multi-locatari concentrează datele multor clienți prin acceleratoare partajate, pool-uri de cache partajate și arhitecturi din ce în ce mai exotice, cum ar fi precompletarea dezagregată și accesul direct la memorie de la distanță. O nepotrivire subtilă între fereastra de context anunțată a unui model și capacitatea fizică furnizată pentru a-l servi a fost suficientă pentru a încălca izolarea chiriașilor.
Pentru întreprinderile care se bazează pe platforme AI fără server, concluzia din raportul Cloudflare este dublă: erorile de izolare a chiriașilor în servirea LLM sunt reale și s-au produs deja în producție, iar timpul de răspuns al furnizorilor - mai puțin de 24 de ore de la raportare până la dezactivare, o zi pentru remediere și restaurare - este standardul de diligență la cererea oricărui furnizor care gestionează solicitări sensibile.
---
Stay Ahead of AIGet the latest AI news, analysis, and breakthroughs — all in one place.
Read more AI news →
