Cloudflare discloses a Workers AI bug that showed some customers data from others with the GLM-5.3 model
IA en un minuto newsroom · Editor: Jon Elgezabal
In 30 seconds
Workers AI, Cloudflare's AI service, handed some users pieces of other people's queries through GLM-5.3 for almost two weeks at the end of the summer; there were 155 such responses, always to requests above 681,280 tokens. Gadi Evron, from Knostic, raised the alarm. Cloudflare blames a bad configuration combined with an SGLang error.
Cloudflare has acknowledged that Workers AI, its platform for using AI models, sent a small number of customers responses carrying data from other customers' requests. It disclosed this on October 26 on its blog, in a report released together with one from SGLang, the open-source engine it relies on to run the affected model.
The problem occurred between August 27 and September 9 with GLM-5.3, a Z.ai model designed for coding with agents. In all, 155 responses were affected, every one of them to a text longer than 681,280 tokens, and the foreign data came from requests sent to the same model shortly before.
On September 8, researcher Gadi Evron, from Knostic, flagged it through the company's HackerOne program. Cloudflare reproduced it the following morning, took the model offline less than 40 minutes after declaring the incident and brought it back, fixed, that same day.
According to the company, the cause was two failures added together. The model accepted texts of up to 1,048,576 tokens, but the memory set aside to process them only fit 681,280; Cloudflare knew about the gap and expected the engine to return an error. Instead, an SGLang bug meant the response was built on top of leftovers from earlier requests. That memory now has room for roughly 2.04 million tokens and the engine has been patched; SGLang has fixed the bug in its version 0.5.21.
Cloudflare says it has found no signs of deliberate exploitation and that no other Workers AI model was affected.
Why it matters · analysis and opinion
A cloud AI provider mixing up queries from different customers is exactly the fear that stops many companies from sending it internal documents. There was no attack here, but there is a lesson: the memory that requests share in these services is reused to gain speed, and one poorly checked setting is enough for someone else's data to slip in. Cloudflare itself admits its tests checked whether the response arrived, not what it said. For anyone using hosted models, the practical steps are to send no more sensitive information than needed, ask the provider how it keeps each customer apart and follow the security notices for the models in use. Very long contexts, newly launched on many services, are where there is the least track record.
Official source: blog.cloudflare.com · Written with the help of AI: how we make the news
What does it mean for your business? · analysis and opinion
This case mainly affects companies and developers in Spain and Latin America that use Workers AI or other shared cloud AI services to connect models to their own applications. The group directly involved is anyone who used GLM-5.3 on Workers AI between August 27 and September 9 with prompts longer than 681,280 tokens. A small business or freelancer that only uses a chat assistant in the browser is not affected by this specific bug, although the lesson applies to them as well.
Our practical advice: review the usage logs for those dates to find out whether such long prompts were sent to that model and, if so, write down what information they contained. In general, the prudent approach is not to put entire documents with personal data, contracts or passwords into a single request when an excerpt is enough, and to remove names and identifying details before sending them. It is also worth knowing where each provider publishes its incident reports, so you find out in time.
These precautions cost very little; the risk of skipping them is that customer information reaches third parties because of a provider error, even though the company did nothing wrong. If personal data was among what was sent, the sensible step is to document it and assess with an advisor whether it should be treated as a security breach under the GDPR.
