Aktualności, narzędzia i prawo AIPolska · codziennie
Narzędzia

Cloudflare Workers AI. Model GLM-5.3 zwracał dane innych klientów

Przez blisko dwa tygodnie GLM-5.3 w Workers AI dołączał do części odpowiedzi dane z zapytań innych klientów. Cloudflare naliczył 155 takich przypadków.

Inżynierka z siwymi włosami w berlińskim biurze o zmierzchu analizuje oś czasu incydentu na monitorze i wykresy pamięci serwerów na laptopie, obok leży wydrukowana lista kontrolna
Ilustracja redakcyjna dailyAI

Cloudflare 26 października 2026 roku opisał błąd izolacji danych między klientami w usłudze Workers AI. Model GLM-5.3, udostępniany przez API Cloudflare, od 27 sierpnia do 9 września 2026 roku w części odpowiedzi na bardzo długie zapytania zwracał treści z zapytań innych klientów, wysłanych chwilę wcześniej. Firma naliczyła 155 takich odpowiedzi, wszystkie dla promptów dłuższych niż 681 280 tokenów, i nie znalazła śladów celowego wykorzystania luki. Błąd usunięto 9 września, a poprawki trafiły też do otwartego silnika SGLang, z którego korzystają także firmy uruchamiające modele na własnych serwerach.

Co się stało w Workers AI

Workers AI to usługa Cloudflare, w której programiści wywołują otwarte modele przez API, bez utrzymywania własnych serwerów z kartami graficznymi. GLM-5.3 chińskiej firmy Z.ai trafił tam 27 sierpnia 2026 roku z oknem kontekstu 1 048 576 tokenów, czyli z możliwością przyjęcia w jednym zapytaniu tekstu o objętości kilku grubych książek. Według wpisu Michelle Chen z Cloudflare przy promptach przekraczających określoną długość odpowiedź modelu mogła zawierać dane z wcześniejszych zapytań innych klientów.

Cloudflare 9 września o 14:00 UTC ustawił model jako prywatny, a zapytania zaczęły zwracać błąd HTTP 400. Po wdrożeniu poprawek GLM-5.3 wrócił do publicznej oferty tego samego dnia o 19:40 UTC. Pełny opis incydentu firma opublikowała dopiero 26 października, równolegle z wpisem zespołu SGLang, w ramach skoordynowanego ujawnienia.

Skąd wziął się wyciek między klientami

Duże modele językowe przechowują w pamięci GPU tak zwaną pamięć podręczną KV (key-value), czyli wyniki obliczeń dla już przetworzonej części promptu. Cloudflare uruchamia GLM-5.3 w trybie rozdzielonym. Jeden serwer przetwarza prompt (etap prefill), a drugi generuje odpowiedź (etap decode) i pobiera od pierwszego gotowe dane z tej pamięci.

Firma wskazuje dwa błędy, które wystąpiły jednocześnie. Pula pamięci KV na serwerach przetwarzających prompt mieściła 681 280 tokenów, wyraźnie mniej niż deklarowane okno kontekstu modelu. SGLang, otwarty silnik do serwowania modeli, nie przerywał przy tym poprawnie zbyt długich zapytań, więc serwer generujący odpowiedź czytał nieaktualne strony pamięci, pozostawione przez wcześniejsze zapytania innych użytkowników. Szczegółów technicznych wykraczających poza opis producenta nie podajemy.

Skala incydentu i oś czasu

Cloudflare naliczył 155 odpowiedzi zawierających cudze dane i określa grupę dotkniętych klientów jako niewielką. Po odfiltrowaniu własnych testów i zapytań badacza pozostały ruch wyglądał według firmy na zwykłe korzystanie z długiego kontekstu, bez prób celowego wywołania błędu. Wpis nie wyjaśnia, jakiego rodzaju dane trafiły do cudzych odpowiedzi, ani w jaki sposób powiadomiono klientów.

  • 27 sierpnia 2026 - premiera GLM-5.3 w Workers AI, błąd obecny od pierwszego dnia.
  • 8 września, 23:11 UTC - zgłoszenie badacza przez program HackerOne.
  • 9 września, 14:00 UTC - model ustawiony jako prywatny, zapytania kończą się błędem HTTP 400.
  • 9 września, 19:40 UTC - model wraca po zmianie konfiguracji i poprawce SGLang.
  • 26 października 2026 - publikacja pełnego opisu incydentu.

Jakie poprawki wdrożył Cloudflare

Firma zwiększyła pulę pamięci KV do około 2,04 mln tokenów, czyli mniej więcej dwukrotności okna kontekstu modelu. SGLang odrzuca teraz zbyt długie zapytania z komunikatem o błędzie, zanim jakiekolwiek dane trafią między serwerami. Poprawki sprawdzono na skrypcie badacza i na wewnętrznych testach kontrolnych, a dodatkowe zabezpieczenia objęły wszystkie produkcyjne wdrożenia SGLang w Cloudflare.

Zmiany trafiły też do głównej wersji SGLang w wydaniach od 0.5.20 do 0.5.22. Cloudflare zapowiada kontrolę integralności na poziomie pojedynczych stron pamięci oraz formalną weryfikację protokołu przesyłania pamięci podręcznej między serwerami.

Co powinny sprawdzić firmy korzystające z API modeli

Firmy, które między 27 sierpnia a 9 września 2026 roku wysyłały do GLM-5.3 w Workers AI bardzo długie zapytania, powinny przejrzeć logi i ustalić, jakie dane zawierały prompty i odpowiedzi. Jeżeli w zapytaniach znajdowały się dane osobowe, ocenę dalszych kroków wynikających z RODO warto przeprowadzić z inspektorem ochrony danych. Wpis Cloudflare nie mówi, czy dostawca indywidualnie informował klientów, dlatego o potwierdzenie najlepiej zapytać bezpośrednio.

Zespoły, które uruchamiają modele na własnej infrastrukturze z SGLang w trybie rozdzielonym, powinny zaktualizować silnik co najmniej do wersji 0.5.22. W naszej ocenie incydent pokazuje ryzyko, o którym rzadko mówi się przy wyborze API, czyli współdzielenie pamięci GPU przez wielu klientów. Przy danych wrażliwych warto wymagać od dostawcy opisu izolacji między klientami albo korzystać z instancji dedykowanych.

Źródła i data sprawdzenia

  1. Remediating a KV cache exposure in Workers AICloudflare, publikacja: 2026-10-26, sprawdzono: 2026-10-28
  2. SGLang - wydaniaGitHub, projekt SGLang, publikacja: 2026-10-26, sprawdzono: 2026-10-28
Nota redakcyjna

Artykuł ma charakter informacyjny. Przy decyzjach prawnych, finansowych lub organizacyjnych warto zweryfikować wnioski w odniesieniu do konkretnej sytuacji.