A Cloudflare Containers vulnerability could have allowed one paying customer to recover residual disk data left by another customer’s container on the same physical host. Cloudflare says it has fully remediated the cross-tenant isolation flaw, completed fleet-wide cleanup on September 19, 2026, and found no evidence of malicious exploitation in the historical telemetry available to the company.
What happened
Security researcher Oren Yomtov of Accomplish reported the flaw to Cloudflare through its HackerOne bug bounty program on September 4. The issue affected Cloudflare Containers and products built on the same storage implementation, including Cloudflare Sandboxes.
Cloudflare Containers use shared storage pools to provide writable disks to isolated workloads. According to Cloudflare, an affected storage setting instructed Linux device mapper thin provisioning to skip zeroing newly allocated 64 KiB blocks. When a storage block previously used by one container was reassigned, a small write by a new container could overwrite only part of that block while leaving older data readable in the remaining space.
The proof of concept used a Workers Paid account and raw access to the container’s writable disk. The researcher could not choose a specific victim, workload, host, or active disk. Exposure depended on Cloudflare’s automatic placement and which previously released storage blocks were reassigned.
What Cloudflare confirmed
Cloudflare confirmed that successful exploitation could cross the tenant-isolation boundary and disclose filesystem metadata, directory structures, database pages, and application data. During controlled testing, researchers observed residual material on 18 of 24 container placements and 20 of 22 underlying nodes across four continents.
Accomplish said the recovered material included directory listings, SQLite databases, Chromium profiles, environment files, and credential files. Cloudflare said the materials submitted to it contained aggregate counts, checksums, and format checks rather than third-party filenames, credentials, or recovered content values. The researchers told Cloudflare that the recovered data remained confidential and was securely deleted.
The researchers did not demonstrate an ability to alter another customer’s active data or interrupt workloads. Cloudflare also said the technique could not access an actively attached disk.
How Cloudflare fixed the vulnerability
Cloudflare removed the configuration that skipped block zeroing across its Containers fleet. That restored the default behavior of clearing newly allocated blocks before a container could access them.
Because changing the setting did not clean blocks already mapped to running container disks or cached image layers, Cloudflare also retired running container disks and removed cached snapshots created before the mitigation. The company completed rollout of the initial fix on September 7, the researchers confirmed their proof of concept no longer worked on September 14, and Cloudflare finished clearing pre-mitigation cached snapshots on September 19.
Cloudflare says customers do not need to change any platform configuration to receive the fix.
What remains unverified
Cloudflare reviewed retained historical disk input and output telemetry for activity matching the proof of concept. It identified authorized testing by the researchers and its own engineers, but no additional activity consistent with the technique.
That finding means Cloudflare found no evidence of malicious exploitation in the telemetry it retained. It is not proof that exploitation was impossible before remediation. Cloudflare has not announced a confirmed customer data breach tied to this flaw, and affected organizations should not describe one as confirmed without additional evidence.
Who may have been affected
The vulnerability concerned workloads using Cloudflare Containers and services built on that storage system. An attacker would have needed a Workers Paid account to run the proof of concept described by Cloudflare.
The risk was random rather than targeted because customers cannot select the physical host that runs a container. Even so, the ability to recover residual data across customer boundaries is significant because application disks can contain API tokens, database content, environment variables, session material, and other business secrets.
Why this matters for small businesses
Small businesses increasingly rely on managed cloud platforms to run websites, automation, development tools, and AI services. Cloud isolation reduces operational work, but it also places responsibility for some security controls with the provider. A platform-side fix may require no patch from the customer while still warranting an internal review of what secrets were stored in the affected service.
This incident also reinforces a basic cloud-security principle: credentials stored in application files or container layers should be treated as potentially recoverable if an isolation control fails. Short-lived credentials and tightly scoped permissions can reduce the impact of an unexpected disclosure.
Practical defensive actions
- Confirm service use: Inventory whether the business or any development vendor used Cloudflare Containers, Sandboxes, or related services during the affected period.
- Review sensitive data placement: Identify secrets, environment files, browser profiles, database copies, or customer records that may have existed on writable container disks.
- Rotate credentials when risk justifies it: Consider rotating high-value API keys, database passwords, and service tokens that were stored in affected workloads, especially if they were long-lived or broadly privileged.
- Use a managed secrets system: Avoid baking credentials into container images or leaving them in temporary files. Retrieve secrets at runtime and limit how long they remain valid.
- Apply least privilege: Restrict each token to the minimum systems and actions required so one exposed secret cannot unlock unrelated business data.
- Check access logs: Review authentication and API logs for unexpected use of credentials associated with these workloads. Cloudflare’s finding does not replace customer-side monitoring in connected services.
- Document vendor incidents: Record the disclosure, the provider’s remediation dates, the business’s exposure review, and any credential rotations for future risk assessments.