Cloudflare раскрыла ошибку изоляции запросов в GLM-5.3 на Workers AI
Раскрытие от 26 октября относится к инциденту 27 августа — 9 сентября. Cloudflare сообщает о 155 ответах с чужими данными, исправленной конфигурации и обновлениях SGLang; другие модели, по её проверке, не затронуты.
Публикация вышла после устранения инцидента
Исследователь сообщил Cloudflare о проблеме 8 сентября. Компания воспроизвела её, временно закрыла модель и восстановила обслуживание 9 сентября после исправления. Публичный разбор опубликован 26 октября совместно с участниками раскрытия. По данным Cloudflare, затронуты 155 ответов при очень длинных запросах к конкретной модели GLM-5.3. После исключения собственных тестов и запросов исследователя компания не обнаружила признаков преднамеренной эксплуатации. Это вывод расследования поставщика, который следует передавать с указанием источника, а не как независимую гарантию.
Кеш модели содержит чувствительное состояние
KV cache хранит промежуточные данные, используемые при генерации текста. Он помогает избежать повторного вычисления уже обработанного контекста. В многопользовательской системе такая оптимизация требует строгой изоляции областей памяти и жизненного цикла запроса. Публичное issue SGLang описывало ошибочный результат для отклонённых запросов при раздельных стадиях обработки. Важно отличать это от обычного кеширования одинакового публичного ответа: здесь состояние связано с содержимым пользовательского запроса. Нарушение границы может раскрыть данные даже при корректной авторизации на внешнем API. Стадия prefill обрабатывает входной контекст, а decode производит продолжение. При разделённом развёртывании между ними передаётся промежуточное состояние. Это увеличивает число согласуемых событий: принятие, отклонение, завершение передачи и освобождение памяти должны одинаково интерпретироваться обеими сторонами. Публичное issue описывает именно расхождение на пути отклонённого запроса. Успешный сетевой ответ в такой архитектуре означает завершённый обмен, но не сам по себе доказательство правильного владения каждой страницей памяти внутри движка.
Две причины совпали в одном развёртывании
Cloudflare описала несоответствие объявленного контекстного окна и фактического объёма кеша, а также дефект обработки отказа в движке SGLang. Вместо ожидаемого завершения с ошибкой путь запроса продолжался и мог обратиться к ранее использованным страницам. Подробности воспроизведения атаки в этом обзоре не приводятся. Важна системная сторона: успешный HTTP-статус и наличие текста в потоке не доказали корректность изоляции. Проверка только доступности сервиса оставила незамеченным то, какие данные участвовали в ответе.
Исправление включает движок и условия запуска
Поставщик сообщает об увеличении пула до безопасной конфигурации, исправлении пути отказа и дополнительных проверках для развёртываний. В разборе рекомендована SGLang 0.5.22 или новее; отдельный release подтверждает существование этой версии. Это указание конкретного расследования, а не утверждение, что любая последующая конфигурация автоматически безопасна. Движок, параметры памяти, разделение стадий и обработка прерванных запросов работают совместно. Поэтому обновление зависимости следует рассматривать вместе с проверкой фактически запущенных параметров, а не только строкой версии в манифесте.
Границы затронутой конфигурации
Cloudflare связывает воздействие с конкретной моделью и несоответствием размера пула контексту. Для остальных моделей компания сообщает о достаточном размере кеша, который не позволял попасть в ошибочный путь отказа. Это результат её проверки, а не утверждение обо всех чужих установках SGLang. Публичное issue описывает общую проблему движка, release notes — доступность исправления, а расследование оператора — воздействие на пользователей сервиса. Эти три уровня доказательств дополняют друг друга. Сам октябрьский день раскрытия отделён от сентября, когда поставщик изменил конфигурацию и восстановил модель, поэтому публикация не означает продолжения воздействия весь этот период.
