Cloudflare GLM-5.3 AI Data Exposure: 155 Responses, the SGLang Fix, and What Enterprises Must Check

Published analysis: 28 October 2026. A cloud AI service can have authentication, tenant separation and encrypted network connections yet still return fragments of another customer's prompt. That is the uncomfortable lesson from Cloudflare's detailed 26 October disclosure about the GLM-5.3 model on Workers AI. This is a report about a remediated incident, not a claim of an ongoing Cloudflare outage.

The verified facts: Cloudflare says an inference-engine configuration mismatch combined with a bug in SGLang caused cross-request data exposure from 27 August to 9 September 2026. It identified 155 affected responses to prompts exceeding 681,280 tokens, not 155 affected customers. The company says it restored the service on 9 September after fixing the configuration and engine, and found no evidence of deliberate exploitation. Read the original Cloudflare incident report before treating secondhand summaries as proof of broader impact.

What actually went wrong?

Large language models retain an internal key-value (KV) cache while processing prompts and generating answers. In a multi-tenant service, the inference runtime must prevent one request from reading memory that belongs to another request. Cloudflare's GLM-5.3 deployment advertised a 1,048,576-token context window, but its prefill GPU KV pool could hold only 681,280 tokens. That mismatch should have caused an oversized request to fail safely.

Instead, the SGLang disaggregated prefill/decode path handled a rejected request incorrectly. The prefill stage sent a minimal placeholder, while the decode stage proceeded as though the full prompt cache had been transferred. Some reserved pages still contained information from earlier requests. The model then generated an answer using stale cache data. Crucially, affected requests could return an HTTP 200 success response, so a basic uptime or API-status check would not reveal the confidentiality failure. Cloudflare documents the request lifecycle and root cause in its technical post.

What was exposed, and what was not?

Cloudflare confirmed 155 contaminated responses in the stated window, all involving unusually long prompts. It says only the GLM-5.3 model on its Workers AI service was affected and that other hosted models did not share the vulnerable configuration. The report does not establish that 155 separate people or companies were compromised, that an attacker deliberately exploited the issue, or that every SGLang deployment leaked data. Those distinctions matter when preparing a customer or executive incident briefing.

The affected model was temporarily taken offline on 9 September. Cloudflare then increased the available KV capacity, patched the rejection path, tested with the researcher's reproduction case, and restored the model later that day. The public disclosure followed on 26 October. Organizations should separate the incident dates, the remediation date, and the public disclosure date in their risk records.

Why this matters to enterprise AI and SAP teams

For an enterprise architect, the failure mode is more instructive than the affected model name. A system may correctly enforce application-level identity, permissions and API authentication while the model-serving layer violates isolation between customers. The same principle applies when an AI assistant is connected to HR, finance, procurement or other confidential business data. Strong role-based permissions at the application layer do not by themselves prove that inference infrastructure is isolating request state.

For example, an organization evaluating a custom AI assistant that accesses employee records should test both sides of the trust boundary: whether the assistant is authorized to retrieve a record, and whether the serving platform can prevent that record's content from appearing in a different user's generated response. This is a general architecture lesson, not evidence that SAP SuccessFactors, Joule, or any SAP product was affected by Cloudflare's incident.

Five checks for AI platform owners

1. Confirm actual exposure. Inventory whether your organization used @cf/zai-org/glm-5.3 on Workers AI between 27 August and 9 September 2026. If so, review Cloudflare communications and seek tenant-specific incident clarification through your support or security channel. Do not infer your data was leaked solely because you used Cloudflare.
2. Identify the serving architecture. If you operate your own SGLang inference stack, determine whether you use disaggregated prefill/decode and whether the running engine's KV pool can accommodate the advertised maximum context length on every relevant node. Validate the actual startup metrics, not only configuration files.
3. Patch and test failure paths. Cloudflare advises disaggregated SGLang operators to run version 0.5.22 or later, or an appropriately backported build. Confirm inclusion of the safe rejection and admission fixes, including PR 36988 and PR 38935. Consult the v0.5.22 release and your own deployment compatibility tests before upgrading.
4. Exercise cross-tenant isolation. In a controlled test environment, send distinct canary markers from separately authorized accounts, including over-length prompts and aborted requests. Assert that rejected requests fail clearly and never return content from another test tenant. A successful HTTP status is not a sufficient security acceptance criterion.
5. Review operational controls. Verify deferred KV release, bounded transfers, and supported integrity or canary checks. Cloudflare notes that some detection features are model-dependent, so record where coverage is absent instead of assuming universal protection. Its hardening guidance explains these operational checks.

What should procurement and governance teams ask vendors?

Ask for a written description of request-state isolation, independent test coverage, incident-notification timelines, long-context failure behavior, and whether the vendor operates shared or dedicated inference capacity. Request evidence of regression tests that detect cross-request contamination after model upgrades or infrastructure changes. For sensitive employee, financial or customer data, include these requirements in AI service acceptance criteria and vendor-risk reviews.

Also ask whether the vendor's security review covers inference-time memory, not merely storage encryption and role-based access. These controls protect different layers. Cloudflare's post is unusually useful because it explains a failure that was not caught by ordinary response-code and performance tests, and describes concrete measures added to its deployment pipeline.

Does this mean hosted AI is unsafe?

No. A single documented, remediated incident does not establish that all hosted AI services are insecure. It does show why confidence must rest on tested isolation properties and transparent incident handling rather than broad marketing assurances. Cloudflare reports that it corrected this specific configuration and applied additional hardening across its SGLang deployments; those are vendor statements that enterprise teams can evaluate against their own risk requirements.

What is the actionable conclusion?

If you used the affected Cloudflare model in the exposure window: investigate tenant-specific implications with the vendor. If you self-host disaggregated SGLang: review your engine version, KV pool sizing, request rejection, cache lifecycle and isolation tests. If you buy managed enterprise AI: add inference-memory isolation and long-context negative testing to the vendor assurance checklist.

The broader shift is important: as AI systems gain access to sensitive enterprise workflows, security teams must examine the entire execution path, from user identity and application authorization to inference memory and generated output. The incident is fixed; the design lesson remains relevant.

Primary sources and further technical reading

Source of record: Cloudflare incident report, 26 October 2026. Upstream engineering references: SGLang rejected-request fix, admission-path hardening, and SGLang v0.5.22. All impact counts and Cloudflare remediation dates above are attributed to Cloudflare's disclosure; general enterprise guidance is an architectural recommendation, not a claim of additional affected services.