Cloudflare opublikowało szczegółowy raport o incydencie opisującym, jak błąd obsługi pamięci podręcznej w bezserwerowej platformie AI spowodował, że co najmniej 155 użytkowników wdrożenia modelu GLM-5.3 otrzymało odpowiedzi zawierające fragmenty monitów i wyników innych klientów. Raport, opublikowany 26 października jako skoordynowane ujawnienie wraz z projektem silnika wnioskowania o otwartym kodzie źródłowym SGLang, oferuje rzadkie publiczne wglądy w strukturę obsługi LLM dla wielu dzierżawców oraz ostrzeżenie dotyczące założeń bezpieczeństwa pamięci GPU.
Jak znaleziono wyciek Więcej kontekstu na ten temat znajdziesz w naszych wiadomości AI.
Według Cloudflare badacz bezpieczeństwa Gadi Evron z Knostic zaalarmował firmę 8 września 2026 r. w ramach programu nagród za błędy HackerOne. Evron poinformował, że bardzo długie monity wysyłane do modelu GLM-5.3 na platformie Workers AI firmy Cloudflare czasami zwracały tekst należący do sesji innych użytkowników. Cloudflare odtworzył problem następnego ranka i tego samego dnia wyłączył model, przywracając go 9 września po wdrożeniu poprawek.
Modelem, którego dotyczy problem, był @cf/zai-org/glm-5.3 — agentyczny model kodowania firmy Z.ai, który Cloudflare obsługuje za pośrednictwem Workers AI, bezserwerowej platformy wnioskowania firmy. Cloudflare potwierdziło, że problem nie dotyczył żadnego innego modelu hostowanego na platformie.
Co się właściwie wydarzyło
Incydent wynika z dwóch nakładających się problemów, jednego w działaniu i jednego w samym silniku.
Po pierwsze zła konfiguracja. Cloudflare wdrożył GLM-5.3 z oknem kontekstowym zawierającym 1 048 576 tokenów, ale w puli pamięci podręcznej klucz-wartość (KV) na wstępnie wypełnionych procesorach graficznych było miejsce tylko na 681 280 tokenów. Firma przyznała, że była świadoma tej niezgodności przed uruchomieniem i spodziewała się, że silnik wnioskowania będzie bezpiecznie odrzucał żądania przekraczające długość.
Po drugie, błąd silnika. W zdezagregowanym trybie wstępnego wypełniania/dekodowania — architekturze używanej przez Workers AI, w której jedna pula procesorów graficznych przetwarza monit i przekazuje wynikową pamięć podręczną KV oddzielnej puli procesorów graficznych, które generują odpowiedź — SGLang niepoprawnie obsłużył żądanie nadmiernej długości. Podpowiedź, która nie pasowała do puli, została wewnętrznie oznaczona jako odrzucona i zastąpiona symbolem zastępczym z jednym tokenem. Zamiast jednak przerywać żądanie i zwracać błąd klienta, etap wstępnego wypełniania wygenerował pamięć podręczną KV dla znaku zastępczego i przeniósł ją do węzła dekodowania, który następnie wygenerował odpowiedź, która zmieszała resztki danych z poprzednich żądań współdzielących te same strony pamięci.
Efekt: pomiędzy 27 sierpnia a 9 września niewielka liczba klientów korzystających z modelu otrzymała odpowiedzi zawierające dane z zapytań innych klientów, złożonych na krótko przed ich zapytaniami. W sumie problem dotyczył 155 odpowiedzi – wszystkie, jak odkrył Cloudflare, dotyczyły monitów dłuższych niż 681 280 tokenów.
Brak dowodów na celowe wykorzystanie
Cloudflare stwierdziło, że po wykluczeniu własnych testów i próśb badacza o zatwierdzenie, żądania, których to dotyczyło, były spójne pod względem czasu i liczby ze zwykłym użyciem w długim kontekście, a firma nie znalazła dowodów na to, że ktokolwiek celowo wykorzystał błąd. Ponieważ każde żądanie, którego to dotyczyło, przekraczało pojemność niewymiarowej puli, okno ekspozycji było ściśle ograniczone — pozytywne rozwiązanie wynikało z błędnej konfiguracji, która była przyczyną problemu.
Poprawka: większe pule i bezpieczniejsza ścieżka awarii
Naprawa zadziałała w przypadku obu warstw awarii. Cloudflare ponownie skonfigurował wdrożenie GLM-5.3, aby dopasować je do konfiguracji GLM-5.2, uwalniając wystarczającą ilość pamięci GPU, aby wstępnie wypełniona pula KV zawierała obecnie około 2,04 miliona tokenów — mniej więcej dwukrotnie więcej niż długość kontekstu modelu wynosząca 1 048 576 tokenów. Podpowiedź pasująca do okna kontekstowego teraz zawsze pasuje do puli.
Firma podkreśliła jednak również, że poleganie wyłącznie na rozmiarze puli jest kruche: zmiany w kwantyzacji, równoległości tensorów, rozmiarach wykresów CUDA lub przyszłej wersji modelu mogą po cichu zmienić rozmiar puli. Zatem załatano także samą ścieżkę odrzucenia SGLanga, zapewniając, że odrzucone żądanie zostanie przerwane w sposób czysty, zamiast generować i przesyłać pamięć podręczną dla obiektu zastępczego. Obie zmiany zostały sprawdzone w oparciu o skrypt reprodukcyjny badacza i własne testy Cloudflare dotyczące markerów kanarkowych przed przywróceniem modelu, a poprawki zostały przesłane do opiekunów SGLang.
Dlaczego współdzielona pamięć GPU jest kwestią bezpieczeństwa
W raporcie wyjaśniono praktykę, która zaskoczy wielu twórców aplikacji: silniki wnioskowania zazwyczaj nie zerują stron pamięci podręcznej KV pomiędzy żądaniami, ponieważ następne żądanie po prostu je nadpisuje. Jest to celowy kompromis w zakresie wydajności, powszechny we wszystkich silnikach wnioskowania, ale jak pokazuje ten incydent, każda ścieżka umożliwiająca wygenerowanie odpowiedzi przed całkowitym nadpisaniem stron zamienia optymalizację wydajności w wektor wycieku danych.
Ujawnienie dotarło do społeczności programistów: historia osiągnęła 123 punkty w Hacker News w ciągu kilku godzin, a dyskusja skupiała się na tym, jak tryb awarii — żądanie, które powinno zakończyć się głośnym niepowodzeniem, zamiast przebiegać cicho w stanie uszkodzonym — odzwierciedla klasyczne lekcje inżynierii systemów rozproszonych.
Szersza lekcja na temat infrastruktury AI
Ten incydent przypomina, że obszar bezpieczeństwa aplikacji AI sięga obecnie głęboko w infrastrukturę wnioskowania. Model obsługi wielu dzierżawców koncentruje dane wielu klientów za pośrednictwem współdzielonych akceleratorów, współdzielonych pul pamięci podręcznej i coraz bardziej egzotycznych architektur, takich jak zdezagregowane wstępne wypełnianie i zdalny, bezpośredni dostęp do pamięci. Subtelna rozbieżność między reklamowanym oknem kontekstowym modelu a fizyczną pojemnością zapewnioną do jego obsługi wystarczyła, aby naruszyć izolację najemcy.
W przypadku przedsiębiorstw korzystających z bezserwerowych platform AI wnioski z raportu Cloudflare są dwojakie: błędy izolacji dzierżawy w obsłudze LLM są rzeczywiste i wystąpiły już w środowisku produkcyjnym, a czas reakcji dostawców — poniżej 24 godzin od zgłoszenia do wyłączenia, jeden dzień na naprawę i przywrócenie — to standard staranności, jakiego należy wymagać od każdego dostawcy obsługującego wrażliwe monity.
---
Bądź na Bieżąco z AINajnowsze wiadomości, analizy i przełomy w dziedzinie AI — wszystko w jednym miejscu.
Czytaj więcej wiadomości AI →
