# KV-cache-lek bij Workers AI: GLM-5.3 toonde data van andere klanten

Door Ivo Donker · 29 oktober 2026 — samengesteld met AI-ondersteuning (DeepSeek V4.1 Flash)

Cloudflare heeft een incidentrapport gepubliceerd over een tenant-isolatieprobleem bij precies één model op Workers AI: `@cf/zai-org/glm-5.3`, oftewel GLM 5.3. Tussen 27 augustus en 9 september 2026 kreeg een klein aantal klanten dat dit model via Workers AI gebruikte, antwoorden die data bevatten uit verzoeken die andere klanten kort daarvoor op hetzelfde model hadden gedaan. In totaal werden 155 responses geraakt, allemaal bij prompts langer dan 681.280 tokens. Volgens Cloudflare is het probleem verholpen en waren andere Workers AI-modellen niet getroffen.

Het rapport staat op Cloudflare's eigen blog, is geschreven door Kevin Flansburg en Michelle Chen en verscheen op 26 oktober 2026 als gecoördineerde openbaarmaking samen met het SGLang-team. De melding kwam op 8 september 2026 binnen via Cloudflare's HackerOne-programma, van securityonderzoeker Gadi Evron van Knostic. Cloudflare zegt geen bewijs te hebben gevonden voor opzettelijke exploitatie. Het technisch leerzaamste deel van het rapport is niet het incident zelf, maar de twee oorzaken erachter: een configuratiemismatch en een bug in gedisaggregeerde prefill/decode. Cloudflare geeft daarom ook advies aan andere operators die SGLang zo draaien. Wat inference in de basis doet, staat uitgelegd in [de uitleg over inference](https://leren.llmnet.nl/inference-uitgelegd), waar je prefill, decode en geheugengebruik in samenhang ziet.

## Wat Cloudflare meldt

De kern van het rapport: klanten van het GLM 5.3-model op Workers AI konden bij zeer lange prompts tekst terugkrijgen die afkomstig was uit eerdere sessies van andere gebruikers. De onderzoeker meldde dat zeer lange prompts soms tekst opleverden die bij sessies van andere gebruikers hoorde. Cloudflare onderzocht dat en kon het reproduceren. Na aftrek van Cloudflare's eigen testverkeer en dat van de onderzoeker, pasten de geïdentificeerde verzoeken qua timing en volume bij gewoon gebruik van lange contexten. Cloudflare vond dan ook geen bewijs van opzettelijke exploitatie.

Cloudflare bevestigt in het rapport dat het om één model ging. Andere modellen op Workers AI waren niet geraakt. Ook noemt Cloudflare geen aantal getroffen klanten; het blijft bij "een klein aantal klanten". Even belangrijk: het lek trad alleen op bij prompts langer dan 681.280 tokens. Dat is een drempel die je met normaal chatgebruik niet snel haalt, maar die binnen agentic coding-workflows — waar GLM-modellen volgens Cloudflare voor bedoeld zijn — wel degelijk voorkomt. Als je wilt volgen hoe Cloudflare Workers zich voor AI-bouwers ontwikkelt, is [het overzicht van Cloudflare Workers-signalen](https://radar.llmnet.nl/cloudflare-workers-signalen-juli-2026) een praktisch startpunt.

## Afbakening: alleen GLM-5.3 op Workers AI

Het is verleidelijk om dit als een breed platformprobleem te lezen, maar dat is het niet. Volgens Cloudflare was GLM 5.3 het enige getroffen model, en elke andere gedisaggregeerde deployment op Workers AI heeft KV-pools die groter zijn dan de contextlengte, op zowel prefill als decode. Anders gezegd: de fout zat in de combinatie van één specifieke configuratie en één specifiek codepad in de engine, niet in de gedeelde infrastructuur als geheel.

Die afbakening is niet alleen een mededeling uit voorzorg. Ze bepaalt ook wat je als gebruiker moet doen. Wie andere modellen op Workers AI gebruikt, hoeft op basis van dit rapport niets te wijzigen. Wie GLM 5.3 gebruikte met extreem lange prompts, doet er wel verstandig aan zijn eigen situatie na te lopen — niet omdat het probleem nog speelt, maar omdat je wilt weten of je zelf in het venster van 27 augustus tot 9 september 2026 zat. Voor meerlaagse toepassingen met meerdere klanten op één infrastructuur is [het bouwen van multi-tenant LLM-applicaties](https://api.llmnet.nl/multi-tenant-llm-apps) de plek waar isolatie- en scheidingsvragen samenkomen.

## Hoe de KV-cache in dit systeem werkt

Om de oorzaak te begrijpen, helpt het om te weten wat een KV-cache is. Een taalmodel verwerkt een prompt in stappen en slaat daarbij per laag sleutel- en waardetensors op: de KV-cache. Bij elk volgend token hoeft het model die tussenresultaten dan niet opnieuw te berekenen. Dat is de reden dat een lang gesprek sneller gaat dan een reeks losse korte prompts. De cache neemt GPU-geheugen in beslag, en hoeveel ruimte er voor die cache overblijft, speelt in dit incident een hoofdrol. Wil je weten hoe je daar in de praktijk mee omgaat, dan is [de gids over KV-cache en kwantisatie in llama.cpp en vLLM](https://gids.llmnet.nl/kv-cache-kwantisatie-instellen-in-llama-cpp-en-vllm) een goede verdieping.

Cloudflare draait GLM 5.3 met de open-source inference-engine SGLang in een gedisaggregeerde configuratie. Prefill-GPU's verwerken de prompt en bouwen de KV-cache op; die cache wordt via RDMA overgedragen aan decode-GPU's, die vervolgens de respons genereren. Cloudflare gebruikt daarvoor Mooncake. RDMA betekent hier simpelweg dat geheugen van de ene machine direct naar geheugen van de andere gaat, zonder omweg via de CPU en het gewone netwerkpad. Dat scheelt latency bij het verplaatsen van grote hoeveelheden KV-data.

De cache is in dit systeem een gedeelde pool van pagina's met vaste grootte. Die pagina's worden tussen verzoeken niet leeggemaakt — dat is volgens Cloudflare gebruikelijk in inference-engines en nodig voor de beste prestaties — dus moet de engine nauwkeurig bijhouden welke pagina bij welk verzoek hoort. Zodra die boekhouding ergens niet klopt, kan een verzoek pagina's lezen die nog de gegevens van een vorig verzoek bevatten. Precies dat gebeurde hier.

## Oorzaak een: KV-pool kleiner dan het contextvenster

GLM 5.3 werd op Workers AI uitgerold met een contextvenster van 1.048.576 tokens, maar de KV-cache-pool op de prefill-GPU's had ruimte voor 681.280 tokens. Die twee waarden worden in SGLang los van elkaar ingesteld: de poolgrootte volgt bij het opstarten uit het GPU-geheugen dat overblijft nadat de modelgewichten zijn geladen, terwijl de contextlengte een aparte configuratiewaarde is. Niets in de engine dwingt ze tot overeenstemming.

Cloudflare wist vóór de lancering van de mismatch en verwachtte dat de engine bij een te lange prompt een fout zou teruggeven. In de lange-contexttests kwamen echter succesvolle HTTP-responses terug. De tests van Cloudflare keken naar HTTP-responscodes en prestaties bij lange contexten, niet naar de inhoud en coherentie van de modeloutput. Daarmee bleef de mismatch onopgemerkt: het systeem leek te werken, en op het niveau van statuscodes werkte het ook.

Dat is een patroon dat je in je eigen stack ook tegenkomt. Een health check die alleen naar statuscodes en latency kijkt, vertelt je niets over de vraag of de output nog bij de invoer hoort. Zodra je contextlengtes boven de omvang van je KV-pool configureert, vraag je om problemen die een dergelijke check niet vangt.

## Oorzaak twee: een SGLang-bug bij disaggregated prefill/decode

De mismatch alleen leidde niet tot het lek. Er kwam een bug bij in de gedisaggregeerde prefill/decode-modus van SGLang. Een prompt die niet in de pool paste, werd intern als afgewezen gemarkeerd en vervangen door een placeholder van één token. In plaats van af te breken en een clientfout te retourneren, genereerde prefill KV-cache voor die placeholder en droeg die over aan de decode-node. Die decode-node ontving "transfer complete" en las in de attention-stap vervolgens verouderde KV-cache-pagina's die nog data bevatten van eerdere verzoeken: prompts en gedeeltelijke generaties van andere gebruikers.

De klant kreeg daarbij HTTP 200 in plaats van HTTP 400. Het antwoord was coherent en bevatte inhoud uit andermans KV-pagina's. Dat maakt het type fout lastig te herkennen: er ging niets stuk, er verscheen geen foutmelding, en de response zag er normaal uit. De bug was al op 6 juli 2026 door een andere gebruiker aan SGLang gemeld als issue #30233.

## Tijdlijn

Cloudflare publiceert de tijdlijn in UTC. Dat is handig om te weten als je wilt terugrekenen naar je eigen logs; die staan vaak in lokale tijd of in een andere zone.

- 8 september 2026, 23:11 UTC — melding ontvangen via HackerOne.
- 9 september 2026, 08:00 UTC — verificatie begint.
- 9 september 2026, 13:22 UTC — security incident afgekondigd; het lek wordt binnen 25 minuten gereproduceerd met twee onafhankelijke accounts.
- 9 september 2026, 14:00 UTC — GLM 5.3 op privé gezet, verzoeken krijgen HTTP 400, statuspagina bijgewerkt; het model is binnen 40 minuten na het afkondigen van het incident offline.
- 9 september 2026, 14:52 UTC — alle prefill-nodes draaien op de gecorrigeerde configuratie.
- 9 september 2026, 19:04 UTC — volledige deployment herbouwd met gecorrigeerde configuratie plus een door Cloudflare geschreven engine-patch, gevalideerd tegen het reproductiescript van de onderzoeker.
- 9 september 2026, 19:40 UTC — model weer publiek beschikbaar, dezelfde dag.
- 10 september 2026 — overleg met de SGLang-maintainers van RadixArk.
- 11 tot en met 19 september 2026 — aanvullende hardening op alle productie-deployments met SGLang.
- 19 oktober 2026 — SGLang v0.5.22 uitgebracht.
- 26 oktober 2026 — gecoördineerde publicatie met de onderzoeker en RadixArk.

## Herstel en hardening

De configuratie van GLM 5.3 is aangepast: de prefill-KV-pool bevat nu ongeveer 2,04 miljoen tokens, ruwweg het dubbele van het contextvenster van 1.048.576 tokens. Daarmee past een prompt die het contextvenster volledig benut ruim binnen de pool. Daarnaast is de engine gepatcht zodat een verzoek met een openstaande afwijzing bij de disaggregation-admission-queue met de oorspronkelijke fout wordt afgevoerd, vóórdat er KV wordt overgedragen. De upstream SGLang-PR's #36988 en #38935 adresseren dit incident.

Sinds het incident is er meer verhard. De deferred release is uitgebreid zodat prefill-bronpagina's worden vastgehouden en elk faaltype wordt afgedekt. Mooncake-transferbatches zijn begrensd. De load balancer is aangepast zodat een client die de verbinding verbreekt een verzoek niet midden in een transfer afbreekt. En bij elke wijziging aan een gedisaggregeerde deployment is er een controle: KV-poolgrootte tegenover contextlengte, deferred release op beide rollen, grenzen aan transferbatches en de vereiste patches. De engine-fix en de hardening zijn toegepast op elk model dat Cloudflare met SGLang serveert.

Voor de langere termijn werkt Cloudflare met het SGLang-team aan integriteitscontroles in de engine zelf, met paginaniveau-tags zodat een verzoek geen KV-pagina kan lezen die niet van hem is. Een prototype daarvan kostte in tests minder dan 1% doorvoer en tail-latency, maar is vanwege betrouwbaarheidsproblemen uitgeschakeld. Ook past Cloudflare formele verificatiemethoden toe op het RDMA-protocol voor KV-cache-overdracht.

## Advies voor wie zelf SGLang draait

De aanbevelingen in het rapport zijn direct toepasbaar, ook als je geen Cloudflare-klant bent. Meet op elke prefill- én decode-node de KV-poolgrootte af tegen de contextlengte, en doe dat op basis van het opstartlog van de engine, na elke wijziging in gewichten, kwantisatie, parallellisme of geheugenfractie. Is de pool kleiner dan de contextlengte, verlaag dan de contextlengte. Vertrouw er niet op dat een proxy de limiet wel afdwingt: die zit per definitie aan de buitenkant van het probleem.

Upgrade naar SGLang v0.5.22 of nieuwer; die versie bevat #36988 en #38935. Draai deferred KV release op beide rollen en begrens Mooncake-transferbatches. Zet corruptiedetectie aan waar dat ondersteund wordt: `--disaggregation-enable-kv-checksum` en `--kv-canary`. Cloudflare merkt wel op dat die opties nog niet elke modelarchitectuur afdekken, dus ze zijn een aanvulling en geen vervanging van de configuratiecheck. Zorg tot slot dat je proxy geen onnodige aborts genereert.

## Wat dit betekent voor Workers AI-gebruikers

Voor de meeste gebruikers van Workers AI verandert er niets. Het ging om één model, GLM 5.3, en dat model is op 9 september 2026 offline gehaald en dezelfde dag hersteld met een gecorrigeerde configuratie en een engine-patch. Andere modellen waren niet getroffen. Gebruik je GLM 5.3 met zeer lange prompts, dan is het zinvol om na te gaan of je in de periode van 27 augustus tot 9 september 2026 zat en of je in die periode prompts boven 681.280 tokens hebt aangeboden.

Interessanter is de bredere les: isolatie is bij inference geen eigenschap die je eenmalig inricht, maar iets dat per configuratiewijziging opnieuw klopt of niet klopt. Elke keer dat je een contextvenster verhoogt, een kwantisatie aanpast of parallellisme opschroeft, verschuift de verhouding tussen wat je belooft en wat je pool aankan. Wie daar grip op wil, kan [AI-security voor bedrijven](https://consultancy.llmnet.nl/ai-security-bedrijven) als kader nemen: niet als certificaat, maar als set van terugkerende controles.

De timing van het rapport is ook een praktisch gegeven. Cloudflare publiceerde op 26 oktober 2026, na afstemming met de onderzoeker en RadixArk, en verwijst voor het melden van beveiligingsproblemen in Workers AI naar hackerone.com/cloudflare. Draai je zelf inference, dan helpt het om je incidentprocedure één keer hardop door te lopen voordat je hem nodig hebt; [een incidentenprotocol opstellen voor fouten door taalmodellen](https://consultancy.llmnet.nl/een-incidentenprotocol-opstellen-voor-fouten-door-taalmodellen) beschrijft hoe je dat aanpakt zonder in juridische conclusies te vervallen. En als je de keuze maakt tussen zelf draaien en afnemen, geeft [het overzicht van inference-hosting en serverloze API's](https://directory.llmnet.nl/inference-hosting-gpu-clouds) je de afwegingen op een rij.

## Checks voor je eigen inference-stack

- Vergelijk op elke prefill- en decode-node de KV-poolgrootte met de contextlengte, op basis van het engine-opstartlog, na elke wijziging aan gewichten, kwantisatie, parallellisme of geheugenfractie.
- Verlaag de contextlengte wanneer de pool kleiner is dan de context; laat de twee waarden niet los van elkaar staan.
- Laat een proxy niet de limiet afdwingen; doe het in de engine zelf.
- Upgrade naar SGLang v0.5.22 of later, inclusief #36988 en #38935.
- Zet deferred KV release aan op zowel prefill als decode.
- Begrens de Mooncake-transferbatches.
- Schakel corruptiedetectie in waar ondersteund (`--disaggregation-enable-kv-checksum`, `--kv-canary`), met de kanttekening dat die niet elke modelarchitectuur dekt.
- Controleer dat je proxy geen onnodige aborts veroorzaakt bij afgebroken clientverbindingen.
- Test lange contexten niet alleen op statuscodes en latency, maar ook op inhoud en coherentie van de output.

Wat het rapport vooral duidelijk maakt, is hoe smal het pad was waarlangs dit misging: één model, één configuratie waarin de pool kleiner was dan het venster, en één codepad in de engine dat een afwijzing omzette in een placeholder in plaats van in een fout. Alle drie tegelijk waren nodig. Dat is ook de reden dat de fix uit meerdere lagen bestaat — een grotere pool, een engine-patch, en controles die een volgende mismatch eerder zichtbaar maken.

Voor ontwikkelaars die andere Workers AI-modellen gebruiken, geeft het rapport geen aanleiding tot actie; gebruikte je GLM 5.3 met extreem lange prompts in het genoemde venster, loop dan je eigen gebruik na. Voor wie zelf SGLang in gedisaggregeerde modus draait, zijn de aanbevelingen uit het rapport de kortste route naar een veiliger opstelling: meten, contextlengte begrenzen, upgraden en deferred release aanzetten. Het volledige rapport staat bij Cloudflare; de verwijzingen hieronder geven aan welke onderdelen waar vandaan komen.

Gecontroleerd op 2026-10-29.

Dit bericht is samengesteld met AI-ondersteuning en redactioneel gecontroleerd; bronnen staan hieronder.

## Bronnen

- C1, C3, C5 — melding via HackerOne door Gadi Evron (Knostic), omvang van 155 responses bij prompts langer dan 681.280 tokens, en de beschrijving van GLM als tekstgeneratiemodel voor agentic coding workflows: https://blog.cloudflare.com/kv-cache-exposure-remediation/
- C2 — afbakening: alleen GLM 5.3 was getroffen, andere Workers AI-modellen niet: https://blog.cloudflare.com/kv-cache-exposure-remediation/
- C4 — geen bewijs van opzettelijke exploitatie: https://blog.cloudflare.com/kv-cache-exposure-remediation/
- C6 — configuratiemismatch tussen contextvenster van 1.048.576 tokens en KV-pool van 681.280 tokens: https://blog.cloudflare.com/kv-cache-exposure-remediation/
- C7 — SGLang-bug bij disaggregated prefill/decode, HTTP 200 in plaats van HTTP 400, issue #30233: https://blog.cloudflare.com/kv-cache-exposure-remediation/
- C8 — architectuur met SGLang, RDMA via Mooncake en gedeelde pagina's zonder nulstelling: https://blog.cloudflare.com/kv-cache-exposure-remediation/
- C9 — tijdlijn in UTC van 8 september tot en met 26 oktober 2026: https://blog.cloudflare.com/kv-cache-exposure-remediation/
- C10 — herstel: pool van circa 2,04 miljoen tokens, engine-patch, PR's #36988 en #38935: https://blog.cloudflare.com/kv-cache-exposure-remediation/
- C11 — hardening op alle productie-SGLang-deployments: https://blog.cloudflare.com/kv-cache-exposure-remediation/
- C12 — adviezen voor operators, waaronder SGLang v0.5.22 of nieuwer: https://blog.cloudflare.com/kv-cache-exposure-remediation/
- C13 — langetermijnwerk aan paginaniveau-tags en formele verificatie van het RDMA-protocol: https://blog.cloudflare.com/kv-cache-exposure-remediation/
- C14 — gecoördineerde openbaarmaking, dank aan Gadi Evron en RadixArk, meldpunt hackerone.com/cloudflare: https://blog.cloudflare.com/kv-cache-exposure-remediation/