Cloudflare признала утечку данных между клиентами в GLM-5.3: 155 ответов

Cloudflare опубликовала отчёт об инциденте с изоляцией клиентов в модели GLM-5.3 (@cf/zai-org/glm-5.3) на платформе Workers AI. О проблеме 8 сентября 2026 года компанию предупредил Гади Эврон (Gadi Evron) из Knostic, исследователь по безопасности: через программу HackerOne он сообщил, что очень длинные промпты иногда возвращают текст из чужих сессий. Проблема существовала с 27 августа. Cloudflare воспроизвела её на следующее утро, в течение 40 минут после объявления инцидента отключила модель, а 9 сентября вернула сервис с исправленной конфигурацией и пропатченным движком.

По данным Cloudflare, за этот период небольшое число клиентов получило ответы с данными из запросов других клиентов к той же модели, сделанных незадолго до этого. Всего затронуто 155 ответов, и все они были на промпты длиннее 681 280 токенов. После исключения собственных тестов компании и тестов исследователя оставшиеся запросы по времени и объёму похожи на обычное использование длинного контекста, а не на повторяющуюся эксплуатацию уязвимости. Свидетельств умышленной эксплуатации Cloudflare не нашла. Никакая другая модель в Workers AI не пострадала. Отчёт опубликован одновременно с заметкой команды SGLang, открытого движка вывода, который использует Cloudflare, как скоординированное раскрытие.

Причин было две. Первая: GLM-5.3 развернули с окном контекста 1 048 576 токенов, но пул KV-кэша на GPU, выполняющих prefill (обработку промпта), вмещал лишь 681 280 токенов. Размер пула SGLang вычисляет при запуске по остатку памяти GPU после загрузки весов, а длина контекста, отдельный параметр, и ничто не заставляет их совпадать. Cloudflare знала о несовпадении до запуска, но ожидала, что движок вернёт ошибку на промпт, который не может обработать. Тесты длинного контекста давали успешные ответы, и в компании решили, что проблемы нет. Проверялись лишь коды HTTP-ответов и производительность движка, но не содержание и связность ответов модели.

Вторая причина, баг SGLang в режиме раздельных prefill и decode (генерации ответа). Слишком длинный промпт помечался как отклонённый и заменялся однотокенной заглушкой, но очередь приёма в раздельном режиме проверяла, завершён ли запрос, а не отклонён ли он, и отклонённый запрос считался живым. Prefill считал KV-кэш для заглушки, передавал одну страницу и сообщал о завершении передачи. Узел decode к тому времени зарезервировал 8 страниц (пример из схемы в отчёте), но записана была только P0, а страницы P1, P7 хранили данные прежних запросов: чужие промпты и частичные ответы. Страницы KV-кэша между запросами не обнуляются, это обычная практика движков вывода ради производительности. В итоге клиент получал HTTP 200 вместо HTTP 400, связный ответ, содержавший чужие данные, причём быстрее, чем должен был работать prefill на 8 страниц.

Что сделали. Конфигурацию GLM-5.3 привели к конфигурации GLM-5.2: освободилось достаточно памяти GPU, и пул prefill теперь вмещает около 2,04 млн токенов, примерно вдвое больше контекста. Кроме того, пропатчили движок: запрос с отложенным отказом снимается в очереди приёма со своей исходной ошибкой до начала передачи KV-кэша. Cloudflare предложила это в SGLang как #38704, где decode ещё и проверяет, что число переданных токенов совпадает с зарезервированным. Исправление #36988 уже было в основной ветке SGLang (влито 6 сентября для родственного сбоя, но не выпущено), а мейнтейнеры также приняли #38935, который отклоняет такие запросы раньше. Обе правки проверили на скрипте исследователя и на собственных тестах с маркерами. Эту ошибку другой пользователь ещё 6 июля 2026 года описал в задаче #30233 SGLang. Патч вышел в SGLang v0.5.20, доработки, в v0.5.21 и v0.5.22; Cloudflare настоятельно советует всем операторам обновиться до v0.5.22 или новее.

Этот случай Cloudflare относит к классу ошибок безопасности памяти KV-кэша, над которыми работает уже несколько месяцев: страница освобождается, переиспользуется или читается, пока на неё ещё есть чужие права. Есть и отдельная гонка между узлами при отмене запроса во время записи prefill в decode по RDMA, которая тоже может дать повреждённый вывод или данные одного пользователя в ответе другому. Cloudflare применила исправление и защитные меры ко всем моделям, которые обслуживает через SGLang, а её проверки развёртывания требуют их для каждого нового развёртывания.

Ключевые факты

• С 27 августа по 9 сентября 2026 года GLM-5.3 в Workers AI вернула 155 ответов с данными из чужих запросов; все это ответы на промпты длиннее 681 280 токенов.
• Причины две: пул KV-кэша prefill (681 280 токенов) был меньше окна контекста (1 048 576), а SGLang в раздельном режиме не отклонял слишком длинные запросы и отдавал ответ по устаревшим страницам кэша.
• О проблеме 8 сентября сообщил Гади Эврон из Knostic через HackerOne; модель отключили в течение 40 минут после объявления инцидента и вернули 9 сентября.
• Cloudflare не нашла свидетельств умышленной эксплуатации; другие модели Workers AI не затронуты.
• Патч вышел в SGLang v0.5.20, доработки в v0.5.21 и v0.5.22; Cloudflare советует всем операторам обновиться до v0.5.22 или новее.

Почему это важно

Это редкий подробный разбор утечки между клиентами в размещённой модели от самого оператора. Данные одних клиентов оказывались в ответах другим не из-за взлома, а из-за того, что страницы KV-кэша не обнуляются между запросами и за их принадлежность отвечает движок вывода. Ошибка сложилась из известного команде несовпадения настроек и бага в открытом движке SGLang, а штатные тесты её не заметили: они проверяли коды HTTP и производительность, но не содержание ответов.

Кому это важно

Операторам, которые сами размещают модели на SGLang, особенно в раздельном режиме prefill/decode. Клиентам Workers AI, отправлявшим в GLM-5.3 очень длинные промпты в указанный период. Командам безопасности и платформенным инженерам, которые отвечают за изоляцию клиентов в сервисах вывода.

Как это применить

Операторам SGLang Cloudflare рекомендует обновиться до v0.5.22 или новее. Сверяйте размер пула KV-кэша с длиной контекста непосредственно на запущенном движке перед каждым изменением раздельного развёртывания, а не выводите его из кодов ответа. В тесты длинного контекста стоит включать проверку содержания и связности ответов, а не только статуса HTTP. Cloudflare использует и маркерные тесты: в проверке после исправления применялись скрипт исследователя и собственные тесты с маркерами. Размер пула нужно сопоставлять с длиной контекста и после смены квантизации, тензорного параллелизма, размеров графов CUDA или версии модели.

Можно ли доверять

Источник первичный: это отчёт самой Cloudflare, опубликованный одновременно с заметкой команды SGLang. Числа и даты в нём конкретны, а ошибки компании названы прямо, включая то, что о несовпадении настроек знали до запуска. Вместе с тем вывод об отсутствии умышленной эксплуатации принадлежит Cloudflare и основан на её анализе запросов. Из доступного текста не видно, сколько именно клиентов затронуто (сказано лишь о небольшом числе) и какие данные оказались в 155 ответах; о компенсациях и уведомлениях тоже не сказано. Раздел с хронологией в доступном фрагменте отчёта не виден.

Риски и подводные камни

Cloudflare предупреждает, что опираться только на размер пула хрупко: его меняют квантизация, тензорный параллелизм, размеры графов CUDA или новая версия модели, поэтому нужна и защита в самом движке. Описанная ошибка входит в класс проблем с безопасностью памяти KV-кэша, над которыми компания работает несколько месяцев. Отдельная гонка между узлами при отмене запроса во время записи по RDMA тоже может приводить к повреждённому выводу или чужим данным в ответе, причём без сообщения об ошибке. Исправления для неё, предложенные Cloudflare (#31357, #38961), описаны как предложенные.

«Мы не нашли свидетельств умышленной эксплуатации.»

— Cloudflare, отчёт об инциденте