Cloudflare сообщает: ошибка в GLM-5.3 раскрыла 155 ответов между сессиями разных клиентов

26 октября 2026 года Cloudflare опубликовала отчет об инциденте, в котором сообщила об утечке данных из кэша KV между запросами к модели GLM-5.3 на платформе Workers AI: в 155 ответах на очень длинные запросы содержались данные из сессий других клиентов.

Исследователь безопасности Gadi Evron из Knostic сообщил Cloudflare о проблеме изоляции клиентов 8 сентября 2026 года через программу HackerOne компании. Уязвимость затрагивала модель, предоставлявшуюся под именем @cf/zai-org/glm-5.3, начиная с 27 августа 2026 года — дня запуска GLM 5.3 на Workers AI. Cloudflare устранила проблему и вновь открыла доступ к модели 9 сентября 2026 года. Компания заявила, что подтвердила: ни одна другая модель, размещенная на Workers AI, не пострадала.

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

Две проблемы, приведшие к утечке

GLM — текстовая модель генерации от Z.ai, предназначенная для агентных задач программирования и входящая в число многих моделей, доступных через Workers AI. Cloudflare запускает GLM 5.3 с помощью SGLang — движка инференса с открытым исходным кодом — в раздельной конфигурации: графические процессоры предварительной обработки запросов обрабатывают запрос и формируют его кэш KV, а затем передают этот кэш через удаленный прямой доступ к памяти (RDMA) с помощью Mooncake графическим процессорам декодирования, которые генерируют ответ. Кэш KV представляет собой общий пул страниц фиксированного размера; страницы не обнуляются между запросами, поэтому движок должен отслеживать, кому принадлежит каждая страница.

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

Вторая проблема — ошибка SGLang при обработке запросов, превышающих допустимую длину, в режиме раздельной предварительной обработки и декодирования. Запрос, не помещавшийся в пул, внутренне помечался как отклоненный и заменялся однокомпонентной заглушкой, однако предварительная обработка все равно создавала для нее кэш KV и сообщала о завершении передачи. Затем узел декодирования генерировал ответ, обращаясь к устаревшим страницам кэша, в которых по-прежнему хранились данные предыдущих запросов, а клиент получал ответ HTTP 200 вместо HTTP 400.

Команда SGLang сообщает в своей согласованной публикации, что при отклонении запроса на одном узле вместо этого возвращалась ошибка, поэтому проблема возникала только при раздельной обработке запросов. Об этой ошибке другой пользователь сообщил SGLang 6 июля 2026 года, создав задачу № 30233; Cloudflare заявила, что заметила ее в ходе расследования.

Реагирование на инцидент и устранение проблемы

Cloudflare начала проверять сообщение в 08:00 UTC 9 сентября 2026 года и объявила об инциденте безопасности в 13:22, после того как команда безопасности продуктов воспроизвела утечку с помощью двух независимых учетных записей менее чем за 25 минут. В 14:00 компания закрыла доступ к GLM 5.3, в 14:35 выявила первопричину, к 14:52 обновила конфигурацию всех узлов предварительной обработки, к 19:04 пересобрала развертывание целиком, включив исправление движка, разработанное Cloudflare, а в 19:40 вновь открыла публичный доступ к модели. На странице состояния Cloudflare указано, что инцидент с Workers AI начался в 10:25 утра EDT 9 сентября 2026 года, был выявлен в 11:02 утра EDT и устранен в 4:09 дня EDT.

Исправление конфигурации привело ее в соответствие с настройкой GLM 5.2 и высвободило достаточно памяти графических процессоров: теперь пул KV для предварительной обработки запросов вмещает около 2,04 миллиона токенов — примерно вдвое больше, чем длина окна контекста, составляющая 1 048 576 токенов. Поэтому любой запрос, помещающийся в окно контекста, всегда помещается и в пул. Исправление движка удаляет запрос с ожидающим отклонением из очереди допуска к раздельной обработке и возвращает исходную ошибку до начала какой-либо инициализации, выделения памяти или передачи KV. Перед восстановлением доступа к модели Cloudflare проверила оба изменения с помощью сценария воспроизведения исследователя и собственных тестов с контрольными маркерами.

Исправления в основной ветке и дальнейшая работа

Cloudflare предложила внести свое исправление в основную ветку SGLang в рамках запроса на включение изменений № 38704. Сопровождающие проект объединили изменения под номером № 38935: согласно подходу Cloudflare, они отклоняют затронутые запросы на этапе допуска. Связанное исправление № 36988 для другого сценария сбоя было внесено 6 сентября 2026 года. Исправление вошло в SGLang v0.5.20; последующие обновления появились в версиях v0.5.21, выпущенной 2 октября 2026 года, и v0.5.22, выпущенной 19 октября 2026 года. Cloudflare рекомендует всем операторам SGLang обновиться до v0.5.22 или более поздней версии. Команда SGLang сообщает, что v0.5.21 по умолчанию защищает развертывания Mooncake и NIXL от сбоев всех типов, для развертываний MORI требуется сборка в v0.5.22, а исправление не переносилось в более ранние ветки выпусков.

Команда SGLang сообщила, что в ходе 21 запуска на двух графических процессорах H100 отклонения пропускной способности при включенных мерах защиты не превышали ±2%, причем каждый 95%-й доверительный интервал включал ноль. В отдельной серии из 16 запусков на двух графических процессорах H200 измерили стоимость включения отложенного освобождения KV по умолчанию: −0,38%. Доверительный интервал составлял от −2,12% до +1,36%; команда охарактеризовала результат как статистически незначимый. 10 сентября 2026 года Cloudflare встретилась с сопровождающими SGLang в RadixArk, а с 11 по 19 сентября 2026 года внедрила дополнительные меры защиты во все свои производственные развертывания SGLang. Объединения изменений в основной репозиторий, охватывающие исправление на этапе допуска, контрольные суммы для каждой передачи, сохранение подтверждения прерывания и включение отложенного освобождения KV по умолчанию, выполнялись с 16 сентября по 12 октября 2026 года.

Для других операторов, использующих SGLang в режиме дезагрегированной обработки, в отчете Cloudflare рекомендуется после любых изменений весов, квантования, параллелизма или доли памяти измерять размер пула KV относительно длины контекста на каждом узле предварительной обработки (prefill) и декодирования; обновиться до сборки, содержащей оба исправления на этапе допуска; включить отложенное освобождение KV для обеих ролей; включить обнаружение повреждений данных, если модель это поддерживает; а также настроить балансировщики нагрузки так, чтобы отключение клиента не прерывало запрос в середине передачи.

Cloudflare сообщила, что ранее разработала прототип, в котором для каждой физической страницы KV указывалась метка, а перед чтением кэша при декодировании проверялось соответствие отображения; испытания показали, что его влияние на пропускную способность и хвостовую задержку составляет менее 1%. Компания протестировала прототип на GLM 5.2 в середине августа 2026 года, но вскоре отключила его из-за проблем с надежностью. Cloudflare совместно с командой SGLang разрабатывает производственную версию, встроенную в движок; первым шагом стала контрольная сумма для каждой передачи в запросе на включение изменений #39500. Компания также сообщила, что применяет свой опыт в области формальных методов для моделирования и доказательства безопасности протокола передачи кэша KV на основе RDMA с использованием Mooncake в своем производственном развертывании SGLang.

В публикации команды SGLang инженеры Cloudflare Кевин Флансбург и Кастан Дэй отмечены за работу над исправлениями, а согласованное раскрытие информации командами SGLang и Cloudflare 26 октября 2026 года указано как последний пункт в хронологии раскрытия. Ожидается публикация собственного отчета исследователя, в котором, по словам команды SGLang, будут описаны обнаружение проблемы и внешняя проверка.