Cloudflare discloses cross-customer data in 155 Workers AI GLM-5.3 responses

Cloudflare’s October 26 report describes a production data exposure that was already contained in September. Between August 27 and September 9, 155 responses, all to prompts longer than 681,280 tokens, included information from other customers’ recent requests to the same Workers AI model, @cf/zai-org/glm-5.3. That is a response count, not a count of people, organizations or accounts. Cloudflare says no other hosted Workers AI model was affected and found no evidence of deliberate exploitation after excluding its testing and the researcher’s activity.

The deployment advertised a 1,048,576-token context window while its prefill KV pool held only 681,280 tokens. In disaggregated serving, prefill processes prompts and transfers cached model state to separate decode GPUs. An over-capacity request became a one-token placeholder instead of being stopped. Decode treated the transfer as complete and generated output using pages still containing earlier requests’ data. The threshold describes the request receiving the response, not a safe lower bound for data submitted by potential source customers.

Cloudflare increased capacity and patched rejection handling before restoring the model on September 9. Its earlier public status notice covered errors; October 26 is the coordinated disclosure date for the data exposure. An older public SGLang bug report and pre-disclosure fixes do not establish that this hosted incident’s customer impact was public then.

For self-hosters, the recommendation is SGLang 0.5.22 or later plus configuration validation, rather than assuming a model name or an HTTP success code proves safety. The incident-specific rejection fixes appeared in 0.5.20 and 0.5.21. Related fixes address interrupted RDMA transfers, premature page reuse and cache lifetime; these have distinct prerequisites. The maintainers say the cross-engine interrupted-transfer race requires a mid-transfer termination and reuse of slots while writes are still in flight; a single-instance deployment without that transfer path is not affected by that specific race. In their reproduction it leaks the aborted request’s context into another client’s output, not back to the aborting client, which cannot select a victim. That is distinct from this incident’s rejected-request stale reads. The maintainer disclosure also identifies failed-send fix #45973 for NIXL/MORI, targeted for 0.5.23. It merged after 0.5.22; review confirmed 0.5.22 was still the latest published GitHub release, so these backends need that additional patch in a reviewed build/backport. The checksum cleanup #39729 and additional hardening were also pending release or development; 0.5.22 does not imply every proposed safeguard has shipped.

L3: confirmed tenant-isolation failure in a mainstream managed AI service, with actionable upstream implications. The known scope is limited and the service was repaired before disclosure; this is not evidence of ongoing theft, a platform-wide breach or a defect in every deployment of the model. Customer count, specific exposed data and customer-specific notifications are not quantified in the cited report. No CVE or GHSA identifier is assigned in these disclosures.