Un defect de izolare între clienți a atins modelul GLM-5.3 găzduit pe Workers AI: un KV cache subdimensionat față de fereastra de context, combinat cu un bug în motorul SGLang, a făcut ca 155 de răspunsuri să conțină date din sesiunile altor utilizatori. Cloudflare a scos modelul din producție, a corectat configurația și a patch-uit motorul, apoi a restaurat serviciul în aceeași zi.

Ce s-a întâmplat, exact, fără ambalaj

Pe 8 septembrie 2026, cercetătorul de securitate Gadi Evron (Knostic) a raportat prin HackerOne că prompturile foarte lungi trimise către modelul @cf/zai-org/glm-5.3 returneau uneori text aparținând altor sesiuni. Cloudflare a reprodus problema a doua zi dimineață, a declarat incident, a scos modelul din acces public în 40 de minute și l-a repus online în aceeași zi, după ce a aplicat o configurație corectată și un patch pe motorul de inferență. Raportul complet a fost publicat pe 26 octombrie 2026, coordonat cu SGLang și cu cercetătorul (Cloudflare Blog).

Expunerea a existat din ziua lansării, 27 august 2026, până pe 9 septembrie. În total, 155 de răspunsuri au fost afectate, toate pentru prompturi de peste 681.280 de tokeni. Cloudflare spune că, după ce a eliminat testele proprii și pe cele ale cercetătorului, volumul și ritmul cererilor identificate sunt consistente cu utilizare normală de context lung, nu cu exploatare repetată. Nu există dovezi de exploatare deliberată.

Două probleme s-au suprapus. Prima: fereastra de context anunțată era de 1.048.576 de tokeni, dar pool-ul de KV cache de pe GPU-urile de prefill avea loc doar pentru 681.280. Diferența era cunoscută înainte de lansare, dar echipa se aștepta ca motorul să returneze o eroare pentru prompturile care nu încap, iar testele de context lung au returnat răspunsuri de succes. A doua: în modul disaggregated prefill/decode, SGLang marca cererea supradimensionată ca respinsă, o înlocuia cu un placeholder de un token, dar trimitea totuși KV cache-ul către nodul de decode. Nodul de decode primea mesajul de transfer complet și genera răspuns uitându-se la pagini de cache care încă țineau date din cererile anterioare ale altor utilizatori.

Rezultatul practic: clientul primea HTTP 200 în loc de HTTP 400, răspunsul era coerent, prompt_tokens corespundea promptului lung, dar conținutul amesteca date din alte sesiuni. Orice cerere peste prag se comporta la fel. Nu era o cursă de timing, ci o cale deterministă care se declanșa de fiecare dată.

De ce nu e o știre despre „Cloudflare a greșit”

E ușor să citești incidentul ca pe o greșeală de configurare. E mai util să-l citești ca pe o lecție despre ce înseamnă verificare la scară. Cloudflare a validat coduri HTTP și performanță la context lung, dar nu a validat coerența și proprietatea output-ului. Adică a măsurat că răspunsul vine, nu și ce conține. Exact genul de orbire care apare când testele sunt construite de oameni care se uită la latență și la throughput, nu la cine deține fiecare pagină de memorie.

Al doilea lucru de reținut: dimensiunea pool-ului de KV cache nu e un parametru de configurare pe care îl setezi explicit. SGLang o calculează la pornire din memoria GPU rămasă după încărcarea greutăților modelului. Lungimea de context anunțată e o valoare separată. Nimic nu le obligă să fie de acord. E responsabilitatea operatorului să le compare. Orice schimbare de cuantizare, de tensor parallelism, de dimensiuni pentru CUDA graph sau o versiune nouă de model poate muta pool-ul într-un mod greu de observat dacă nu îl verifici direct din motorul care rulează.

Al treilea: corectura nu a fost doar de configurație. Cloudflare a mărit pool-ul la aproximativ 2,04 milioane de tokeni, cam dublu față de fereastra de context, astfel încât o cerere validă să încapă mereu. Dar au patch-uit și calea de respingere, pentru că bazarea doar pe dimensiunea pool-ului e fragilă. Acum o cerere cu respingere pendinte e retrasă în coada de admisie de dinainte de orice bootstrap, alocare sau transfer KV, cu eroarea originală. Propunerea a fost trimisă upstream, iar nodul de decode verifică acum că numărul de tokeni transferați corespunde cu cel rezervat.

SGLang a livrat patch-ul în v0.5.20, cu urmări în v0.5.21 și v0.5.22. Cloudflare recomandă explicit tuturor operatorilor să actualizeze dependențele SGLang la v0.5.22 sau mai sus. Bug-ul fusese raportat de alt utilizator pe 6 iulie 2026, ca issue #30233, iar Cloudflare l-a observat abia în timpul investigației.

Ce face un operator bun imediat după o astfel de știre

Recomandările de mai jos sunt ale mele, nu ale sursei. Sunt pași de verificare, nu verdicte.

Primul pas: verifică dacă rulezi SGLang cu un pool de KV cache mai mic decât fereastra de context. Nu te baza pe răspunsuri de succes. Compară direct, din metricile motorului care rulează, cele două valori. Dacă nu ai un loc în care această comparație apare ca verificare blocantă înainte de un deploy, ai o problemă de proces, nu doar de configurare.

Al doilea: dacă faci servire disaggregated prefill/decode, testează ce se întâmplă cu o cerere peste limita pool-ului. Nu doar codul HTTP. Verifică dacă răspunsul are sens, dacă tokenii raportați se leagă de prompt, dacă nu apar fragmente care nu au ce căuta acolo. Un canary cu markeri proprii, cum au făcut cei de la Cloudflare, e cel mai ieftin mod să prinzi regresii de genul ăsta.

Al treilea: actualizează dependențele. Dacă ai fork-uri proprii pe calea de respingere, de admisie sau pe transferul RDMA, verifică-le una câte una. Nu presupune că un fix upstream ajunge automat la tine dacă ai modificat codul din jur.

Al patrulea: documentează ce înseamnă „izolare între clienți” în arhitectura ta. Paginile de KV cache nu sunt zeroate între cereri, și asta e normal pentru performanță. Asta înseamnă că motorul e singurul responsabil de urmărirea proprietății paginilor, inclusiv în scenarii de abandon, eroare, offload și transfer remote. Toate căile astea trebuie să fie în teste, nu doar happy path-ul.

Ce înseamnă pentru tine, antreprenor sau marketer în România

Dacă folosești unelte AI în marketing, fie că e vorba de generare de conținut, de asistenți pentru customer support sau de automatizări peste datele clienților, întrebarea nu e dacă providerul tău are incidente. Întrebarea e ce pui în prompt.

Prompturile lungi, cu context mare, care conțin date sensibile ale clienților, sunt exact zona în care astfel de defecte pot ieși la suprafață. Nu pentru că cineva vrea să îți fure datele, ci pentru că un lanț de erori de configurare și de motor poate produce amestecuri care nu se văd în codul HTTP. Un răspuns care arată perfect și conține o bucată din conversația altcuiva e mai periculos decât unul care crapă.

Concret, ce faci: nu bagi în același prompt lucruri care nu trebuie să se întâlnească niciodată. Datele unui client, într-o sesiune separată de datele altuia, cu izolare logică în aplicația ta, nu doar în model. Nu trimiți liste de clienți, istorice de comenzi sau date personale doar pentru că „merge modelul”. Ține contextul scurt acolo unde nu ai nevoie de context lung. Și cere furnizorului tău de AI detalii despre cum tratează izolarea între cereri, nu doar despre uptime.

Asta se leagă direct de discuția despre unde pui contextul în agenți AI stateful vs stateless, care rămâne utilă tocmai pentru că separă clar ce ține de model și ce ține de aplicația ta. Iar dacă folosești biblioteci care vorbesc cu modele AI, merită să citești și despre ce înseamnă un pachet PyPI compromis, pentru că lanțul de încredere nu se oprește la providerul mare de cloud.

Întrebări frecvente

A fost un atac asupra GLM-5.3? Nu există dovezi de exploatare deliberată. Cloudflare a raportat 155 de răspunsuri afectate, cu volum și ritm consistente cu utilizare normală de prompturi foarte lungi, peste 681.280 de tokeni.

Care modele au fost afectate? Doar GLM-5.3 pe Workers AI. Cloudflare a confirmat că celelalte modele găzduite nu au fost afectate, iar celelalte implementări disaggregated au pool-uri mai mari decât lungimea de context.

Trebuie să mă tem dacă folosesc un alt provider care rulează SGLang? Trebuie să întrebi, nu să presupui. Dacă providerul rulează SGLang sub v0.5.22 sau are un pool de KV cache mai mic decât fereastra de context, cere-i să confirme că a aplicat fix-ul. O verificare incompletă nu dovedește absența problemei.

AI-ul ajută, dar decizia rămâne la om

Un model AI poate să îți pună în ordine un plan de verificare, să îți transforme logurile în întrebări utile, să îți scrie un script care compară pool-ul cu fereastra de context. Ce nu poate face modelul e să își asume decizia: dacă trimiți sau nu datele clienților într-un prompt lung, dacă accepți sau nu un răspuns care arată bine, dacă lași sau nu un deploy să plece fără canary. Acolo e media buyer-ul, omul care se uită la ce contează și răspunde de rezultat.

Pasul concret îl face ALLSoft Agency: punem ordine în structura de date, în contextul pe care îl trimiți către unelte AI, în modul în care măsori și validezi un lanț de automatizare înainte să intre în producție. Fără hype, fără promisiuni de cifre inventate. Cu verificări clare, cu responsabilitate pe execuție și cu decizia finală la om, unde îi este locul.