Cloudflare zveřejnil podrobnou zprávu o incidentu popisující, jak chyba zpracování mezipaměti v její platformě AI bez serveru způsobila, že nejméně 155 uživatelů nasazení modelu GLM-5.3 obdrželo odpovědi obsahující fragmenty výzev a výstupů jiných zákazníků. Zpráva zveřejněná 26. října jako koordinované zveřejnění spolu s projektem open-source inferenčního enginu SGLang nabízí veřejnosti vzácný pohled do instalace LLM s více nájemci – a varování před předpoklady zabezpečení paměti GPU.
Jak byl únik nalezen For more context on this story, see our ongoing breaking AI news.
Podle Cloudflare bezpečnostní výzkumník Gadi Evron z Knostic upozornil společnost 8. září 2026 prostřednictvím svého programu odměny za chyby HackerOne. Evron uvedl, že velmi dlouhé výzvy odeslané do modelu GLM-5.3 na platformě Cloudflare Workers AI někdy vracely text, který patřil k relacím jiných uživatelů. Cloudflare problém reprodukoval následující ráno a téhož dne deaktivoval model a obnovil jej 9. září po nasazení oprav.
Dotčený model byl @cf/zai-org/glm-5.3 — model agentního kódování od Z.ai, který Cloudflare obsluhuje prostřednictvím Workers AI, firemní bezserverové inferenční platformy. Cloudflare potvrdil, že žádný jiný model hostovaný na platformě nebyl ovlivněn.
Co se vlastně stalo
Incident se vrací ke dvěma překrývajícím se problémům, jednomu provoznímu a druhému v samotném motoru.
Za prvé, špatná konfigurace. Cloudflare nasadil GLM-5.3 s kontextovým oknem 1 048 576 tokenů, ale fond mezipaměti klíč-hodnota (KV) na jeho předvyplněných GPU měl místo pouze pro 681 280 tokenů. Společnost potvrdila, že si byla vědoma tohoto nesouladu před spuštěním a očekávala, že inferenční modul bezpečně odmítne příliš dlouhé požadavky.
Za druhé, chyba motoru. V režimu rozčleněného prefill/decode — architektura Workers AI, ve které jeden fond GPU zpracovává výzvu a předává výslednou mezipaměť KV samostatnému fondu GPU, které generují odpověď – SGLang nesprávně zpracoval požadavek na překročení délky. Výzva, která se nevešla do fondu, byla interně označena jako odmítnutá a nahrazena zástupným symbolem s jedním tokenem. Namísto přerušení požadavku a vrácení chyby klienta však fáze předvyplnění vygenerovala mezipaměť KV pro výzvu zástupného symbolu a přenesla ji do dekódovacího uzlu, který pak vytvořil odpověď, která zamíchala zbývající data z předchozích požadavků sdílejících stejné stránky paměti.
Výsledek: mezi 27. srpnem a 9. zářím obdržel malý počet zákazníků využívajících tento model odpovědi obsahující data z požadavků jiných zákazníků, které byly učiněny krátce před jejich. Celkem bylo ovlivněno 155 odpovědí – všechny, jak Cloudflare zjistil, na výzvy delší než 681 280 tokenů.
Žádné důkazy o úmyslném vykořisťování
Cloudflare uvedl, že po vyloučení vlastního testování a požadavků výzkumníka na ověření byly dotčené požadavky konzistentní v načasování a objemu s běžným používáním v dlouhém kontextu a společnost nenašla žádné důkazy o tom, že by někdo úmyslně zneužil chybu. Protože každý dotčený požadavek překračoval kapacitu poddimenzovaného fondu, okno expozice bylo pevně ohraničeno – stříbrná čára, která pramení ze samotné nesprávné konfigurace, která problém způsobila.
Oprava: Větší bazény a bezpečnější cesta k selhání
Sanace fungovala na obou vrstvách poruchy. Cloudflare překonfiguroval své nasazení GLM-5.3 tak, aby odpovídalo konfiguraci GLM-5.2, a uvolnil tak dostatek paměti GPU, že předvyplněný KV fond nyní obsahuje asi 2,04 milionu tokenů – zhruba dvojnásobek délky kontextu modelu 1 048 576 tokenů. Výzva, která se hodí do kontextového okna, nyní vždy odpovídá fondu.
Společnost však také zdůraznila, že spoléhat se pouze na dimenzování bazénu je křehké: změny kvantizace, paralelismus tenzoru, velikosti grafů CUDA nebo budoucí verze modelu mohou tiše změnit velikost fondu. Takže také opravila samotnou cestu odmítnutí SGLang a zajistila, že odmítnutý požadavek se čistě přeruší namísto generování a přenosu mezipaměti pro zástupný symbol. Obě změny byly ověřeny proti reprodukčnímu skriptu výzkumníka a vlastním testům kanárských markerů Cloudflare, než byl model obnoven, a opravy byly poskytnuty správcům SGLang.
Proč je sdílená paměť GPU bezpečnostní otázkou
Zpráva vysvětluje postup, který překvapí mnoho vývojářů aplikací: inferenční stroje obecně nevynulují stránky mezipaměti KV mezi požadavky, protože další požadavek je jednoduše přepíše. Jedná se o záměrný kompromis ve výkonu, který je běžný u inferenčních enginů, ale jak ukazuje tento incident, jakákoli cesta, která umožňuje vygenerovat odpověď před úplným přepsáním těchto stránek, změní optimalizaci výkonu na vektor úniku dat.
Toto odhalení přistálo u vývojářské komunity: příběh dosáhl 123 bodů na Hacker News během několika hodin, přičemž diskuse se zaměřovala na to, jak režim selhání – požadavek, který by měl hlasitě selhat místo toho, aby v poškozeném stavu pokračoval v tichosti – odráží klasické lekce z inženýrství distribuovaných systémů.
Širší lekce pro infrastrukturu AI
Incident je připomínkou toho, že bezpečnostní perimetr pro aplikace AI nyní zasahuje hluboko do inferenční infrastruktury. Obsluha modelu s více nájemci soustřeďuje data mnoha zákazníků prostřednictvím sdílených akcelerátorů, sdílených fondů mezipaměti a stále exotičtějších architektur, jako je disagregované předvyplnění a vzdálený přímý přístup do paměti. Jemný nesoulad mezi inzerovaným kontextovým oknem modelu a fyzickou kapacitou zřízenou pro jeho obsluhu stačil k porušení izolace tenanta.
Pro podniky využívající bezserverové platformy umělé inteligence jsou poznatky ze zprávy Cloudflare dvojí: chyby v izolaci nájemců v poskytování LLM jsou skutečné a již se vyskytly ve výrobě a doba odezvy prodejců – méně než 24 hodin od nahlášení po deaktivaci, jeden den na opravu a obnovení – je standardem pečlivosti, kterou vyžaduje každý poskytovatel, který zpracovává citlivé výzvy.
---
Stay Ahead of AIGet the latest AI news, analysis, and breakthroughs — all in one place.
Read more AI news →
