Cloudflare uvádí, že chyba v GLM-5.3 způsobila únik 155 odpovědí napříč relacemi tenantů

Cloudflare 26. října 2026 zveřejnil zprávu o incidentu, v níž odhalil únik dat z mezipaměti KV mezi požadavky v modelu GLM-5.3 na platformě Workers AI. V rámci tohoto incidentu obsahovalo 155 odpovědí na velmi dlouhé prompty data z relací jiných zákazníků.

Bezpečnostní výzkumník Gadi Evron ze společnosti Knostic nahlásil problém s izolací tenantů Cloudflare 8. září 2026 prostřednictvím firemního programu HackerOne. Únik se týkal modelu poskytovaného pod označením @cf/zai-org/glm-5.3, a to od 27. srpna 2026, kdy byl GLM 5.3 na Workers AI spuštěn. Cloudflare problém napravil a 9. září 2026 model znovu zpřístupnil. Uvedl také, že ověřil, že se problém netýkal žádného jiného modelu hostovaného na Workers AI.

Všech 155 dotčených odpovědí se týkalo promptů delších než 681 280 tokenů. Cloudflare uvedl, že po vyloučení vlastního testování a požadavků výzkumníka odpovídaly zjištěné požadavky běžnému využití dlouhého kontextu co do načasování i objemu, nikoli opakovanému zneužívání chyby, a že nenašel žádné důkazy o úmyslném zneužití.

Dva problémy, které vedly k úniku

GLM je model pro generování textu od Z.ai určený pro agentní pracovní postupy při programování a patří mezi řadu modelů dostupných prostřednictvím Workers AI. Cloudflare provozuje GLM 5.3 s otevřeným inferenčním modulem SGLang v oddělené konfiguraci: GPU pro předzpracování promptu zpracují prompt a vytvoří jeho mezipaměť KV, kterou poté prostřednictvím technologie Mooncake předají přes vzdálený přímý přístup do paměti (RDMA) GPU pro dekódování, jež generují odpověď. Mezipaměť KV tvoří sdílená zásoba stránek pevné velikosti. Stránky se mezi požadavky nevynulují, takže za evidenci vlastnictví každé z nich odpovídá inferenční modul.

Zpráva připisuje únik dvěma problémům. Prvním byla chybná konfigurace: Cloudflare nasadil GLM 5.3 s kontextovým oknem o velikosti 1 048 576 tokenů, ale zásoba mezipaměti KV na GPU pro předzpracování promptů pojala pouze 681 280 tokenů. Cloudflare uvedl, že o nesouladu věděl už před spuštěním, očekával však, že inferenční modul vrátí chybu u každého promptu, který nedokáže zpracovat. Jeho testy s dlouhým kontextem navíc vracely úspěšné odpovědi, a proto se společnost nedomnívala, že by nesoulad představoval problém. Uvedla, že testování ověřovalo stavové kódy HTTP a výkon inferenčního modulu při dlouhém kontextu, nikoli však výstup modelu a jeho soudržnost. Nyní před nasazením jakékoli změny oddělené konfigurace přímo kontroluje velikost zásoby KV vůči délce kontextu.

Druhým problémem byla chyba v SGLang, která se týkala zpracování požadavků překračujících limit v odděleném režimu předzpracování a dekódování. Prompt, který se do zásoby nevešel, byl interně označen jako zamítnutý a nahrazen zástupným tokenem, ale předzpracování přesto pro tento zástupný token vytvořilo mezipaměť KV a oznámilo dokončení přenosu. Uzel pro dekódování pak vygeneroval odpověď s využitím zastaralých stránek mezipaměti, které stále obsahovaly data z dřívějších požadavků, a klient místo HTTP 400 obdržel odpověď HTTP 200.

Tým SGLang ve svém vlastním koordinovaném příspěvku uvádí, že při zamítnutí požadavku na jediném uzlu se místo toho vrátila chyba, takže k problému docházelo pouze při obsluze v odděleném režimu. Chybu nahlásil SGLang jiný uživatel jako problém č. 30233 dne 6. července 2026. Cloudflare uvedl, že si hlášení všiml během vyšetřování.

Reakce na incident a náprava

Cloudflare začal zprávu ověřovat 9. září 2026 v 08:00 UTC a ve 13:22 vyhlásil bezpečnostní incident poté, co jeho tým produktové bezpečnosti do 25 minut reprodukoval únik pomocí dvou nezávislých účtů. Ve 14:00 nastavil GLM 5.3 jako soukromý, ve 14:35 určil hlavní příčinu, do 14:52 nasadil opravenou konfiguraci na všechny uzly pro předzpracování promptů, do 19:04 znovu sestavil celé nasazení s opravou inferenčního modulu, kterou vytvořil Cloudflare, a v 19:40 model znovu zpřístupnil veřejnosti. Stavová stránka Cloudflare zaznamenala, že incident ve Workers AI začal 9. září 2026 v 10:25 AM EDT, byl identifikován v 11:02 AM EDT a vyřešen v 4:09 PM EDT.

Oprava konfigurace odpovídala nastavení GLM 5.2 a uvolnila dostatek paměti GPU, takže zásoba mezipaměti KV pro předzpracování promptů nyní pojme přibližně 2,04 milionu tokenů, tedy zhruba dvojnásobek kontextového okna o velikosti 1 048 576 tokenů. Prompt, který se vejde do kontextového okna, se proto vždy vejde i do zásoby. Oprava inferenčního modulu ukončí požadavek čekající na zamítnutí ve frontě pro přijetí při odděleném zpracování a vrátí jeho původní chybu ještě před jakoukoli inicializací, alokací nebo přenosem KV. Cloudflare obě změny před opětovným zpřístupněním modelu ověřil pomocí reprodukčního skriptu výzkumníka a vlastních testů se značkovacími prvky Canary.

Opravy v hlavní větvi a další práce

Cloudflare navrhl svou opravu v hlavní větvi projektu jako požadavek na začlenění změn SGLang č. 38704. Správci projektu začlenili změnu č. 38935, která podle postupu Cloudflare zamítá dotčené požadavky už při jejich přijetí. Související oprava č. 36988 byla začleněna 6. září 2026 a řešila příbuznou cestu vedoucí k selhání. Oprava byla vydána v SGLang v0.5.20 a následně doplněna ve verzích v0.5.21, vydané 2. října 2026, a v0.5.22, vydané 19. října 2026. Cloudflare doporučuje všem provozovatelům SGLang aktualizovat na verzi v0.5.22 nebo novější. Tým SGLang uvádí, že v0.5.21 ve výchozím nastavení chrání nasazení Mooncake a NIXL před všemi druhy selhání, nasazení MORI vyžadují sestavení ve verzi v0.5.22 a tato řada oprav nebyla zpětně přenesena do starších větví vydání.

Tým SGLang uvedl, že při 21 bězích na dvou GPU H100 se rozdíly v propustnosti s ochranami pohybovaly v rozmezí ±2 %, přičemž každý 95% interval spolehlivosti zahrnoval nulu. Při samostatné sérii 16 běhů na dvou GPU H200 pak naměřil náklady na zapnutí odloženého uvolňování KV ve výchozím nastavení ve výši −0,38 %; interval spolehlivosti od −2,12 % do +1,36 % označil za statisticky nevýznamný. Cloudflare se 10. září 2026 setkala se správci SGLang v RadixArk, mezi 11. a 19. zářím 2026 zavedla další bezpečnostní opatření ve všech svých produkčních nasazeních SGLang a navazující změny zahrnující opravu při přijímání požadavků, kontrolní součty jednotlivých přenosů, zachování potvrzení o přerušení a odložené uvolňování KV zapnuté ve výchozím nastavení byly sloučeny mezi 16. zářím a 12. říjnem 2026.

Provozovatelům, kteří používají SGLang v odděleném režimu, zpráva Cloudflare doporučuje po každé změně vah, kvantizace, paralelismu nebo podílu paměti změřit kapacitu fondu KV v závislosti na délce kontextu na každém uzlu pro předvyplňování i dekódování; přejít na sestavení obsahující obě opravy při přijímání požadavků; používat odložené uvolňování KV v obou rolích; zapnout detekci poškození, pokud ji model podporuje; a nastavit vyvažovače zátěže tak, aby odpojení klienta nepřerušilo požadavek uprostřed přenosu.

Cloudflare uvedla, že již dříve vytvořila prototyp návrhu, který označuje každou fyzickou stránku KV a před čtením mezipaměti při dekódování kontroluje mapování; podle testů činil jeho dopad na propustnost a koncovou latenci méně než 1 %. Společnost prototyp otestovala na GLM 5.2 v polovině srpna 2026, ale krátce nato jej kvůli problémům se spolehlivostí deaktivovala. Cloudflare spolupracuje s týmem SGLang na produkční verzi integrované do enginu; prvním krokem je kontrolní součet pro každý přenos v pull requestu #39500. Uvedla také, že své zkušenosti s formálními metodami využívá k modelování a dokazování bezpečnosti protokolu pro přenos mezipaměti KV založeného na RDMA, který používá Mooncake v jejím produkčním nasazení SGLang.

Příspěvek týmu SGLang děkuje inženýrům Cloudflare Kevinu Flansburgovi a Kastanu Dayovi za jejich práci na opravách a jako poslední položku v časové ose zveřejnění uvádí koordinované zveřejnění informací týmy SGLang a Cloudflare dne 26. října 2026. Vlastní zpráva výzkumníka, která podle týmu SGLang popíše objev a externí ověření, teprve vyjde.