Утечка KV-кэша между запросами в модели GLM-5.3 на Workers AI и наше устранение уязвимости с помощью SGLang

8 сентября 2026 года исследователь безопасности Гади Эврон (Gadi Evron) из компании Knostic сообщил нам о проблеме изоляции тенантов, затрагивающей модель GLM-5.3 Workers AI (@cf/zai-org/glm-5.3) в период с 27 августа 2026 года. Мы устранили эту проблему и восстановили работу модели 9 сентября. Мы подтвердили, что никакие другие модели, размещенные на Workers AI, затронуты не были.

В период с 27 августа по 9 сентября небольшое число клиентов, использующих модель GLM 5.3 на Workers AI, получили ответы, содержащие данные из запросов других клиентов к той же модели, отправленных незадолго до этого. Всего было затронуто 155 ответов, и все они касались промптов длиной более 681 280 токенов.

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

Сегодня мы публикуем этот отчет одновременно с публикацией от SGLang — используемого нами движка инференса с открытым исходным кодом, — в рамках скоординированного раскрытия информации. В этой публикации описывается ошибка, вызвавшая проблему, хроника нашего реагирования и последующее усиление защиты наших производственных развертываний SGLang. Мы также подробно описываем нашу дальнейшую работу с мейнтейнерами SGLang по устранению этой и аналогичных ошибок.

Что произошло

GLM — это модель генерации текста от Z.ai, созданная для рабочих процессов агентного программирования; это одна из многих models, доступных через Workers AI. 8 сентября Гади Эврон подал отчет через нашу программу HackerOne, в котором сообщил, что очень длинные промпты, отправленные на @cf/zai-org/glm-5.3 в Workers AI, иногда возвращают текст, принадлежащий сессиям других пользователей. Cloudflare воспроизвела проблему на следующее утро и отключила модель в течение 40 минут после объявления инцидента. Затем мы развернули исправленную конфигурацию и пропатченный движок инференса, а также восстановили работу сервиса в тот же день.

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

Второй проблемой стала ошибка в том, как SGLang обрабатывал получившиеся запросы сверхлимитной длины в раздельном режиме префиллинга и декодирования (disaggregated prefill/decode). Промпт, который не помещался в пул, внутри системы помечался как отклоненный и заменялся однотокеновым плейсхолдером, но вместо прерывания запроса и возврата ошибки клиента этап префиллинга генерировал KV-кэш для промпта-плейсхолдера и передавал его на узел декодирования. Узел декодирования получал сообщение о «завершении передачи» и предполагал, что префиллинг перезаписал KV-кэш предыдущих запросов полным промптом для текущего запроса, хотя на самом деле он оставил большую часть предыдущего состояния неизменной. Впоследствии узел декодирования сгенерировал ответ, используя устаревшие страницы кэша, в которых все еще хранились данные из предыдущих запросов. В результате ответы на промпты длиной более 681 280 токенов могли содержать данные из сессий GLM 5.3 других пользователей.

Оперативное устранение

После отключения модели мы предприняли следующие действия для устранения этой уязвимости перед возобновлением публичного доступа к ней:

Чтобы исправить конфигурацию, мы увеличили пул до поддержки полного контекста. Мы настроили параметры GLM 5.3 в соответствии с нашей конфигурацией GLM 5.2, что высвободило достаточно памяти GPU, и теперь пул KV префиллинга вмещает около 2,04 миллиона токенов, что примерно в два раза превышает длину контекста в 1 048 576 токенов. Теперь промпт, помещающийся в окно контекста, всегда помещается и в пул, поэтому для корректного запроса ветка с отклонением никогда не задействуется. Это само по себе предотвращает возникновение ошибки.

Чтобы исправить сам движок, мы также сделали путь отклонения запросов безопасным. Опора исключительно на размер пула ненадежна: любое изменение квантования, тензорного параллелизма, размеров CUDA-графов или будущей версии модели меняет размер пула незаметным образом. Более того, могут существовать и другие ситуации, в которых планировщик префиллинга может отклонить запрос и вызвать ту же ошибку. Чтобы предотвратить это, мы также пропатчили движок таким образом, чтобы запрос с ожидающим отклонением завершался в очереди приема дезагрегации с исходной ошибкой до того, как произойдет какая-либо загрузка, выделение ресурсов или передача KV. Мы предложили это апстриму в качестве #38704, что также заставило узел декодирования проверять, соответствует ли количество переданных токенов зарезервированному количеству. Исправление уже присутствовало в ветке main SGLang в #36988, будучи слиянным 6 сентября для связанного сценария сбоя, но еще не было выпущено. Мейнтейнеры также объединили #38935, которая отклоняет такие запросы на более раннем этапе в соответствии с нашим подходом.

Перед восстановлением работы модели мы проверили оба изменения с помощью скрипта воспроизведения исследователя и наших собственных тестов с canary-маркерами.

Справочная информация: как мы обслуживаем GLM 5.3

Workers AI запускает GLM 5.3 с SGLang в дезагрегированной конфигурации: пул GPU префиллинга обрабатывает промпт и создает для него KV-кэш модели, а затем передает этот кэш через удаленный прямой доступ к памяти (RDMA) с помощью Mooncake в пул GPU декодирования, которые генерируют ответ. Ранее мы писали об этой архитектуре в наших публикациях о высокопроизводительных LLM и меньших, быстрых и безопасных моделях.

KV-кэш в памяти GPU представляет собой общий пул страниц фиксированного размера. Каждому запросу при поступлении назначаются страницы, и он освобождает их по завершении. Страницы в настоящее время не обнуляются между запросами; следующий запрос, получающий страницу, просто перезаписывает ее. Такой подход распространен среди движков инференса и необходим для достижения наилучшей производительности, но он означает, что движок инференса несет ответственность за отслеживание владения этими страницами памяти. Отслеживание владельца и времени жизни страниц KV-кэша должно справляться не только с совместным владением внутри узла (выгрузка KV-кэша и генерация токенов обращаются к памяти с разным временем жизни), но и с владением, которое технически является общим с удаленным узлом префиллинга (который удерживает одновременную изменяемую ссылку на страницу).

Более того, размер этого пула не является конфигурационным параметром. SGLang определяет его размер при запуске на основе остатка памяти GPU после загрузки весов модели. Заявленная длина контекста модели является отдельным параметром конфигурации. Ничто не заставляет их совпадать, и наша задача — проверять это.

Проблема первая: неверная конфигурация

На наших узлах префилла GLM 5.3 с нашей конфигурацией пул составлял 681 280 токенов, в то время как длина контекста модели составляет 1 048 576 токенов. Выбранный размер KV-пула выводится SGLang в логи во время запуска и передается в качестве метрики. Мы знали об этом несоответствии размеров; однако во время тестирования перед запуском мы наблюдали успешные HTTP-статус-коды и тело стриминга без фреймов ошибок во время бенчмаркинга. Мы предполагали, что движок способен корректно обрабатывать разницу между пулом KV-кэша и запрошенным окном контекста с помощью стриминга или какого-то другого механизма.

Это был один из критических пробелов в нашем тестировании: мы проверяли только HTTP-коды ответа и производительность движка при длинных контекстах, не проверяя вывод модели и его связность. Теперь мы проверяем размер KV-пула непосредственно на соответствие длине контекста из работающего движка перед отправкой любых изменений в разделенной (disaggregated) развертке, а не выводим его из кодов ответа.

Проблема вторая: баг в SGLang

В версии v0.5.21 команда SGLang исправила этот баг, связанный с тем, как обрабатывались промпты, превышающие по длине размер KV-пула. Вот что происходило раньше.

Когда поступал промпт, который был длиннее, чем мог вместить KV-пул, планировщик SGLang отклонял его. Путь отклонения (Req.set_finish_with_abort) записывал ошибку для возврата клиенту и заменял промпт плейсхолдером из одного токена, чтобы запрос мог пройти через стандартный механизм батчей без выделения реальной памяти. При развертывании на одном узле это работало: плейсхолдер отрабатывал, батч завершался, и клиент получал ошибку.

В разделенном (disaggregated) режиме, который используем мы, очереди приема (admission queues) как на префилле, так и на декодере проверяли, завершен ли запрос, а не отклонен ли он. Отклоненный запрос сообщал о себе как о действующем. Итак:

• Запуск. Роутер сообщил узлу декодирования длину промпта (8 страниц на диаграмме). Декодер зарезервировал 8 KV-страниц для запроса.
• Прием на префилл. Очередь приема префилла принимала любой запрос, у которого req.finished() возвращал False. Отклоненный запрос сохранял свое отклонение в to_finish, а не в finished_reason, поэтому finished() все равно возвращал False. Отклоненный запрос был принят.
• Прямой проход префилла. Отклонение уже заменило промпт плейсхолдером из одного токена. Префилл выполнил тривиальный прямой проход по этому единственному токену.
• Передача KV. Префилл отправил одну страницу KV на декодер и просигнализировал о завершении передачи.
• Прием на декодер. Очередь приема декодера выполняла ту же проверку finished(), поэтому приняла передачу.
• Внимание декодера. Декодер начал генерацию, и механизм внимания (attention) прочитал все 8 зарезервированных страниц. Записана этим запросом была только страница P0. Страницы с P1 по P7 по-прежнему содержали то, что оставили в них предыдущие запросы: промпты других пользователей и частичные генерации.
• Ответ. Клиент получил HTTP 200 вместо HTTP 400. prompt_tokens совпадали с длинным промптом, и ответ был связным. Он прибыл быстрее, чем должен занимать префилл из 8 страниц, и содержал контент из KV-страниц других пользователей.

Каждый запрос, превышающий пороговое значение, вел себя подобным образом. Об этом баге в SGLang сообщил другой пользователь как обissue #30233 6 июля 2026 года, что Cloudflare заметила во время расследования этого инцидента. Мы сообщали о проблемах такого типа в SGLang начиная с версии v0.5.10, и этот инцидент безопасности ускорил работу, которую Cloudflare уже начала в сотрудничестве с командой SGLang. Патч для этой проблемы был выпущен в SGLang v0.5.20 с последующими доработками в v0.5.21 и v0.5.22 и доступен для использования всеми остальными операторами, зависящими от SGLang. Мы настоятельно рекомендуем всем операторам обновить зависимости SGLang до версии v0.5.22 или более поздней. Более подробную информацию о конкретных PR читайте ниже.

GLM 5.3 была единственной моделью, затронутой этим багом. У всех остальных разделенных разверток на Workers AI KV-пулы больше их длины контекста как на префилле, так и на декодере, поэтому ни один запрос не мог дойти до пути отклонения. Мы применили исправление движка и описанные ниже меры по повышению безопасности к каждой модели, которую мы обслуживаем с помощью SGLang, и наши проверки развертывания требуют их для каждого нового развертывания.

Хронология

Все время указано в UTC.

Когда

Что

27 августа 2026 г.

GLM 5.3 запущен на Workers AI с KV-пулом префилла меньше его окна контекста. Уязвимость присутствовала с момента запуска.

8 сентября 2026 г. — 23:11

Отчет получен через HackerOne.

9 сентября 2026 г. — 08:00

Cloudflare начинает проверку отчета HackerOne.

9 сентября 2026 г. — 13:22

Объявлен инцидент безопасности. Команда безопасности продукта воспроизвела утечку с использованием двух независимых учетных записей в течение 25 минут.

9 сентября 2026 г. — 14:00

После подтверждения масштаба проблемы GLM 5.3 был переведен в частный режим. Запросы возвращают HTTP 400. Страница статуса обновлена.

9 сентября 2026 г. — 14:35

Первопричина определена: пул префилла меньше длины контекста. Canary-узел префилла с большим пулом подтвердил отсутствие уязвимости.

9 сентября 2026 г. — 14:52

Все узлы префилла переведены на исправленную конфигурацию.

9 сентября 2026 г. — 19:04

Полная развертка пересобрана с исправленной конфигурацией и патчем движка от Cloudflare, который корректно возвращает ошибки для запросов, отклоненных планировщиком префилла. Проверено с помощью скрипта воспроизведения исследователя.

9 сентября 2026 г. — 19:40

Модель снова переведена в публичный доступ.

10 сентября 2026 г. — 23:30

Встреча с мейнтейнерами SGLang (техническим директором RadixArk и основными инженерами) для согласования апстрим-исправлений.

11–19 сентября 2026 г.

Дополнительные меры безопасности внедрены во все продакшн-развертки SGLang (подробности ниже).

16 сентября – 12 октября 2026 г.

Апстрим SGLang объединяет исправление приема, контрольные суммы для каждой передачи, сохранение подтверждений прерывания (abort-ACK) и включает отложенное высвобождение KV по умолчанию.

2 октября 2026 г.

Выпущен SGLang v0.5.21.

19 октября 2026 г.

Выпущен SGLang v0.5.22.

26 октября 2026 г.

Согласованная публикация совместно с исследователем и RadixArk.

Постоянная работа по повышению безопасности

Этот баг относится к классу багов безопасности памяти KV-кэша, над устранением которых Cloudflare работает уже несколько месяцев. В каждом случае страница освобождается, переиспользуется или считывается в то время, как что-то другое все еще претендует на нее. Мы выделяем две основные причины.

Первая — это жизненный цикл страницы в рамках одного узла. Несколько задач на узле декодирования могут удерживать одну и ту же страницу одновременно: генерация токенов, выгрузка в хост-память, получатель передачи KV, а также пути прерывания и ошибок. Если одна из них освобождает страницу в то время, как другая все еще использует ее, новому запросу может быть выделена эта страница, пока она все еще читается или записывается. Наши предыдущие исправления для выгрузки декодирования (#24226, #30899) и двойного высвобождения при ошибках грамматики (#30937) относились к этому типу.

Второе — это состояние гонки между узлами. Когда запрос прерывается в момент, когда фаза prefill еще записывает свой KV-кеш для передачи decode по RDMA, уже отправленные записи нельзя отменить. Если decode освобождает эти страницы немедленно, они могут быть отданы другому запросу, и запоздалые записи попадут в KV-кеш этого нового запроса. Cloudflare внесла свой вклад в устранение этой гонки посредством предложенных испавлений (#31357, #38961) и скрипта воспроизведения (#32564). В обоих случаях результатом становится поврежденный вывод или попадание данных одного пользователя в ответ другому без генерации какой-либо ошибки. Ошибка в данном инциденте была иной: отклоненный запрос всегда проходил этап передачи (handoff) не из-за случайного совпадения по времени, а в штатном режиме. Но результат был тем же: decode считывал страницы, которые этот запрос никогда не записывал. Ни один из этих сценариев не покрывал сбой данного инцидента, при котором prefill отклонял запрос, а decode об этом так и не узнал.

С момента инцидента мы сделали следующее:

• Расширили отложенное освобождение (deferred release), чтобы оно также удерживало исходные страницы prefill и охватывало все типы сбоев, а не только прерывания. Мы предложили это изменение в рамках основной ветки как , которое затем было заменено на #40645, #41402 и #41404.
• Развернули ограниченные пакеты передачи Mooncake (#32758, от сообщества SGLang), чтобы ни один отдельный вызов передачи не мог превысить таймаут освобождения.
• Изменили наш балансировщик нагрузки таким образом, чтобы отключение клиента больше не прерывало запрос в середине передачи. Он удерживает соединение prefill до завершения prefill, а соединение decode — до получения первого токена, после чего закрывает оба.
• Добавили проверку при каждом изменении дезагрегированного развертывания: размер пула KV сопоставляется с длиной контекста, отложенное освобождение задействовано на обеих ролях, ограничения пакетов передачи укладываются в тайм-аут освобождения, и применены все необходимые патчи.

Все эти изменения были выпущены в наши дезагрегированные производственные развертывания.

Работа с командой SGLang

Мы встретились с мейнтейнерами SGLang в RadixArk 10 сентября, на следующий день после инцидента. Мы договорились, что RadixArk исследует рассинхронизации (состояния гонки), о которых мы сообщали, перенесет в основную ветку идею проверки целостности и создаст тесты воспроизведения для данного класса ошибок.

Следующие изменения были приняты в основную ветку SGLang для устранения этого инцидента и связанных с ним состояний гонки KV-кеша, причем все, кроме одного, вошли в версию v0.5.22. Операторам, использующим дезагрегированный SGLang, следует обновиться до версии v0.5.22 или портировать эти патчи по мере необходимости.

Категория

Пулл-реквест

Релиз

Что делает

Инцидент

v0.5.20

Исключает прерванные запросы prefill до того, как их результат дойдет до decode. Это предотвращает возникновение проблемы данного инцидента.

Инцидент

v0.5.21

Отклоняет такие запросы на этапе приема (admission), до любого бутстрапа, распределения или передачи KV. Следует подходу из чернового патча Cloudflare, .

Гонка

v0.5.21, v0.5.22

sgl-router отменяет обе половины запроса при отключении клиента или сбое prefill.

Гонка

v0.5.20, v0.5.21

Включает отложенное освобождение KV только на тех бэкендах, которые его поддерживают, а затем включает его по умолчанию.

Гонка

v0.5.21

Исправляет случаи, когда подтверждение опустошения (drain confirmation) было потеряно, поэтому освобождение происходит по подтверждению, а не по истечении таймаута.

Гонка

v0.5.21

Удерживает страницы при любом сбое передачи, а не только при прерываниях, инициированных со стороны decode.

Гонка

v0.5.21

Исправляет регрессию в пути уведомления о прерывании.

Гонка

v0.5.22

Неудачная отправка Mooncake больше не сообщает о своих записях как об очищенных.

Гонка

v0.5.22

Помечает сообщения о прерывании для каждого запроса, чтобы повторно используемый идентификатор не мог использовать устаревшее подтверждение. Добавляет поддержку MORI.

Гонка

v0.5.20

Передает уведомление о сбое от prefill к decode между Mooncake, NIXL и MORI.

Гонка

v0.5.20

Опциональное ограничение на размер пакета передачи Mooncake, чтобы один вызов с истекшим тайм-аутом не оставлял неограниченное количество незавершенных записей.

Время жизни

v0.5.21

Decode ожидает завершения текущей выгрузки в хост-память перед отзывом запроса и освобождением его страниц. Разработано Cloudflare.

Время жизни

v0.5.22

Поддерживает согласованность рангов тензорного параллелизма при сбое восстановления кеша из хост-памяти.

Наблюдаемость

v0.5.21

Добавляет --disaggregation-enable-kv-checksum: decode проверяет контрольную сумму переданного KV перед генерацией. Очистка кода в #39729, объединено и ожидает релиза.

Наблюдаемость

v0.5.20, v0.5.21

Исправления для KV canary в SGLang, которая обнаруживает и регистрирует потенциальное повреждение.

Наблюдаемость

v0.5.22

Метрики для отложенного освобождения: количество, длительность и завершилось ли каждое удержание по подтверждению очистки или по тайм-ауту.

Эти доработки все еще находятся в разработке:

• Дополнительная очистка для --disaggregation-enable-kv-checksum. Объединено, ожидает релиза.
• Обнуление KV-страниц при освобождении, черновик предложения: #46435
• Расширение проверки контрольной суммы KV с передачи от prefill к decode на каждый шаг decode (см. раздел «Целостность по умолчанию» ниже)
• Более широкая поддержка моделей и функций KV Canary и KV Checksum

Что мы рекомендуем другим операторам

Если вы используете SGLang в дезагрегированном режиме prefill/decode, мы рекомендуем следующее:

• Измеряйте ваш пул KV и сравнивайте его с длиной контекста на каждом узле prefill и decode, используя лог запуска движка, после каждого изменения весов, квантования, параллелизма или доли памяти. Если пул меньше, уменьшите длину контекста до нужного значения. Не полагайтесь на прокси-сервер для принудительного соблюдения лимита и не рассчитывайте, то движок сам отклонит то, что не помещается. Это та проверка, которую мы не выполнили.
• Обновитесь до сборки, включающей и (v0.5.22 или новее), чтобы запрос с превышением длины отклонялся до передачи независимо от размера пула. Это исправление на уровне движка, которое служит страховкой на случай, если ваша проверка на первом шаге окажется неверной.
• Запускайте процесс с отложенным освобождением KV на обеих ролях (включено по умолчанию после #41023) и ограничивайте пакеты передачи Mooncake, чтобы один вызов с истекшим тайм-аутом не оставлял неограниченный «хвост» записей.
• Включите обнаружение повреждений там, где ваша модель это поддерживает. Параметры --disaggregation-enable-kv-checksum и --kv-canary пока поддерживают не всю архитектуру моделей. Проверяйте логи, чтобы убедиться, что запросы проходят верификацию. Мы работаем с командой SGLang над распространением обеих проверок на большее число архитектур, включая GLM 5.3, GLM 5.3 Flash и DeepSeek V4.
• Убедитесь, что ваш прокси-сервер не генерирует лишних прерываний. Настройте балансировщик нагрузки так, чтобы запросы доходили до первого токена, чтобы не вызывать прерывание, требующее межмоузловой координации.

В долгосрочной перспективе

Целостность по умолчанию

Проверки конфигурации и исправления жизненного цикла снижают количество способов неправильного использования страниц. Они не делают злоупотребление или сбои невозможными, и этот инцидент служит напоминанием о том, что следующая ошибка будет иметь форму, которую мы еще не видели. Надежное решение заключается в том, чтобы движок во время чтения обнаруживал, что запрос собирается обратиться к странице, которой он не владеет, и прерывал этот конкретный запрос вместо того, чтобы возвращать чужие данные.

Летом мы создали прототип этого механизма и описали его в августе. Каждая физическая страница KV имеет тег, который меняется при перераспределении страницы, каждый запрос записывает ожидаемые им теги, и маппинг проверяется до того, как decode считывает кеш. В наших тестах это стоило менее 1% пропускной способности и хвоста задержки (tail latency). Мы протестировали это на GLM 5.2 в середине августа, но вскоре отключили из-за проблем с надежностью.

Прототип также был привязан к конкретным бэкендам внимания и архитектурам моделей, поэтому он не мог служить универсальным решением. Мы работаем с командой SGLang над созданием продакшн-версии, встроенной в движок, которая будет работать со всеми моделями, вместо поддержки патчей, специфичных для Cloudflare. Контрольная сумма для каждого переноса в #39500 — это первый шаг: она проверяет передачу данных от этапа заполнения к этапу декодирования. Теги на уровне страниц идут дальше, поскольку они проверяют каждое чтение, включая чтения спустя долгое время после переноса.

Целостность за счет математической невозможности

RDMA копирует данные напрямую из памяти одного узла в память другого. Для двух машин крайне важно прийти к согласию о том, куда направляются данные, каков их размер и когда передача завершена; любое несоответствие может привести к тому, что получатель прочитает не те данные. Этот баг является примером сбоя согласованности в распределенной системе, при котором у двух машин было несогласованное представление о состоянии этой системы.

В других подразделениях Cloudflare мы приложили усилия к доказательству безопасности распределенных систем с помощью методов формальной верификации. Topaz обеспечивает выбор IP-адресов без конфликтов для наших авторитетных DNS-серверов. Модели реализации QuePaxa в Meerkat продемонстрировали ошибки согласованности, которые впоследствии были исправлены.

Теперь мы направляем наш опыт в области формальных методов на движки переноса KV-кэша. Это начнется с моделирования и доказательства безопасности протокола переноса KV-кэша на базе RDMA. Цель состоит в том, чтобы смоделировать распределенную систему KV-кэша нашего продакшн SGLang с использованием Mooncake, а затем отслеживать и исправлять любые отклонения от свойств безопасности, которые мы хотим гарантировать. Задача заключается в том, чтобы доказать — насколько это возможно — что подобный баг больше не повторится. Реалистично оценивая ситуацию, мы ожидаем пробелы в том, что могут подсказать средства доказательства, но доказательство остальных частей системы позволяет нам более внимательно проверять и контролировать эти пробелы.

Согласованное раскрытие информации

Мы публикуем этот отчет в рамках координированного раскрытия информации. Мы хотим поблагодарить исследователя Гади Эврона (Gadi Evron), который сообщил об этом через нашу программу HackerOne с четким, воспроизводимым скриптом и дал нам время на устранение проблемы и координацию действий с мейнтейнерами SGLang перед публикацией. Мы также хотим поблагодарить команду SGLang в RadixArk, которая восприняла это как свою проблему наравне с нашей и оперативно внедрила исправления в основной репозиторий.

Если вы обнаружите проблему безопасности в Workers AI, пожалуйста, сообщите о ней на hackerone.com/cloudflare.