Cloudflare has fixed a cross-tenant vulnerability in its Containers and Sandboxes service that could have let a customer read leftover data from other customers’ containers running on the same physical host, BleepingComputer reported Sunday. The company described the issue and its remediation in a technical post on Sept. 24 and said it found no evidence the flaw was abused.

What Happened

The problem sat in how container root disks were provisioned. Cloudflare used the Linux device-mapper thin provisioning system, known as dm-thin, with a shared storage pool that served workloads from many customer accounts. That pool was configured with the skip_block_zeroing option, which meant 64 KiB blocks returned to the pool when a container’s disk was deleted were not wiped before being assigned to another container.

A new container that wrote just 4 KiB into an unused region of its disk would cause a fresh 64 KiB physical block to be mapped. The write replaced only that 4 KiB, so the remaining 60 KiB could still hold data left by a previous tenant, readable from inside the new container.

RelatedSuspected Chinese Spies Exploited BeyondTrust Remote Support Flaw Since August, Google Says

Oren Yomtov, a researcher at technology company Accomplish, reported the flaw through Cloudflare’s HackerOne program on Sept. 4, 2026. Exploiting it required only a Workers Paid account.

Why It Matters

The testing showed the issue was not an edge case. According to Cloudflare, researchers found residual material on 18 of 24 container placements and on 20 of 22 underlying nodes across four continents, and identified about 2,700 distinct foreign directory inodes.

Recoverable data included directory listings, SQLite databases, Chromium browser profiles, .env files and credential files. Environment files and credentials are among the most sensitive artifacts a workload can leave behind, since they often hold API keys and database passwords.

Container and sandbox services are increasingly used to run untrusted code, including code written or executed by AI agents, and customers rely on the provider to keep tenants’ data apart. A storage optimization that skips a wipe step undermines that isolation without any bug in the container runtime itself.

The Fix and Its Limits

Cloudflare said a runtime fix was merged on Sept. 4, the day of the report, and the rollout across its fleet was complete by Sept. 7. Cleanup of cached image snapshots created before the fix finished on Sept. 19.

The mitigations removed the skip_block_zeroing setting, retired all container disks created before the fix and cleared the cached snapshots, so that no pre-fix block could carry old data into a new container.

The company said an attacker could not have chosen a specific victim or host, and could not modify another customer’s live data; the technique only exposed whatever happened to remain in recycled blocks. Cloudflare said its logs and telemetry showed only activity by the authorized researcher and its own engineers, and that customers do not need to do anything.

What to Watch

Cloudflare’s disclosure gives other providers a specific configuration to audit. Disabling block zeroing in thin-provisioned storage saves write overhead, and multi-tenant platforms that run customer workloads on shared pools may review whether the same setting is in use. Customers that stored secrets in container disks on the service may also choose to rotate them, even though Cloudflare says no action is required.