Cloudflare’s Workers AI disclosure puts shared inference isolation under scrutiny

August 27 to September 9: the provider’s incident record

Cloudflare’s public account gives the incident a defined sequence. The GLM-5.3 exposure window began on August 27. Researcher Gadi Evron from Knostic alerted Cloudflare on September 8. The provider says it reproduced the issue the next morning, took the model offline within 40 minutes of declaring an incident, applied corrections and restored it on September 9. The new event covered here is the October 26 coordinated disclosure.

According to the company’s disclosure, some responses during that period contained data from other customers’ recent requests to the same model. Cloudflare reports 155 affected responses, all to prompts longer than 681,280 tokens. It says no other model hosted on Workers AI was affected. These scope statements are the provider’s incident account, not an independent forensic finding by Foundra.

The new event is the public explanation of the exposure and remediation. The article does not present the August start date as current breaking news or imply that the disclosed failure is still active. Its significance is the account of how a shared inference service lost a boundary customers would ordinarily expect it to preserve.

A rejection crossed the processing boundary

An inference system can reuse internal work to avoid repeating computation. In broad terms, a key-value cache stores intermediate model state that can help generate subsequent output efficiently. That operational advantage creates another responsibility: reused state must not carry material from one customer into a response for another. Cloudflare’s technical account describes two overlapping problems: a configured context window larger than the prefill cache pool, and an engine bug handling the resulting over-length requests. The company says it expected an error for a request the system could not process. Instead, the handling of rejected requests allowed incorrect state to reach the output path. This is the provider’s technical explanation, not a reproduction by Foundra.

The technical sequence described by Cloudflare explains why a failed request mattered. An over-length prompt was marked as rejected and replaced by a one-token placeholder. Instead of ending with an error, the system transferred the placeholder’s cache and signalled completion to the decode side. That side assumed the new prompt had overwritten the earlier state, while most of the old state remained. This is the provider’s account, not an exploit reproduced by Foundra.

The practical lesson is about how a system fails as well as how it succeeds. A rejected request should remain rejected throughout the processing chain. A test that confirms some long prompts return successful responses would not, on its own, establish correct handling of requests beyond a different resource boundary. That is an inference from the disclosed mismatch, not a claim to have independently audited the implementation.

For an application developer, that distinction can be difficult to see from the endpoint alone. A response can look fluent and otherwise useful while containing information from the wrong request. Conventional product-quality evaluation would not necessarily reveal that problem unless it deliberately tested isolation across customers and request histories.

The provider says it addressed both layers before restoring service: it enlarged the cache pool to accommodate the configured context window and patched the rejection path so rejected requests ended before allocation or cache transfer. It describes validation using the researcher’s reproduction script and its own marker tests. Correcting capacity and making rejection safe are distinct changes; the account does not ask readers to rely only on a larger pool.

The scope number needs its denominator—and its label

The figure of 155 is a count of affected responses in Cloudflare’s account. It is not a count of unique people, a complete description of every piece of information exposed or a basis for calculating the probability of exposure in a different service. Readers should resist turning a concrete incident count into a general failure rate without the relevant denominator and method.

Cloudflare says that, after excluding its own tests and the researcher’s, the identified requests were consistent with ordinary long-context use. It reports no evidence of deliberate exploitation. The disclosure should therefore not be rewritten as an established attack campaign. An isolation failure can affect ordinary requests without a malicious customer deliberately seeking someone else’s information.

Similarly, the provider’s finding that other hosted models were unaffected is important to its stated scope but should not be expanded into a claim that all other inference products are immune to isolation problems. An incident report can identify a bounded failure without certifying a whole technology category.

What this changes for a buyer’s evaluation

A prospective customer can use the disclosure to ask more concrete questions of a shared inference supplier. What state is reused across requests? How is the permitted reuse boundary enforced? Which tests exercise interactions between customers? How are anomalous outputs investigated and scoped? These are evaluation questions, not an assertion that another named service has the same defect.

The relationship between upstream components and the hosted service also matters. A buyer contracts for the operating service, not just the model weights. The supplier’s responsibilities include configuration, deployment changes, monitoring and incident response around the components it uses. An upstream fix and a safely operated customer service are related but distinct pieces of evidence.

Cloudflare’s disclosure gives developers a specific case to examine rather than a reason to assume all shared inference is unsafe. The durable lesson is narrower: inference quality includes confidentiality boundaries. A service must return a useful answer and ensure that the state behind that answer belongs to the customer entitled to receive it.