What Happened in the Cloudflare Workers AI Leak?#
Cloudflare confirmed a Workers AI leak this week: its GLM-5.3 model exposed fragments of other customers' conversations in 155 responses, between 27 August and 9 September this year. A bug in the memory handling let one customer's request read leftover data from someone else's. Nobody noticed until a security researcher flagged it.
Here's the mechanic, stripped of jargon. GLM-5.3's context window was built for just over a million tokens, but the memory pool reserved for processing prompts only held about 681,000. When a request ran over that limit, it should have been rejected outright.
Instead, a bug in SGLang — the inference engine behind the model — marked the request as rejected but still let it read leftover cache pages from whoever's request had just finished on that machine. Cloudflare's own writeup says the issue was reported through HackerOne by researcher Gadi Evron of Knostic. It was patched the same day it was confirmed, 9 September 2026, and published in full on 26 October.
Does This Affect Your Business?#
Mostly, no. If you're running a WhatsApp bot or a FAQ widget that only ever sees your own customers' short questions, this doesn't touch you. The bug only triggered on prompts longer than roughly 681,000 tokens. That's hundreds of pages in one request. Most small business chatbots never come close.
It matters if you're feeding a vendor's shared AI endpoint large batches of client documents, call transcripts, or long chat histories, and you don't actually know whether that endpoint is multi-tenant.
We build WhatsApp and voice automation for businesses across the GCC, Europe, USA, Canada, and India. At WebEpex, every new AI vendor pitch now starts with one question before features or price come up: is inference isolated per request, or shared across a pool. Two vendors we talked to this month didn't have a ready answer. That told us plenty.
What Cloudflare Got Right — and What It Didn't#
Credit where it's due. Cloudflare disclosed this properly, coordinated with the SGLang team, patched it the same day it was confirmed, and published a genuinely technical postmortem instead of a vague "we take security seriously" statement. It also says it found no evidence of deliberate exploitation — the pattern looked like ordinary long-context use, not an attack.
What's missing: Cloudflare doesn't say whether the 155 affected customers were ever told directly, and it gives you no way to check if you were one of them.
There's also an uncomfortable detail buried in the postmortem. The exact same SGLang bug was flagged on GitHub back in July, three months before anyone connected it to this leak. I don't think that's incompetence. I think it's just how distributed systems work when dozens of teams share one open-source engine — "someone else already tested this" isn't a safety guarantee.
How We're Handling AI Vendor Risk at WebEpex#
This week we went through every client integration that touches an external AI endpoint for anything heavier than a quick lookup — Voiceflow's knowledge base calls, n8n's AI nodes — and mapped which ones hit a vendor's shared pool versus our own self-hosted layer.
Anywhere a client's raw documents were leaving our infrastructure for third-party summarization without a written isolation guarantee, we've already swapped it for a self-hosted step, or put the question to the vendor directly, in writing.
That's not dramatic work. It's the kind of audit that's cheap on a quiet week and expensive to skip on a bad one. We've flagged this exact risk before, when AI agent containment came up for UAE enterprises running agents with too much standing access — the pattern repeats: infrastructure built for speed gets security bolted on after, not before.
What Should You Do This Week?#
If your bot only handles short, routine conversations, don't lose sleep over this one. If you're pushing long documents, transcripts, or big chat histories through any AI API, ask your vendor in writing:
- Is inference isolated per customer request, or shared across a pool?
- What happens when a request is rejected for being too long — does it fail cleanly, or silently return something?
- Which specific model and provider is actually processing the data, not just the brand on the login page?
- Has this vendor had a disclosed incident like this before, and how fast did they patch it?
A vendor who answers in a day has already thought about this. One who goes quiet for a week hasn't, and that's useful information on its own — the same logic we apply when auditing dormant credentials left behind by AI agents, or patching server-level vulnerabilities before they get exploited.
If you want a second pair of eyes on which of your AI integrations actually run where, send me what you're using and I'll tell you straight — two minutes, no pitch. cal.com/webepex/growth-review
