Cloudflare twierdzi, że błąd w GLM-5.3 doprowadził do wycieku 155 odpowiedzi między sesjami klientów

26 października 2026 r. Cloudflare opublikował raport o incydencie, ujawniając, że w modelu GLM-5.3 na platformie Workers AI dochodziło do udostępniania między żądaniami danych z pamięci podręcznej KV. W rezultacie 155 odpowiedzi na bardzo długie prompty zawierało dane z sesji innych klientów.

Badacz bezpieczeństwa Gadi Evron z Knostic zgłosił Cloudflare problem z izolacją sesji klientów 8 września 2026 r. za pośrednictwem firmowego programu HackerOne. Problem dotyczył modelu udostępnianego jako @cf/zai-org/glm-5.3, począwszy od 27 sierpnia 2026 r., czyli dnia, w którym GLM 5.3 zadebiutował w Workers AI. Cloudflare usunął problem i ponownie udostępnił model 9 września 2026 r.; firma poinformowała, że potwierdziła, iż problem nie dotyczył żadnego innego modelu hostowanego w Workers AI.

Wszystkie 155 odpowiedzi, których dotyczył problem, wygenerowano dla promptów dłuższych niż 681 280 tokenów. Cloudflare poinformował, że po wyłączeniu własnych testów i żądań badacza zidentyfikowane żądania pod względem czasu i liczby odpowiadały zwykłemu korzystaniu z długiego kontekstu, a nie wielokrotnemu wykorzystywaniu błędu, oraz że nie znalazł dowodów na celowe wykorzystanie podatności.

Dwa problemy, które doprowadziły do wycieku

GLM to model generowania tekstu firmy Z.ai, przeznaczony do zadań programistycznych realizowanych przez agentów. Jest jednym z wielu modeli dostępnych za pośrednictwem Workers AI. Cloudflare uruchamia GLM 5.3 z użyciem SGLang, otwartoźródłowego silnika inferencyjnego, w konfiguracji rozdzielonej: procesory GPU do etapu prefill przetwarzają prompt i tworzą jego pamięć podręczną KV, a następnie przekazują ją za pośrednictwem zdalnego bezpośredniego dostępu do pamięci (RDMA), z użyciem Mooncake, do procesorów GPU do dekodowania, które generują odpowiedź. Pamięć podręczna KV to wspólna pula stron o stałym rozmiarze. Strony nie są zerowane między żądaniami, dlatego silnik musi śledzić, do kogo należy każda z nich.

Raport wskazuje dwa problemy, które doprowadziły do wycieku. Pierwszym była błędna konfiguracja: Cloudflare wdrożył GLM 5.3 z oknem kontekstu o długości 1 048 576 tokenów, ale pula pamięci podręcznej KV na procesorach GPU do etapu prefill mieściła tylko 681 280 tokenów. Cloudflare poinformował, że przed uruchomieniem modelu wiedział o tej rozbieżności, ale spodziewał się, że silnik zwróci błąd dla każdego promptu, którego nie będzie w stanie przetworzyć. Ponieważ testy z długim kontekstem kończyły się powodzeniem, firma nie uznała rozbieżności za problem. Firma poinformowała, że w testach sprawdzała kody odpowiedzi HTTP i wydajność silnika przy długim kontekście, ale nie weryfikowała wyników modelu ani ich spójności; dodała też, że przed wdrożeniem każdej zmiany w konfiguracji rozdzielonej bezpośrednio sprawdza teraz rozmiar puli KV w odniesieniu do długości kontekstu.

Drugim problemem był błąd SGLang w obsłudze żądań przekraczających dopuszczalną długość w rozdzielonym trybie prefill i dekodowania. Prompt, który nie mieścił się w puli, był wewnętrznie oznaczany jako odrzucony i zastępowany jednotokenowym symbolem zastępczym, ale proces prefill nadal generował dla niego pamięć podręczną KV i sygnalizował zakończenie jej transferu. Następnie węzeł dekodujący generował odpowiedź, korzystając ze starych stron pamięci podręcznej, które wciąż zawierały dane z wcześniejszych żądań, a klient otrzymywał odpowiedź HTTP 200 zamiast HTTP 400.

Zespół SGLang poinformował w swoim skoordynowanym wpisie, że ścieżka odrzucania żądań w konfiguracji jednowęzłowej zwracała błąd, więc problem występował wyłącznie przy obsłudze żądań w konfiguracji rozdzielonej. Inny użytkownik zgłosił ten błąd zespołowi SGLang 6 lipca 2026 r. jako problem nr 30233; Cloudflare poinformował, że zauważył to zgłoszenie podczas dochodzenia.

Reakcja na incydent i usunięcie problemu

Cloudflare rozpoczął weryfikację zgłoszenia 9 września 2026 r. o godz. 08:00 UTC, a o 13:22 ogłosił incydent bezpieczeństwa, gdy zespół ds. bezpieczeństwa produktów odtworzył wyciek, używając dwóch niezależnych kont — zajęło to 25 minut. O 14:00 firma ustawiła GLM 5.3 jako prywatny, o 14:35 ustaliła przyczynę źródłową, do 14:52 wdrożyła poprawioną konfigurację na wszystkich węzłach prefill, do 19:04 ponownie zbudowała całe wdrożenie z poprawką silnika opracowaną przez Cloudflare, a o 19:40 ponownie udostępniła model publicznie. Strona statusu Cloudflare odnotowała, że incydent w Workers AI rozpoczął się 9 września 2026 r. o 10:25 EDT, został wykryty o 11:02 EDT i rozwiązany o 16:09 EDT.

Poprawka konfiguracji doprowadziła ją do zgodności z konfiguracją GLM 5.2 i zwolniła wystarczająco dużo pamięci GPU, by pula KV dla etapu prefill mieściła teraz około 2,04 miliona tokenów, czyli mniej więcej dwa razy więcej niż wynosi długość okna kontekstu — 1 048 576 tokenów. Dzięki temu prompt mieszczący się w oknie kontekstu zawsze mieści się także w puli. Poprawka silnika usuwa żądanie oczekujące na odrzucenie z kolejki przyjmowania w konfiguracji rozdzielonej, zachowując pierwotny błąd, zanim dojdzie do inicjalizacji, alokacji lub transferu KV. Przed ponownym udostępnieniem modelu Cloudflare zweryfikował obie zmiany za pomocą skryptu odtwarzającego problem, dostarczonego przez badacza, oraz własnych testów ze znacznikami canary.

Poprawki wprowadzone do głównego repozytorium i dalsze prace

Cloudflare zaproponował poprawkę w głównym repozytorium jako pull request nr 38704 do SGLang. Opiekunowie projektu scalili pull request nr 38935, który zgodnie z podejściem Cloudflare odrzuca problematyczne żądania na etapie ich przyjmowania. Powiązana poprawka nr 36988, dotycząca innej ścieżki awarii, została scalona 6 września 2026 r. Poprawka trafiła do SGLang v0.5.20, a jej uzupełnienia znalazły się w v0.5.21, wydanej 2 października 2026 r., oraz v0.5.22, wydanej 19 października 2026 r. Cloudflare zaleca wszystkim operatorom SGLang aktualizację do wersji v0.5.22 lub nowszej. Zespół SGLang informuje, że v0.5.21 domyślnie zabezpiecza wdrożenia Mooncake i NIXL przed każdym rodzajem awarii, wdrożenia MORI wymagają kompilacji w wersji v0.5.22, a poprawki nie przeniesiono do wcześniejszych gałęzi wydań.

Zespół SGLang poinformował, że w 21 przebiegach na dwóch procesorach graficznych H100 różnice w przepustowości przy włączonych zabezpieczeniach mieściły się w przedziale ±2%, a każdy 95-procentowy przedział ufności obejmował zero. W osobnej serii 16 przebiegów na dwóch procesorach graficznych H200 zmierzono koszt domyślnego włączenia odroczonego zwalniania KV: −0,38%. Przedział ufności wynosił od −2,12% do +1,36%, co zespół uznał za wynik nieistotny statystycznie. 10 września 2026 roku przedstawiciele Cloudflare spotkali się z opiekunami SGLang w RadixArk. W dniach od 11 do 19 września 2026 roku firma wdrożyła dodatkowe zabezpieczenia we wszystkich swoich produkcyjnych wdrożeniach SGLang. Scalenia w repozytorium nadrzędnym, obejmujące poprawkę dotyczącą przyjmowania żądań, sumy kontrolne dla poszczególnych transferów, zachowanie potwierdzeń przerwania oraz domyślnie włączone odroczone zwalnianie KV, przeprowadzono w okresie od 16 września do 12 października 2026 roku.

W przypadku innych operatorów korzystających z SGLang w trybie rozdzielonym raport Cloudflare zaleca mierzenie puli KV względem długości kontekstu na każdym węźle wstępnego przetwarzania i dekodowania po każdej zmianie wag, kwantyzacji, równoległości lub udziału pamięci; aktualizację do kompilacji zawierającej obie poprawki dotyczące przyjmowania żądań; włączenie odroczonego zwalniania KV w obu rolach; włączenie wykrywania uszkodzeń, jeśli obsługuje je model; oraz skonfigurowanie modułów równoważenia obciążenia tak, by rozłączenie klienta nie przerywało żądania w trakcie transferu.

Cloudflare poinformowało, że wcześniej opracowało prototyp rozwiązania, które oznacza każdą fizyczną stronę KV i sprawdza mapowanie, zanim dekoder odczyta pamięć podręczną. W testach jego koszt w zakresie przepustowości i opóźnień ogonowych wyniósł mniej niż 1%. Firma przetestowała prototyp na GLM 5.2 w połowie sierpnia 2026 roku, ale wkrótce potem go wyłączyła z powodu problemów z niezawodnością. Cloudflare współpracuje z zespołem SGLang nad wersją produkcyjną wbudowaną w silnik; pierwszym krokiem jest suma kontrolna dla poszczególnych transferów w żądaniu ściągnięcia nr 39500. Firma poinformowała również, że wykorzystuje swoje doświadczenie w metodach formalnych do modelowania i dowodzenia bezpieczeństwa protokołu transferu pamięci podręcznej KV opartego na RDMA, który wykorzystuje Mooncake w jej produkcyjnym wdrożeniu SGLang.

W swoim wpisie zespół SGLang dziękuje inżynierom Cloudflare, Kevinowi Flansburgowi i Kastanowi Dayowi, za pracę nad poprawkami. Jako ostatnią pozycję na osi czasu ujawniania informacji wymienia skoordynowane ujawnienie sprawy przez SGLang i Cloudflare z 26 października 2026 roku. Raport samego badacza, który — jak zapowiedział zespół SGLang — opisze odkrycie i jego zewnętrzną walidację, ma się ukazać w przyszłości.