Cloudflare zegt dat een bug in GLM-5.3 155 antwoorden uit sessies van verschillende tenants heeft gelekt

Cloudflare publiceerde op 26 oktober 2026 een incidentrapport waarin het een blootstelling van de KV-cache tussen verzoeken door bekendmaakte in het model GLM-5.3 op zijn Workers AI-platform. Daarbij bevatten 155 antwoorden op zeer lange prompts gegevens uit sessies van andere klanten.

Beveiligingsonderzoeker Gadi Evron van Knostic meldde het probleem met de tenantisolatie op 8 september 2026 via het HackerOne-programma van het bedrijf bij Cloudflare. De blootstelling trof het model dat werd aangeboden als @cf/zai-org/glm-5.3, vanaf 27 augustus 2026, de dag waarop GLM 5.3 op Workers AI werd gelanceerd. Cloudflare verholp het probleem en stelde het model op 9 september 2026 weer beschikbaar. Het bedrijf zei te hebben bevestigd dat geen enkel ander model op Workers AI was getroffen.

Alle 155 getroffen antwoorden waren afkomstig van prompts van meer dan 681.280 tokens. Cloudflare zei dat de verzoeken die het had vastgesteld, na uitsluiting van de eigen tests en de verzoeken van de onderzoeker, qua timing en volume overeenkwamen met normaal gebruik van lange contexten en niet met herhaalde uitbuiting van de bug. Het bedrijf zei geen bewijs van opzettelijke uitbuiting te hebben gevonden.

De twee problemen die tot de blootstelling leidden

GLM is een tekstgeneratiemodel van Z.ai, ontwikkeld voor agentgestuurde programmeerworkflows en een van de vele modellen die via Workers AI beschikbaar zijn. Cloudflare draait GLM 5.3 met SGLang, een opensource-inferentie-engine, in een gedisaggregeerde configuratie: prefill-GPU’s verwerken de prompt en maken de KV-cache aan, waarna ze die cache via remote direct memory access (RDMA) en Mooncake overdragen aan decode-GPU’s, die het antwoord genereren. De KV-cache is een gedeelde pool van pagina’s met een vaste grootte. Omdat pagina’s tussen verzoeken niet op nul worden gezet, moet de engine bijhouden wie eigenaar is van elke pagina.

Volgens het rapport waren er twee problemen die tot de blootstelling leidden. Het eerste was een verkeerde configuratie: Cloudflare implementeerde GLM 5.3 met een contextvenster van 1.048.576 tokens, maar de KV-cachepool op de prefill-GPU’s had slechts ruimte voor 681.280 tokens. Cloudflare zei vóór de lancering op de discrepantie te hebben gewezen, maar verwachtte dat de engine een foutmelding zou geven bij prompts die hij niet kon verwerken. Omdat de tests met lange contexten succesvolle antwoorden opleverden, dacht het bedrijf niet dat de discrepantie een probleem vormde. Cloudflare zei dat de tests wel de HTTP-responscodes en de prestaties van de engine bij lange contexten controleerden, maar niet de uitvoer en samenhang van het model. Voortaan controleert het bedrijf vóór elke implementatiewijziging in de gedisaggregeerde configuratie rechtstreeks of de grootte van de KV-pool overeenkomt met de contextlengte.

Het tweede probleem was een bug in SGLang bij de verwerking van verzoeken die te lang waren voor de pool, in de gedisaggregeerde prefill- en decodeermodus. Een prompt die niet in de pool paste, werd intern als afgewezen gemarkeerd en vervangen door een tijdelijke aanduiding van één token. Toch genereerde prefill nog steeds een KV-cache voor die tijdelijke aanduiding en gaf het systeem aan dat de overdracht was voltooid. Vervolgens genereerde het decodeerknooppunt een antwoord terwijl het verouderde cachepagina’s gebruikte die nog gegevens van eerdere verzoeken bevatten. De client ontving daardoor een HTTP 200-reactie in plaats van HTTP 400.

Het SGLang-team stelt in zijn eigen gecoördineerde bericht dat het afwijzingspad voor één node in plaats daarvan een foutmelding teruggaf, waardoor het probleem zich alleen voordeed bij gedisaggregeerde verwerking. Een andere gebruiker had de bug op 6 juli 2026 bij SGLang gemeld als issue #30233; Cloudflare zei dat het die melding tijdens het onderzoek had opgemerkt.

Incidentrespons en herstel

Cloudflare begon het rapport op 9 september 2026 om 08:00 UTC te verifiëren en riep om 13:22 een beveiligingsincident uit, nadat het Product Security-team het lek binnen 25 minuten met twee onafhankelijke accounts had gereproduceerd. Het zette GLM 5.3 om 14:00 op privé, stelde om 14:35 de hoofdoorzaak vast, had uiterlijk om 14:52 alle prefill-nodes overgezet naar de gecorrigeerde configuratie, had om 19:04 de volledige implementatie opnieuw opgebouwd met een door Cloudflare geschreven enginepatch en stelde het model om 19:40 weer openbaar beschikbaar. Op de statuspagina van Cloudflare stond dat het incident met Workers AI op 9 september 2026 om 10:25 uur EDT begon, om 11:02 uur EDT werd vastgesteld en om 16:09 uur EDT was opgelost.

Dankzij de configuratiecorrectie, die overeenkwam met de configuratie van GLM 5.2, kwam voldoende GPU-geheugen vrij om de prefill-KV-pool te vergroten tot ongeveer 2,04 miljoen tokens, ongeveer twee keer de contextlengte van 1.048.576 tokens. Daardoor past elke prompt die binnen het contextvenster valt ook altijd in de pool. De patch voor de engine beëindigt verzoeken met een nog openstaande afwijzing in de toelatingswachtrij voor de gedisaggregeerde verwerking, met behoud van de oorspronkelijke foutmelding, voordat er enige initialisatie, toewijzing of KV-overdracht plaatsvindt. Cloudflare testte beide wijzigingen met het reproductiescript van de onderzoeker en met eigen tests met canary-markeringen voordat het model weer beschikbaar werd gesteld.

Oplossingen in SGLang en vervolgwerk

Cloudflare diende zijn oplossing upstream in als SGLang-pullverzoek #38704. De beheerders voegden vervolgens #38935 samen, dat de getroffen verzoeken bij toelating afwijst volgens de aanpak van Cloudflare. Een verwante oplossing, #36988, was op 6 september 2026 samengevoegd voor een verwant foutscenario. De patch verscheen in SGLang v0.5.20, gevolgd door updates in v0.5.21, uitgebracht op 2 oktober 2026, en v0.5.22, uitgebracht op 19 oktober 2026. Cloudflare raadt alle beheerders van SGLang aan bij te werken naar v0.5.22 of hoger. Het SGLang-team zegt dat v0.5.21 implementaties van Mooncake en NIXL standaard beschermt tegen elk type fout, dat voor MORI-implementaties een build in v0.5.22 nodig is en dat deze reeks oplossingen niet is teruggeporteerd naar eerdere releasebranches.

Het SGLang-team meldde dat de verschillen in doorvoer tijdens 21 runs op twee H100-GPU’s met de beschermingsmaatregelen binnen ±2% bleven, waarbij elk 95%-betrouwbaarheidsinterval nul omvatte. In een afzonderlijke reeks van 16 runs op twee H200-GPU’s werd de kostenpost van het standaard inschakelen van uitgestelde KV-vrijgave gemeten op −0,38%, met een betrouwbaarheidsinterval van −2,12% tot +1,36%, wat volgens het team niet significant was. Cloudflare ontmoette de beheerders van SGLang op 10 september 2026 bij RadixArk, voerde tussen 11 en 19 september 2026 aanvullende beveiligingsmaatregelen door voor al zijn SGLang-productie-implementaties en upstream-samenvoegingen met betrekking tot de toelatingscontrole, controlesommen per overdracht, het behoud van afbreekbevestigingen en het standaard inschakelen van uitgestelde KV-vrijgave vonden plaats tussen 16 september en 12 oktober 2026.

Voor andere beheerders die SGLang in gedisaggregeerde modus gebruiken, beveelt het rapport van Cloudflare aan om na elke wijziging van de gewichten, kwantisering, parallellisatie of geheugenfractie de KV-pool af te zetten tegen de contextlengte op elk prefill- en decoderingknooppunt; te upgraden naar een build met beide oplossingen voor de toelatingscontrole; uitgestelde KV-vrijgave voor beide rollen in te schakelen; corruptiedetectie in te schakelen wanneer het model dit ondersteunt; en loadbalancers zo in te stellen dat het verbreken van de verbinding door een client een verzoek niet midden in een overdracht afbreekt.

Cloudflare zei eerder een prototype te hebben ontwikkeld dat elke fysieke KV-pagina labelt en de koppeling controleert voordat de decoder de cache uitleest. Tests lieten zien dat dit minder dan 1% kostte aan doorvoer en staartlatentie. Cloudflare testte het prototype medio augustus 2026 met GLM 5.2, maar schakelde het kort daarna uit vanwege betrouwbaarheidsproblemen. Cloudflare werkt met het SGLang-team aan een productieversie die in de engine is ingebouwd. De controlesom per overdracht in pull request #39500 is een eerste stap. Het bedrijf zei bovendien zijn ervaring met formele methoden in te zetten voor het modelleren en bewijzen van de veiligheid van een op RDMA gebaseerd protocol voor KV-cacheoverdracht, waarbij Mooncake wordt gebruikt in de SGLang-productie-implementatie.

In het bericht van het SGLang-team worden Cloudflare-ingenieurs Kevin Flansburg en Kastan Day bedankt voor hun werk aan de oplossingen. Ook wordt de gecoördineerde bekendmaking door SGLang en Cloudflare op 26 oktober 2026 vermeld als laatste onderdeel van de tijdlijn voor de bekendmaking. Het eigen rapport van de onderzoeker, waarin de ontdekking en externe validatie worden beschreven, moet nog verschijnen.