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, створивши завдання № 30233 6 липня 2026 року; 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, а усунули о 16: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%, за словами команди, не був статистично значущим. Cloudflare зустрілася з мейнтейнерами SGLang у RadixArk 10 вересня 2026 року, а з 11 до 19 вересня 2026 року розгорнула додаткові засоби захисту на всіх своїх виробничих розгортаннях SGLang. Злиття до основної гілки, що містили виправлення на етапі допуску, контрольні суми для кожного передавання, збереження підтвердження переривання та ввімкнене за замовчуванням відкладене звільнення KV, відбувалися з 16 вересня до 12 жовтня 2026 року.

Для інших операторів, які запускають SGLang у дезагрегованому режимі, у звіті Cloudflare рекомендовано вимірювати пул KV відносно довжини контексту на кожному вузлі попереднього заповнення та декодування після будь-якої зміни ваг, квантування, паралелізму чи частки пам’яті; оновитися до збірки, що містить обидва виправлення на етапі допуску; використовувати відкладене звільнення KV в обох ролях; увімкнути виявлення пошкодження, якщо модель його підтримує; а також налаштувати балансувальники навантаження так, щоб від’єднання клієнта не переривало запит посеред передавання.

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

У дописі команди SGLang згадано інженерів Cloudflare Кевіна Флансбурга та Кастана Дея, яким подякували за роботу над виправленнями, а спільне розкриття інформації командами SGLang і Cloudflare 26 жовтня 2026 року зазначено як останній пункт у хронології розкриття. У майбутньому має вийти власний звіт дослідника, у якому, за словами команди SGLang, буде описано виявлення проблеми та її зовнішню перевірку.